Integrations/GitHub Actions

Publish and manage artifacts directly from GitHub Actions

GitHub Actions drives your builds. Cloudsmith governs what those builds produce. Connect Cloudsmith to your GitHub workflows using the official Cloudsmith CLI Action. Teams publish packages to secure, policy-enforced repositories straight from their pipelines, authenticate with OIDC instead of long-lived secrets, and pull dependencies through upstream caching without touching public registries directly. Every artifact Cloudsmith stores is scanned, governed by policy, and available for distribution worldwide across 600+ edge PoPs.

How we support GitHub Actions

Cloudsmith plugs directly into GitHub workflows to give your pipelines a governed, secure destination for every artifact they produce.
    One-step publishing
    Use the official cloudsmith-io/cloudsmith-cli-action to install the Cloudsmith CLI and push packages to any Cloudsmith repository in a single workflow step, supporting all 30+ artifact formats.
    OIDC authentication
    Authenticate workflows with OIDC instead of stored API keys. Cloudsmith exchanges a GitHub-issued identity token for a short-lived credential, so no secrets need to be rotated or stored in your repository.
    Policy enforcement at publish
    Every package pushed from GitHub Actions lands in a Cloudsmith repository where vulnerability scanning, license checks, and OPA Rego policies run automatically before the artifact is made available downstream.
    Upstream caching
    Proxy public registries through Cloudsmith so your workflows pull dependencies from a governed cache. Builds stay fast even when upstream registries are slow or unavailable.
    Full audit trail
    Every push and pull triggered by a GitHub Actions workflow is recorded in Cloudsmith's client and audit logs, giving you complete provenance from commit to deployed artifact.

Why teams integrate Cloudsmith with GitHub Actions

GitHub Actions runs the build. Without Cloudsmith, what happens to the artifact after that build completes is where teams lose control, security, and visibility.
Without CloudsmithLong-lived API keys are stored as GitHub Secrets and shared across workflows. Any breach of those secrets exposes your artifact repositories indefinitely, and rotating them requires manual updates across every repo.
With CloudsmithWorkflows authenticate with OIDC. Cloudsmith issues a short-lived token scoped to the job, and it expires automatically. No keys to store, rotate, or audit.
Without CloudsmithBuild artifacts are uploaded to GitHub's temporary storage, which has per-repo storage quotas, 90-day expiry limits, and no vulnerability scanning. Teams hit quota errors and lose artifacts with no long-term registry to rely on.
With CloudsmithArtifacts are published to Cloudsmith repositories with no expiry, persistent storage across regions, and immediate vulnerability scanning on every package pushed from the pipeline.
Without CloudsmithThere is no policy layer between what GitHub Actions builds and what gets distributed. A vulnerable or non-compliant package can be published and consumed before anyone notices.
With CloudsmithOPA Rego policies and vulnerability rules run at publish time. Packages that fail checks are quarantined automatically, keeping non-compliant artifacts out of downstream environments.

Frequently asked questions

  1. Add the cloudsmith-io/cloudsmith-cli-action step to your workflow. It installs the Cloudsmith CLI and authenticates it automatically using OIDC or an API key. After that, run cloudsmith push with your format, namespace, repository, and the path to the built package.

  2. OIDC lets your GitHub Actions workflow prove its identity to Cloudsmith using a short-lived token issued by GitHub, rather than a static API key stored as a secret. This eliminates the risk of long-lived credential exposure and removes the overhead of secret rotation. It is the recommended authentication method for CI/CD pipelines.

  3. Yes. You create a Cloudsmith service account in your workspace, configure an OIDC provider on it with the appropriate GitHub claim mappings, and then reference the service account slug in your workflow. Full setup steps are documented at docs.cloudsmith.com/authentication/openid-connect.

  4. The Cloudsmith CLI Action supports all formats available in the Cloudsmith CLI, which covers 30+ formats including Docker, npm, PyPI, Maven, NuGet, Helm, Debian, RPM, Cargo, Go, and more. Any format Cloudsmith supports can be published from a GitHub Actions workflow.

  5. Every package pushed to a Cloudsmith repository is automatically scanned for known vulnerabilities using continuously updated security databases. You can configure vulnerability policies to quarantine or block packages that exceed your severity threshold before they are accessible to downstream consumers.

  6. Yes. Cloudsmith supports upstream proxying for all major public registries. You configure your workflow to pull from a Cloudsmith upstream-backed repository, and Cloudsmith caches the packages on first download. Subsequent workflow runs are faster and protected from upstream outages or package removals.

  7. Yes. Pass your Cloudsmith API key as a GitHub Actions secret and reference it in the cloudsmith-cli-action using the api-key input. OIDC is strongly recommended for security, but API key authentication is fully supported for legacy setups or environments where OIDC is not available.

  8. Policies are configured on your Cloudsmith repositories, not on the pipeline itself. When a workflow pushes a package, Cloudsmith's policy engine evaluates it against your vulnerability rules, license policies, and OPA Rego-based Enterprise Policy Manager rules automatically. You do not need to add any extra workflow steps.

  9. Cloudsmith's client logs and audit logs record every push event, including the credential and service account used. When combined with OIDC, the token claims provide a direct trace back to the specific GitHub repository, workflow, and branch that triggered the push.

  10. Cloudsmith does not impose arbitrary artifact count limits. Storage and throughput are governed by your Cloudsmith plan. Unlike GitHub Actions' built-in artifact storage, which applies per-repository quotas and 90-day expiry, packages stored in Cloudsmith repositories persist until you choose to delete or apply retention rules.

Integrations

Discover more Cloudsmith Integrations