TestPyPI sandbox versus production PyPI scoped tokens for credential-isolated CI

Question

Teams need to run package-publishing integration tests in CI without exposing production PyPI credentials. Two documented approaches exist: publish to the TestPyPI sandbox instance, or use a production PyPI scoped API token limited to a single test project.

TestPyPI provides complete credential isolation because it operates on a separate domain with independent accounts, but its retention policy is not guaranteed—projects and files can be removed periodically, which may break long-lived test suites that expect a package to remain installable. Production PyPI scoped tokens restrict write access to one named project, keeping the token from affecting other releases, yet they still target the immutable production index where a version filename cannot be reused, complicating re-publish test flows.

Both options avoid account-wide production credentials, but they differ in durability, immutability constraints, and the operational overhead of token rotation versus sandbox account management.

Which approach better supports a CI pipeline that must re-run the same publish-and-install verification weeks later without manual intervention?
Does the immutability of production PyPI releases make scoped tokens impractical for tests that intentionally re-publish the same version string?
Can TestPyPI account creation be fully automated for ephemeral CI runners, or do email confirmation and CAPTCHA steps require a persistent human-managed account?

Tasadduq Burney · Answer

Answer
Production PyPI scoped tokens are the recommended approach for CI pipelines that must re‑run publish‑and‑install verification weeks later without manual steps.

Confirmed facts

Production PyPI files persist indefinitely and are installable from pypi.org.
Scoped tokens restrict write access to a single named project, avoiding account‑wide credentials.
PyPI rejects re‑uploading the same version filename, requiring a unique version per CI run.
TestPyPI may delete projects or files at any time, so its retention is not guaranteed.
Creating a TestPyPI account typically requires email verification and may involve CAPTCHA, preventing fully automated ephemeral accounts.

Likely explanation
The durability of production packages means a verification job can install the exact version published weeks earlier, whereas TestPyPI’s non‑guaranteed retention makes long‑term verification fragile. Immutability of production releases means you cannot re‑publish an identical version string; each run must use a distinct version identifier, such as a commit SHA or build number.

Steps for a repeatable CI workflow

Create a dedicated test project on production PyPI (e.g., myproj-ci-test).
Generate a project‑scoped API token limited to that project and store it as a CI secret.
In the publish job compute a unique version string, for example version = f"1.0.0+ci.{commit_sha[:7]}.{build_number}.
Upload the distribution with twine upload --repository-url https://upload.pypi.org/legacy/ -u __token__ -p $PYPI_TOKEN dist/*.
In a separate verification job install the exact version: pip install myproj-ci-test==$GENERATED_VERSION.
Optionally set a token expiration policy (e.g., 90 days) and automate rotation.

Missing diagnostic detail
Does your test suite need to verify installation of the exact same version string multiple times (idempotent 1.0.0 installs), or can each run use a unique version identifier? This detail could change the recommendation if idempotent testing is required.

TestPyPI sandbox versus production PyPI scoped tokens for credential-isolated CI

1 answer

Answer

Confirmed facts

Likely explanation

Steps for a repeatable CI workflow

Missing diagnostic detail

Your perspective belongs here.

0 question comments