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

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

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

, allowing Python package clients to fetch only metadata from the Simple API during dependency resolution.

Cloudsmith's Python Simple API index now includes .metadata links alongside package distribution files. When a compliant client like uv resolves dependencies, it fetches only the small metadata file for each candidate package rather than downloading the full archive. This allows the full dependency tree to be resolved efficiently upfront.

Previously, Python clients had to download entire packages just to read their dependency metadata. This put unnecessary strain on upstream caches and caused builds to be slow and unreliable.

Customers using Cloudsmith Python repositories with the Python Simple API enabled.

Speed up Python builds with PEP-658 support

Cloudsmith now handles authentication for Docker Hub and Docker Hardened Images (DHI) upstreams using a managed token, removing the need to supply your own credentials during setup. Authenticated requests receive a higher rate limit than anonymous access.

When a Docker Hub or DHI upstream is created without credentials, Cloudsmith uses a managed Docker Hub organization access token (OAT) to authenticate requests on your behalf. Workspace names are shared with Docker to attribute usage when the Cloudsmith-managed token is used.


A pre-configured DHI upstream is also available, so you can start proxying and caching images from the DHI Community tier immediately.


 are minimal, secure, and production-ready container base and application images maintained by Docker. Designed to reduce vulnerabilities and simplify compliance, DHI integrate easily into your existing Docker-based workflows with little to no retooling required.

To access the DHI Select or Enterprise tiers, you must configure the DHI registry as a private upstream with your Docker Hub credentials.

For more information about creating Docker Hub and DHI upstreams in Cloudsmith, see:

Set up Docker Hub and DHI upstreams with Cloudsmith-managed authentication 

Packages from Debian, Alpine, PyPI, and other ecosystems that use native version ranges are now matched against a broader set of OSV advisories, building on existing coverage for SemVer-based ranges.

Users with active vulnerability policies that use the 

 dataset may see more policy matches than before. This is expected: your policies are now being evaluated against a more complete set of advisories. It's broader coverage, not noise.

 for more information on how to access the OSV.dev dataset to create your vulnerability policies.

Vulnerability detection now covers ecosystem-native OSV advisories

Two additional policy evaluation triggers are now available, ensuring that policies are enforced consistently across repositories without manual intervention.

Policy evaluations will now also trigger when:

A policy or policy action is created, edited, or deleted.

 Any change to your policy configuration immediately re-evaluates affected packages against the updated ruleset, so your policy coverage stays current without manual intervention.

 Any package that has not been evaluated against policies within the last 12 hours is automatically picked up for evaluation. This scheduled sweep runs every 12 hours, closing the gap for packages that may have been missed by event-driven triggers or that rely on a time-based value to determine what action to take.

These additional triggers are being rolled out to all early access customers over the next few weeks. They apply to policy-as-code configurations and do not affect legacy policies. An increase in policy matches is expected during this period as packages that were previously unevaluated are assessed for the first time.

These additional triggers complement the existing set, which includes package upload, resync, copy, manual scan, recurring scan, and when Cloudsmith receives updated package data, such as Common Vulnerability Scoring System (CVSS) or Exploit Prediction Scoring System (EPSS) updates.

More events now trigger policy evaluations

A cooldown policy now filters non-compliant package versions from the repository index before package managers ever see them. This provides both security control and a better developer experience: clean resolution to the next compliant version, no build failures, and no waiting.

Malicious packages typically live in public registries for hours before detection. In that window, automated CI/CD pipelines can pull them straight into customer builds. A package cooldown policy closes that gap by enforcing a minimum age requirement on packages before they're available to install.

Previously, cooldowns were enforced at the point of download, meaning a build requesting a version still within the cooldown window would fail to resolve. Now, we’ve moved enforcement to the repository index, filtering out non-compliant versions before package managers see them. Builds resolve cleanly to the first available compliant version, with no iterative build failures.

Non-compliant package versions are filtered automatically:

 Package managers only ever see versions that meet your policy requirements.

 Builds succeed without retries, failures, or workarounds. Developers don't need to worry about the impact of having a cooldown policy in effect.

Enforcement is server side and enterprise wide:

 Security teams configure policies once in Cloudsmith, applied consistently across every consumer of the registry, no per-client configuration required.

 (for example, 3 days) for the repositories and formats you want to protect.

When a package manager requests the index, Cloudsmith evaluates every version against the policy in real time.

 are filtered from the index, and the package manager 

automatically resolves to the first available compliant version

This feature is available in Early Access for Ultra and Enterprise customers.

 to request early access or register interest in additional format support.

Cooldown policies now prevent builds from seeing non-compliant packages

 now support delete. Select up to 100 packages and remove them in a single action. Deleted packages will be moved to 

Delete up to 100 packages at once with multi-select

We've made a series of usability improvements to 

If you haven't yet configured an upstream on a repository, a new streamlined setup makes it easy to connect to one in a single click.

An error tag is now displayed in the table if an upstream encounters a problem, such as invalid credentials or an unreachable address. Connectivity issues are also surfaced directly in the upstream status column.

Each row in the upstreams table now shows the number of indexed packages, and can be expanded to reveal further detail — including the last indexed timestamp, GPG key details, and distributions.

A reindex action is now available for each upstream.

Upstreams can now be updated without re-entering a password when authentication is enabled.

The upstreams table is now sorted in priority order.

For even greater insight into upstream activity, see 

Track and troubleshoot upstream requests with logs

Cloudsmith Changelog