You can now apply cooldown policies to Cargo packages, protecting your supply chain from newly published versions that may carry malware or have not yet undergone sufficient community scrutiny.

You can create cooldown policies via the Cloudsmith API, Terraform provider, and web app.

This feature is available for Ultra and Enterprise customers using policy management with policy as code.

Cooldown policies are now supported for npm, Python, Go, Maven, NuGet, Conda, Docker, and Cargo. For more information about using cooldown policies, see 

Cooldown policies now support Cargo

You can now apply cooldown policies to Conda and Docker packages, protecting your supply chain from newly published versions that may carry malware or have not yet undergone sufficient community scrutiny.


You can create cooldown policies via the Cloudsmith API, Terraform provider, and web app.

Cooldown policies are now supported for npm, Python, Go, Maven, NuGet, Conda, and Docker. For more information about using cooldown policies, see 

Cooldown policies now support Conda and Docker

See how published packages are being consumed - downloads, entitlement token use, and client logs - without leaving the Broadcasts app.

See how many public, open source, and private packages are currently broadcasting and how many entitlement tokens (authentication tokens used to track and control package downloads, often issued per customer) have been active this billing cycle, alongside usage by repository and your most-downloaded packages.

An interactive world map shows download distribution, with a sortable table of usage and request counts by country. Filter by usage period, date range, country, and broadcast.

View a timestamped event stream of package requests, which you can filter by status code, package format, IP address, country, and more.

Track downloads, token use, and client logs in the Broadcasts app

Library registries provide a vendor-curated feed of open source packages. Packages may be pre-vetted, rebuilt from source, and security scanned by the vendor. For details on which of these features are available for a specific registry, see the latest documentation for the registry vendor.


Currently supported quick configure vendors:

Pick a vendor and library, name the upstream, and add your credentials - Cloudsmith fills in the proxy URL for you.

Other library registries can still be added as upstreams by using manual configuration. To register interest in additional quick configure vendor support, please 

Quickly configure library registries as upstreams with the new Libraries tab

Cloudsmith now supports the Nix format, letting you host a public or private Nix binary cache, complete with Ed25519-signed packages and upstream proxying and caching against NixOS release channels. Your existing 

 workflows point directly to Cloudsmith, with no new upload tooling required, and no self-hosted cache such as 

Nix packages are content-addressed by store path rather than name and version, so packages are pushed to Cloudsmith using the native 

 command instead of a CLI or website upload:

 flag is required because a locally built store path is unsigned; Cloudsmith signs it server-side using the repository's Ed25519 signing key.

Cloudsmith signs on every read rather than at upload, so a key rotation applies to all packages immediately with no backlog to re-sign, and multiple keys can be valid at once.

To consume packages, add the repository's public key to 

 in your Nix configuration (or per-invocation via 

). Without it, Nix will refuse to substitute packages even though the HTTP request itself succeeds.

A Nix upstream points at a single NixOS release channel, for example, 

When a requested store path isn't cached locally, Cloudsmith fetches it from the configured channel, caches it, and serves it signed with the repository's key.

 To proxy multiple releases, configure one upstream per channel.

Nix always resolves a package's full dependency closure before installing. On NixOS channels, dynamically-linked packages resolve to a 

 build whose closure includes a GCC bootstrap intermediate (

) that isn't published in the channel's manifest, so Cloudsmith cannot index or serve it. As a workaround, configure 

 as an additional fallback substituter alongside your Cloudsmith repository.

The Nix format is available in Early Access. For more details, see the 

New format: Nix, with upstream support for NixOS

Go upstreams can now point to any GOPROXY-compatible module proxy, in addition to the public mirror at 

. This lets you proxy and cache Go modules from private proxies, such as the Buf Schema Registry (BSR), giving you one place to manage, secure, and distribute these Go modules alongside the rest of your organization’s artifacts.

Configure Go upstreams for any GOPROXY-compatible proxy

Following early access, policy management - Cloudsmith's policy-as-code system for enforcing rules across your software supply chain - is now generally available across the web app, API, and Terraform provider. This includes:

 write your own logic in Rego, tailored to your specific security and compliance requirements

 policies are evaluated on package upload, and re-evaluated automatically as policies or threat intelligence changes

 hold new package versions back from consumers for a set window before they're trusted

 pre-built starting points so you don't need to write Rego from scratch

 a full audit trail of every policy evaluation, viewable in the web app or downloadable via API

In addition to writing policies that act on package metadata, you can also write policies using Cloudsmith's continuous risk detection, which is also 

Policy management is available as an add-on for Ultra and Enterprise plans. Reach out to your account team to get started.

A separate set of baseline standard policies is included in both plans: CVE, license, package deny, and — newly added — malware policies. The package search field is no longer available when creating vulnerability and license policies in the web app, API, or Terraform. Existing policies using it are frozen and cannot be edited, but remain in place and continue to evaluate.

Policy management and baseline standard policies now live together under 

Creating policies as code in the Cloudsmith web app

For more details about Cloudsmith policy management, see:


Policy management is now generally available

Every package in your workspace is now checked automatically against known vulnerabilities and malicious packages, with no scheduled or manual rescans required. This is powered by 

, which has driven policy evaluation since early access and now also replaces Trivy as the data source shown in the web app and API.

results appear in the web app's workspace, repository, and package-level compliance views, alongside the existing API.

the OpenSSF Malicious Packages feed, added to Cloudsmith in 

, now also flags packages directly in the web app and API.

duplicate advisory records are grouped into one, reducing noise in compliance reviews.

results are sorted by severity across compliance views.

vulnerability detection now covers CRAN, plus Debian/Ubuntu, RPM (Red Hat, AlmaLinux, Rocky Linux), and Alpine packages, whether uploaded individually or bundled in a Docker image.

Detection runs automatically for every supported package format in your workspace, with no configuration required. Cloudsmith refreshes threat intelligence every 5 minutes, and whenever a new or updated record could affect packages already in your workspace, it checks for a match automatically, without requesting a rescan.

Packages are matched to advisories on a shared package URL (PURL). Cloudsmith supports SemVer and ecosystem-native version ranges when matching; see our 

 on ecosystem-native OSV advisory support for more.

The same vulnerability often has multiple records from different upstream databases. Cloudsmith groups these and surfaces one primary record per vulnerability, so counts stay accurate and reviews stay focused. See the Cloudsmith 

 to learn how the primary record is selected.

Packages are sorted by severity, highest first: Malware, then Critical, High, Medium, Low, and Unknown.

Policies can act on this data automatically, quarantining or flagging a package the moment it matches, without manual review. This data has been actionable in policy management with policy as code since we first added it to the platform in early access, and nothing changes for policies you've already built. See the Cloudsmith 

 to learn more about defining policies against this data.

Trivy-based scan results remain available in the legacy web app and via existing API endpoints for now. Trivy will be deprecated in a future release; we'll share migration details ahead of that change.


For more details about continuous risk detection, see 

Continuous risk detection is now generally available

The policy editor now flags Rego problems as you write, so mistakes surface before you save rather than after. In the web app, errors appear inline in the editor and in the error panel; autocomplete also suggests schema fields as you type.

When a policy is saved, the web app and API return errors for:

Type mismatches and incorrect argument counts

Restricted variables in index-applicable policies

The web app editor checks three additional things the API does not: a warning when a policy omits 

 or a match rule, inline highlighting for malformed Rego that doesn't block saving, and autocomplete for schema field names.

Catch policy errors before you save

The Cloudsmith CLI now ships as a standalone, self-contained binary for Linux, macOS, and Windows. This eliminates its dependency on a local Python environment. The CLI includes a new one-line installer, a refreshed Homebrew tap and Docker image, and updated GitHub Actions, Azure DevOps, and CircleCI integrations.

The standalone binary bundles everything it needs at runtime. Installation is now a single download-and-verify step that behaves identically across platforms and CI providers.

Previously, the CLI was distributed primarily as a Python zipapp (

), which requires a compatible Python runtime on any machine and CI runner that uses it. The dependency on a local Python environment often creates extra setup steps, could slow down pipelines, and is susceptible to breaking when the runner's Python version changes.

For each CLI release, we now publish platform-specific binary archives with SHA-256 checksums, attached to a GitHub release and pushed to Cloudsmith. Linux archives also ship a detached GPG signature.

The standalone binaries replace the cloudsmith.pyz zipapp, which will be deprecated.

There are 4 supported installation methods:

 for Windows. The install script detects the platform, downloads the right archive, verifies its SHA-256 checksum, and installs the CLI atomically. Each release also attaches a SHA256SUMS file for verifying the scripts themselves. For reproducible CI builds, pin a specific version instead of latest.

: 
The tap now installs the standalone binary and no longer depends on Python. Existing installs upgrade transparently with 

brew install cloudsmith-io/cloudsmith-cli/cloudsmith

: 
The official cloudsmith/cloudsmith-cli 

 on Docker Hub now ships the standalone binary on a plain Alpine base.

 
If you prefer to run in your own Python environment, you still can do so, via 

Each CI/CD integration for the Cloudsmith CLI now installs the standalone CLI and supports API key and CLI-native OIDC authentication, with no Python or additional dependencies on the runner. 

These are major releases with breaking changes. Existing integrations will continue to work normally until you update to v1.20.0.

For migration steps and examples, see the guide for your integration:

: 
Cloudsmith now publishes our CLI artifacts (binaries, Docker images, and Python wheels) to the 

 repository. We are deprecating the existing 

 repository, so you should update any tooling that pulls from the deprecated repository.


The new CI/CD integrations for GitHub Actions, Azure DevOps, and CircleCI orb are major releases with breaking changes. Update your integrations with the migration guide for each.


 handles the upgrade transition automatically. After upgrading, you may have an orphaned python@3.10 dependency, which you can remove with 

Cloudsmith Changelog