Cloudsmith supports NuGet, Docker, Maven, and Helm feeds that can each be registered as separate external feeds in Octopus Deploy. You configure each format independently in the Octopus Library under External Feeds, pointing to the relevant Cloudsmith repository URL for that format.

Cloudsmith supports three authentication methods for Octopus external feeds: entitlement tokens embedded in the feed URL, HTTP Basic Authentication using your Cloudsmith API key as the password, or username and password credentials entered in the Octopus feed credentials section. Private repositories require one of these methods; public repositories need no credentials at all.

Yes. Cloudsmith works identically as an external feed for Octopus Cloud and self-hosted Octopus Server instances. The feed configuration steps are the same for both; the only difference is where you navigate to in the Octopus web portal to register the feed.

Cloudsmith complements Octopus Deploy rather than replacing it. The Octopus built-in feed is write-only and can only be consumed by Octopus itself. Cloudsmith gives you a separate, fully governed repository that your CI pipeline, local development tooling, and Octopus can all access, making it the shared source of truth for all your deployment artifacts.

Cloudsmith scans packages for vulnerabilities automatically on upload. You can configure quarantine policies that prevent flagged packages from being downloaded, meaning Octopus Deploy cannot pull a vulnerable package to a deployment target until the issue is resolved or an explicit exception is granted by a team admin.

Common patterns include a single multi-format repository used as the external feed for all Octopus projects, or separate repositories per environment tier (development, staging, production) with promotion policies controlling which package versions progress between them. Teams deploying to Kubernetes often have a dedicated Helm repository alongside a Docker registry, both registered as separate Octopus external feeds pointing to Cloudsmith.

Yes. Cloudsmith's client logs and audit trail record every download event including the credential or token used, the requesting IP, and the timestamp. You can correlate these download events with your Octopus deployment history to trace exactly which release consumed each package version and from which target.

Octopus external feed triggers for automatic release creation currently support container image and Helm feeds. When Cloudsmith is registered as a Docker or Helm external feed, Octopus can poll it for new package versions and automatically create releases. For NuGet and Maven feeds, teams typically trigger releases from their CI pipeline after pushing to Cloudsmith.

Any CI tool that can push to a NuGet, Docker, Maven, or Helm registry can publish to Cloudsmith as part of a pipeline that then triggers Octopus deployments. Common configurations include GitHub Actions, GitLab CI, Jenkins, and Azure DevOps publishing build artifacts to Cloudsmith, with Octopus consuming from the same repository to deploy to target environments.

Unlike the Octopus Cloud built-in feed which enforces storage quotas that can silently truncate packages when limits are reached, Cloudsmith provides elastic storage backed by a global CDN. You control retention through Cloudsmith's configurable retention policies without being constrained by Octopus-imposed caps, and older package versions remain available for rollback deployments at the same download speed as the latest version.