Curating trusted content for the agentic software era

While AI made it easier for organizations to keep up with the latest innovations, it also made it harder to know what to trust. When software is selected at machine speed, the question is no longer “is this popular?” It’s “do we know who published this?”

Docker Hub has always been where developers go to answer that question. Starting today, software vendors looking to make their trusted content discoverable to developers by becoming Docker Verified Publishers will enjoy a faster application process, with less friction, and plans that fit their specific growth needs.

With the Docker Verified Publisher (DVP) program, Docker Hub turns into a trusted, discoverable, and measurable distribution channel. Organizations accepted into the program earn verified status and prioritized ranking. DVP publishers also gain access to analytics reports that show which versions are getting the most traction and which companies are pulling them, turning open-source reach into a commercial pipeline.

What’s new in Docker Verified Publisher Applications

Applying to become a Docker Verified Publisher (DVP) is now self-serve. You can now apply directly in Docker Hub, our team reviews your application, and if you’re approved, you become part of our trusted ecosystem on Docker Hub.

This marks a significant improvement in how we onboard and evaluate publishers. Previously, companies interested in becoming a Docker Verified Publisher needed to contact our sales team to be considered for the program. While the Docker team still evaluates every single application manually, this change makes it significantly easier to apply to the program.

Within our new self-serve process, you can choose between two different plans that suit your needs as you grow. 

Turn pulls into reach: One badge for all your content

The verified publisher program helps you grow your impact on Docker’s ecosystem. With the badge and priority search ranking due to trusted status, developers evaluating options on Hub see your verified content first.

DVP analytics also help close the gaps you have in understanding your users and product offerings. Summary and trends reports show which repositories are gaining ground and where adoption is shifting across versions and releases. Domain-level reports on Growth turn anonymous traffic into named domains, so the teams already running your software show up in your sales and partner pipeline.

In addition, DVP is designed to mean the same thing across every content type on Hub. Docker Hub isn’t just images anymore. Developers come to Hub for MCP servers, models, sandboxes, agents, and more; everything that’s needed for an agentic stack. DVP offers one review, one badge, one answer to “who published this” no matter what you’re publishing. Whatever you distribute next, your verification comes with you.

What DVP means for developers

The Verified Publisher badge means Docker has manually reviewed the publisher behind that content and confirmed they are who they claim to be. Publishers such as Google, Microsoft, AWS, Datadog, Grafana Labs, n8n, and many more rely on DVP to build trust, increase visibility, and grow adoption of their content on Docker Hub.

Pulling your images from Docker Verified Publishers is a good step towards improving your security posture, but also needs to be paired with other good consumption practices. This means, for example, reviewing the specific artifact you pull, pinning to digests rather than mutable tags, verifying provenance and any signatures at the image level, and checking for CVEs. 

And while publisher verification is an important link in the trust chain, we continue building towards stronger, more secure publishing flows across Docker Hub. Stay tuned for more in this space.

Get started

You can apply to the Docker Verified Publisher Program from the Explore page in Docker Hub. Verification is done by the Docker team, and you’ll get a checkout link as soon as you’re approved.

• Apply to DVP on Docker Hub
• Read the docs

Eliminate Stored Credentials in Your CI/CD Pipelines

TL;DR: Docker now supports OpenID Connect (OIDC) for GitHub Actions. Your workflows can authenticate with short-lived, per-run tokens instead of stored PATs or OATs. No secrets to rotate, no credentials to leak. 

GitHub OIDC connections are available to organizations with Docker Team, Docker Business, or Docker Hardened Images (DHI) subscriptions, as well as organizations enrolled in the Docker Sponsored Open Source Program (DSOS).

Table of contents

• The problem with stored credentials
• Who should use this
• How OIDC connections work
• Getting started
• What doesn’t change
• Learn more

OIDC token exchange flow between GitHub Actions and Docker

The problem with stored credentials

Every GitHub Actions workflow that pushes or pulls images from Docker Hub authenticates with a personal access token (PAT) or organization access token (OAT) stored as a GitHub secret. These credentials are long-lived. Someone has to remember to rotate them. A leaked token grants access to your registry — pulling private images, pushing malicious ones — and that access persists until someone discovers and revokes it. Rotation is manual and does not scale. As pipelines multiply, so do the credentials that need tracking, and stale tokens are a common audit finding.

Who should use this

1. GitHub issues a signed identity token (a JWT) that encodes the repository, branch, environment, and other metadata about the workflow run.
2. The workflow calls docker/login-action, which presents this token to Docker.
3. Docker verifies the token’s signature against GitHub’s public key registry and checks it against rulesets configured in the Admin Console.
4. If the token matches a ruleset, Docker returns a short-lived access token scoped to the resources defined in that ruleset.
5. docker/login-action uses this token to authenticate to Docker Hub. From there, docker pull, docker push, and docker build commands work as usual.

The entire exchange happens without any stored secrets, API keys, or access tokens. The short-lived Docker access token expires in minutes and cannot be reused.

This is the same pattern that AWS and GCP already use for cloud resource access (AWS OIDC for GitHub Actions, GCP Workload Identity Federation). Docker is applying it to container registry access.

Getting started

Setup is a one-time connection in Docker Home plus a small update to your workflow YAML.

Step 1: Create a connection

Sign in to Docker Home, select your organization, and navigate to OIDC connections. Select Create OIDC connection and configure the rulesets that control which repositories, branches, and workflows can access which Docker Hub resources. You can create up to five rulesets per connection. When a workflow triggers an OIDC exchange, Docker checks the token against every ruleset defined in your connection. If a ruleset’s conditions are satisfied, Docker grants access based on the parameters set by that ruleset.

Rulesets use OIDC subject claims to match incoming tokens. You can pin to specific repos and branches as a recommended security best practice:

• repo:my-org/my-repo:ref:refs/heads/main — only the main branch of a specific repo
• repo:my-org/my-repo:ref:refs/heads/release-* — all release branches
• repo:my-org/my-repo:* – all branches of this repo
• repo:my-org/* — any repo in the organization (not recommended)

Copy the connection ID when you are done.

Note: GitHub repositories created after July 15, 2026 use immutable identifiers for default subject claims. For example: repo:octocat@123456/my-repo@456789:ref:refs/heads/main. See the GitHub changelog for more details.

Step 2: Update your workflow

Update your GitHub Actions workflow. Replace <YOUR_CONNECTION_ID> with the ID from the previous step and <YOUR_ORG_NAME> with your Docker organization name:

permissions:
  contents: read
  id-token: write

steps:
    - name: Docker login                                                                                                                                                                 
      uses: docker/login-action@v4 # v4.5.0+                                                                                                                                                                
      with:                           
        username: <YOUR_ORG_NAME>
      env:                                                                                                                                                                               
        DOCKERHUB_OIDC_CONNECTIONID: <YOUR_CONNECTION_ID>

The id-token: write permission lets the workflow request a GitHub OIDC token. The docker/login-action handles the token exchange and Docker login in a single step when DOCKERHUB_OIDC_CONNECTIONID is set. From there, docker pull, docker push, and docker build commands work as usual.details of the incoming claim sub value, which you can use to diagnose why the connection failed.

Step 3: Verify the OIDC connection works

Run your workflow and confirm it completes successfully. If you encounter an error, the Failures tab of the OIDC connection page will show the details of the incoming claim sub value, which you can use to diagnose why the connection failed.

Step 4: Remove the stored credential

After verifying your workflow runs successfully with OIDC, remove the old PAT or OAT from your GitHub repository secrets. You no longer need it.

Migration Checklist

• Create a connection
• Update your workflow
• Verify the OIDC connection works
• Remove stored credentials

What doesn’t change

• Existing PATs and OATs keep working. Organizations can migrate workflows to OIDC connections at their own pace.
• Images, registries, and build workflows are unchanged. OIDC connections only replace the authentication step; everything downstream is the same.
• Local development and non-GitHub CI still use PATs and OATs. OIDC connections are the recommended replacement for GitHub Actions specifically. Other CI providers will follow based on demand.

Learn more

• Learn more about OpenID Connect
• Visit Docker Home to get started
• Read the documentation