The private Python registry built for scale

Cloudsmith provides feature-complete private Python repositories with cloud-native performance for your distributed teams. Store and control your Python packages and wheels with Cloudsmith, and give your teams access using native tools including Pip, Poetry, Flit, Hatch, Shiv.

Universal format support

Python is one of our most-used formats. Cloudsmith is the registry built by Python engineers, for Python engineers.

• Use Python + 30 other formats in a single registry
• Store ML models, datasets, and wheels side by side
• Manage your entire software supply chain from one platform

How we support Python

Cloudsmith is itself written in Python. We know what it takes to run a globally-performant, secure Python registry at scale - and we have built exactly that for you.

Native tooling support

Works with pip, Poetry, uv, Twine, Flit, Hatch, Shiv, and every other major Python packaging tool. Configure your index URL once and your existing workflows run without modification.

Upstream proxying and caching

Proxy PyPI and other upstreams through Cloudsmith to eliminate dependency confusion, typosquatting, and maintainer-deletion risks. Packages are cached locally so builds stay reproducible even when upstream changes.

Malware and CVE scanning

Every package is scanned on upload. Set policies to quarantine, block, or alert on packages with low, medium, or critical severity vulnerabilities before they reach your teams.

Zero-trust access control

SAML, SSO, OIDC, and SCIM integrations give you full control over who and what can push or pull. Use scoped entitlement tokens for read-only distribution and OIDC for keyless CI authentication.

Global distribution at any scale

Packages are served via 600+ edge PoPs worldwide. Cloudsmith's cloud-native, fully-managed infrastructure scales automatically with demand - no instances to configure, no downtime during spikes.

Why teams choose Cloudsmith for Python

The public PyPI index is a great starting point - but production Python teams need isolation, security controls, and performance that public registries cannot offer. Cloudsmith gives you all three.

Without Cloudsmith Using --extra-index-url leaves your builds exposed to dependency confusion attacks. Pip resolves packages from both indexes simultaneously, and a malicious actor can claim your internal package name on PyPI to hijack installs.

With Cloudsmith Point pip at Cloudsmith with --index-url and proxy PyPI through your private repository. Resolution happens in one place, under your control, with no exposure to public namespace collisions.

Without Cloudsmith Pulling directly from PyPI during CI means your builds depend on external availability. A PyPI outage, a maintainer yanking a version, or a typosquatted package can break pipelines at any time.

With Cloudsmith Cloudsmith caches all proxied packages locally. Once a version is pulled, it is served from Cloudsmith regardless of what happens upstream - builds stay reproducible and pipelines stay green.

Without Cloudsmith Self-hosted registries like devpi require your team to manage servers, upgrades, SSL, and availability. Engineering time goes into keeping the registry alive rather than shipping software.

With Cloudsmith Cloudsmith is fully managed. Scaling, patching, and availability are handled for you. Your team gets a registry that just works, backed by a team of engineers who run Python infrastructure every day.

Signs you're ready to switch to Cloudsmith for Python

If your current Python registry is slowing down your pipelines, creating security blind spots, or demanding ops time to keep alive, Cloudsmith is the upgrade your team needs.

No vulnerability scanning on inbound packages

If packages arrive in your repo without being checked for CVEs or malware, you are trusting PyPI to protect you. Cloudsmith scans every package on upload and lets you enforce policy automatically.

Dependency confusion exposure from --extra-index-url

Many teams use --extra-index-url as a workaround, unknowingly opening themselves up to namespace hijacking. Cloudsmith's upstream proxying model eliminates this attack surface entirely.

Self-hosted registry stealing engineering time

Maintaining devpi or a custom PyPI server ties up engineers who should be building product. Cloudsmith takes the ops burden off your team completely.

Slow installs for distributed or remote teams

If your registry is single-region, engineers outside that region feel it in every pip install. Cloudsmith's 600+ edge PoPs serve packages from the closest point to every developer.

Python packages siloed away from other formats

If your Python registry is separate from your Docker images, Helm charts, and ML models, you have fragmented visibility and no unified access control. Cloudsmith consolidates everything in one place.

Get started with Python on Cloudsmith

Frequently asked questions

1. Which Python packaging tools does Cloudsmith support?

• Cloudsmith supports all major Python packaging tools including pip, uv, Poetry, Twine, Flit, Hatch, and Shiv. It implements the PEP 503 Simple Repository API, so any tool that speaks that protocol works without modification. You configure your index URL once and your existing workflows run as-is.

2. Should I use --index-url or --extra-index-url with Cloudsmith?

• Always use --index-url, not --extra-index-url. When you use --extra-index-url, pip resolves packages from both your private registry and PyPI simultaneously. This exposes your builds to dependency confusion attacks, where a malicious actor publishes a package with the same name as your internal package on PyPI and pip resolves the wrong one. With Cloudsmith's upstream proxying configured, --index-url is all you need: public packages are fetched through your Cloudsmith repository transparently.

3. How does upstream proxying work for Python packages?

• You configure a Python upstream in your Cloudsmith repository pointing at PyPI or another index. When a pip install requests a package that is not yet in your repository, Cloudsmith fetches it from the upstream, caches it as a first-class local package, and serves it. On subsequent requests it is served directly from Cloudsmith. This eliminates external dependency on PyPI availability and makes your builds fully reproducible.

4. Does Cloudsmith scan Python packages for vulnerabilities?

• Yes. Every package pushed to Cloudsmith is scanned for CVEs and malware on upload. You can configure policies to automatically quarantine, block, or alert on packages that exceed a chosen severity threshold. This applies to both packages you publish directly and packages fetched via upstream proxying.

5. How does Cloudsmith handle authentication for pip and CI pipelines?

• Cloudsmith supports multiple authentication mechanisms. For human users, SAML and SSO keep access tied to your identity provider. For CI pipelines, Cloudsmith supports OIDC-based keyless authentication, meaning your GitHub Actions or GitLab CI jobs can authenticate without storing long-lived secrets. You can also use scoped entitlement tokens with read-only permissions for distribution use cases. Credentials are passed to pip via the standard netrc file or inline in the index URL.

6. Can I store both .whl and .tar.gz distributions in Cloudsmith?

• Yes. Cloudsmith stores all standard Python distribution formats including built distributions (.whl), source distributions (.tar.gz), and legacy egg files. You can upload multiple distributions for the same package version, exactly as you would to PyPI, and pip will select the appropriate distribution for the target platform.

7. Why is Python one of Cloudsmith's most widely-used formats?

• Python's ubiquity across data engineering, ML, web backends, DevOps tooling, and scripting means almost every engineering team has Python packages to manage. Cloudsmith itself is written in Python, so we have built our registry with a deep understanding of the ecosystem's packaging quirks, dependency resolution edge cases, and performance requirements. That experience is directly reflected in the reliability and correctness of our Python support.

8. How do I migrate from devpi, Artifactory, or a self-hosted PyPI to Cloudsmith?

• Cloudsmith's import tooling supports bulk migration from existing Python registries. You can configure a Python upstream pointing at your current registry, which causes Cloudsmith to index and cache your existing packages automatically. Alternatively, you can use the Cloudsmith CLI to script a batch upload from a local package directory. Once migrated, you update your pip configuration to point at Cloudsmith and your teams see no change in workflow.

9. Does Cloudsmith support uv, the fast Python package manager?

• Yes. uv implements the PEP 503 Simple Repository API and works with Cloudsmith out of the box. You point uv at your Cloudsmith repository index URL and it resolves and installs packages exactly as it would from PyPI, with all the speed benefits uv provides. Cloudsmith's edge network means the network hop is fast regardless of where your developers or CI runners are located.

10. Can I store Python packages alongside Docker images and ML models in the same Cloudsmith account?

• Yes. Cloudsmith supports 30+ formats in a single platform. Your Python packages, Docker container images, Helm charts, Conda environments, and ML model artifacts all live under the same organisation, share the same access control policies, and appear in the same audit logs. This gives you unified visibility and governance across your entire software supply chain rather than managing separate registries for each format.