Publishing
Promoting a module from your dev environment to production, and deciding who can see it.
Deploying and publishing are separate on purpose. Deploying builds your code and runs it where only you can reach it. Publishing promotes that build to production and puts the module in front of other people. You can deploy twenty times and publish once.
Publish sits in the project header, next to Deploy, and is available from any tab.
Before you can publish
Two things have to be true, and the dialog tells you which one isn't:
- A successful deployment to dev. There has to be something to promote.
- A Module ID. The Publish button is disabled without one, with a tooltip pointing you at the Overview tab.
The Module ID
This is your module's public name, and it's what people put in their client:
@your-org/your-moduleThe organization half is the handle of the organization that owns the module; you choose the second half. It has the same rules as the project name — 1–50 characters of lowercase letters, numbers and hyphens, no leading or trailing hyphen, no double hyphens — and it has to be free, both within your organization and across every published module's routes. It also can't be an address one of your organization's gateways already holds. A gateway reserves its address the moment it's created, not when it's published, and the reservation outlives the gateway coming off the marketplace — only deleting the gateway frees the name.
Set it on the Overview tab, where it's displayed prominently with an edit button.
Renaming after publishing resets every install
Changing the Module ID of a published module moves it. Installs move to the new ID, but every value users typed in for the module is deleted, along with any link to a vault item (the vault item itself stays), and every MCP client's sign-in for it is revoked. Each user has to point their client at the new address, sign in again and set the module's credentials up again. Everyone who installed it gets an email saying so. Credit grants that name the old ID stop paying for it, and the organizations that fund them are emailed too.
The old address stops serving the module as soon as you rename it. For 14 days the old store page redirects to the new one, and signing in at the old address shows where the module went; after that, neither points to the new ID. No other module can ever take the old ID. Pick the name you want before the first publish.
Choosing what to publish
Three independent checkboxes, and you can tick any combination:
| Option | What it does |
|---|---|
| Update listing | Republishes your marketplace listing — name, tagline, icon, tags, store page and required secrets |
| Deploy new code | Promotes the current dev build to production |
| Bump version | Sets a new version number, pre-filled from your project version |
Fixing a typo in your description is listing only, and nothing about your running code changes. Shipping a fix is code only, and your listing stays as it was.
Bindings crossing over
Production is a different worker from dev, with its own bindings. When you publish code, the dialog reconciles them:
- Variables are listed with checkboxes. The ones you select are copied across.
- Secrets can't be copied — Cloudflare will not give a secret's value back once set. The dialog lists any that exist in dev but not production and warns you, and you add them yourself on the Deployments tab afterwards.
Take that warning seriously. A module published with a secret missing in production deploys successfully and then fails on the first real call.
Who can see it
Visibility is set on the Overview tab, under Access & ownership, on the same ladder you publish and unpublish from: moving off Project opens the publish dialog at the rung you picked, and moving back to Project unpublishes the module.
| Setting | Effect |
|---|---|
| Project | Not published. Only the project's Inspector can call it. |
| Public | Listed on the marketplace. Anyone can find, install, and call it. |
| Private — personal projects | Hidden from the marketplace. Only you can install or call it. |
| Internal — team projects | Hidden from the marketplace. Only members of the owning organization whose access lets them use it can find, install or call it. |
Private and Internal are the same underlying setting; the label changes because a personal organization has one member, so whoever can use it there is you.
On a live module, this is immediate
Switching a live module away from Public takes effect at once. It leaves the marketplace, and everyone outside the organization is denied on their next call — including people who already installed it and connections that are open right now. The portal asks you to confirm before applying it.
Ownership
Access & ownership also shows which organization owns the module, and can transfer it to another one. Transferring takes what deleting the module here and creating it there would: Delete on the module, and Create modules in the destination. In the destination you then have the same access to it as to a module you created there. Publishing, unpublishing and changing who can see the module take Publish on it, and setting or changing its Module ID takes Rename. An owner or admin of the organization holds all three on every module, and the Admin access level gives them on one module; the Maintain level that creating a module gives you does not.
A Module ID always sits under its owner's handle, so a transfer changes it: @acme/weather moved
to Globex becomes @globex/weather. For a published module that is the same move as
renaming it: installs follow, everything users set up for it is reset, and the
old ID redirects for 14 days. The email each user gets says who owns it now. The module sees most
users as new ones, because the default userId
belongs to the owning organization; only users who chose one id everywhere keep theirs. The
project's links to the old organization's vault items are removed; the values already copied onto
the module stay until you change them.
There is no review
Publishing takes effect when you click it. Nothing queues, nobody approves, and no scan runs between you and the marketplace. A module goes from draft to published, and back to draft if you unpublish it. That's the whole lifecycle.
Updating
Change your code, deploy to dev, check it in the Inspector, publish again. Each publish is the same three checkboxes, so an update can be code, or a listing change, or a version bump, or all three.