Deploying to Google Cloud from GitHub Actions

Google Cloud deploys use Workload Identity Federation so you never store a service account key.

On Google Cloud, the keyless pattern is Workload Identity Federation: GitHub OIDC tokens are exchanged for short-lived Google credentials. This lesson shows how to authenticate and deploy to Cloud Run, a common serverless target.

Workload Identity Federation

You create a workload identity pool and provider that trusts GitHub OIDC, then let it impersonate a service account. The google-github-actions/auth action performs the exchange, returning temporary credentials. No downloaded service account JSON key is ever stored in secrets.

Authenticate and deploy to Cloud Run

The workflow authenticates, then deploys an image to Cloud Run:

.github/workflows/deploy-gcp.yml

permissions: { id-token: write, contents: read }
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: google-github-actions/auth@v2
        with:
          workload_identity_provider: ${{ secrets.GCP_WIF_PROVIDER }}
          service_account: ${{ secrets.GCP_SERVICE_ACCOUNT }}
      - uses: google-github-actions/setup-gcloud@v2
      - run: |
          gcloud run deploy app \
            --image us-docker.pkg.dev/$PROJECT/app/app:${{ github.sha }} \
            --region us-central1 --platform managed

Targets on Google Cloud

Cloud Run: container deploys with built-in scaling and traffic splitting.
GKE: Kubernetes deploys via kubectl or Helm.
Cloud Functions: event-driven serverless functions.
App Engine: managed platform deploys via gcloud.

Traffic splitting on Cloud Run

Cloud Run revisions make canary rollouts easy - deploy without traffic, then shift a percentage to the new revision and ramp up as metrics hold.

Key takeaways

Workload Identity Federation gives keyless GCP auth from GitHub Actions.
Authenticate, then deploy with gcloud to Cloud Run, GKE, or Functions.
Cloud Run revisions support easy traffic-split canary rollouts.