Yes. A PyPI pending publisher lets you set up trusted publishing for a project that does not exist yet. Your first successful publish from the configured workflow creates the project, so you never mint an API token or upload a "priming" release by hand.
What a pending publisher is
A trusted publisher tells PyPI which CI workflow may upload for a project, using short-lived identity tokens instead of a stored secret. Normally you configure it from the project's own page, which assumes the project already exists.
A pending publisher solves the chicken and egg problem. You register the same kind of rule, plus the name of the project to be created, from your account instead of from a project. The PyPI documentation says the first publish creates the project, and the pending publisher then becomes a normal one.
Steps
- Sign in to PyPI and open the Publishing link in your account sidebar. It is not on a project sidebar, because there is no project yet.
- Pick your provider. The docs list GitHub Actions, Google Cloud, ActiveState and GitLab CI/CD. For GitLab, only gitlab.com projects are supported.
- For GitHub, enter the repository owner, the repository name and the workflow file name that will publish.
- Enter the project name you want PyPI to create.
- Optionally add an environment name. The docs say it is optional but strongly recommended for GitHub and GitLab.
- Click Add, then run your release workflow.
The catch: it does not reserve the name
The docs are explicit that a pending publisher does not create a project or reserve its name until it is used. If someone else registers that name first, your pending publisher is invalidated.
That has a practical consequence for a solo developer. Do not register the pending publisher months ahead and forget about it. Register it when the workflow is tested and the release is close. Check the name with a search before you start, and see our post on why a PyPI project name may not be available if you hit a conflict.
The page does not say whether a pending publisher expires, so treat that as unknown and do not rely on it either way.
Why this is better than a first upload with a token
| Approach | Secret stored? | Name risk | Extra steps |
|---|---|---|---|
| Manual first upload with an API token | Yes, until you delete it | Name is yours after upload | Create token, store it, remove it, then switch to trusted publishing |
| Pending publisher | No | Name not held until first publish | Register once, then publish from CI |
If you never create the token, there is nothing to leak from a laptop, a CI secret store or a shell history. Compare this with the older flow described in how PyPI trusted publishers work on GitHub Actions.
A short checklist before the first run
- Tag the release only from a protected branch, and keep the publish job separate from the build job.
- Use an environment on the publish job so you can add an approval step later.
- Test the upload path on TestPyPI first. Our post on testing a Python release on TestPyPI shows how.
- Run your own dependency scan before tagging. The free scan at gold.safeguard.sh/scan gives a quick view of what your package pulls in.
Quick check
Does a pending publisher claim my project name?
No. According to the PyPI docs, it does not create the project or reserve the name until it is used to publish. Another user can take the name and invalidate it.
Do I need a manual first upload before trusted publishing works?
Not with a pending publisher. The first successful publish from the configured workflow creates the project.
Sources
Last reviewed: 19 October 2026.
