Workspace owners can grant each of the following privileges separately, without giving members the Manager or Owner role:

View workspace usage data, including artifact data and package delivery quotas

View workspace OpenID Connect (OIDC) settings

Only workspace managers and owners could previously view this data. Each privilege applies to all members of the workspace.

You can configure these in your workspace settings under 

Give members read-only access to billing, usage, and OIDC data

When an exposed Cloudsmith API key is detected in a GitHub repository, the email notification sent to the affected Cloudsmith user and workspace owners now lists every location the key was found in GitHub, with a direct link to each detection.

Pull request titles, descriptions, comments, and reviews

The Cloudsmith workspace audit log records an 

 event for each detection, with the masked key and detection location.

Exposure detection for Cloudsmith API keys in GitHub runs through the 

GitHub secret scanning notifications now link to each detection location

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 

Cloudsmith Changelog