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.

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.

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.

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.

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.

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.

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.

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.

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.

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.