deniz.in

Markets

Weather

Loading weather

· via Vercel blog

Vercel Container Registry login action uses GitHub OIDC to drop long-lived credentials

Vercel's new vcr-action/login GitHub Action exchanges a workflow's OIDC token for a short-lived Vercel token, letting CI push to Vercel Container Registry without stored registry secrets.

Vercel Container Registry login action uses GitHub OIDC to drop long-lived credentials

What shipped

Vercel has released a login action for GitHub Actions that removes the need for stored registry credentials. According to a Vercel changelog entry, the new vercel/vcr-action/login action lets a workflow authenticate to Vercel Container Registry (VCR) and push images to vcr.vercel.com using nothing but the job's own identity.

How the OIDC exchange works

The action builds on GitHub's OpenID Connect support. At run time it presents the workflow's OIDC token to Vercel, receives a short-lived access token in return, and uses that token to sign in to the registry. When the job ends, the action signs out and revokes the Vercel token, so no reusable credential outlives the run.

Vercel controls the boundary on its side: the exchange only succeeds when an OIDC policy on the team points at the exact repository and workflow making the request, and that policy also fixes the permission level, such as read-write access to VCR. A token issued to one pipeline consequently cannot be replayed from a different repository or workflow.

What setup involves

The changelog lays out four prerequisites:

  • An OIDC policy on the Vercel team, scoped to the GitHub repository and workflow, granting read-write registry access.
  • Repository variables holding the Vercel team ID (for instance VERCEL_TEAM_ID) plus the team slug, project slug and repository name that compose the image tag.
  • The id-token: write permission on the job or workflow, which authorizes GitHub to mint the OIDC token.
  • A login step placed ahead of the build-and-push step.

The essential shape of the workflow:

yaml permissions: contents: read id-token: write

steps:

  • uses: actions/checkout@v4
  • uses: docker/setup-buildx-action@v3
  • name: Log in to VCR uses: vercel/vcr-action/login@v1 with: team: ${{ vars.VERCEL_TEAM_ID }}
  • name: Build and push uses: docker/build-push-action@v6 with: tags: vcr.vercel.com/${{ vars.VERCEL_TEAM_SLUG }}/${{ vars.VERCEL_PROJECT_SLUG }}/${{ vars.VCR_REPOSITORY }}:latest

Vercel's full example additionally configures a linux/amd64 platform target and zstd-compressed OCI image output.

Engines and sandbox images

Docker is authenticated by default. According to the changelog, the action also accepts an engines setting for teams that build with Podman or Buildah instead. Once VCR has prepared a linux/amd64 image, it can double as a custom Vercel Sandbox image, referenced within the same project by repository name and tag.

Why it matters

Static registry tokens are a standing liability: they sit in secret managers, leak into logs when mishandled, and remain valid long after the pipeline that needed them disappears. Binding authentication to the job's identity through OIDC eliminates that class of secret entirely, because the credential exists only for the duration of the run and is revoked the moment it ends. The move lines Vercel up with the larger cloud registries, which have offered workload-identity federation for years. For teams already building in GitHub Actions, the switch is deliberately cheap: one policy on the Vercel team, a few repository variables and a single extra workflow step.

  • #vercel
  • #github-actions
  • #oidc
  • #containers
  • #security

Related posts