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 comes from the project; 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 breaks installs
Changing the Module ID replaces the route rather than aliasing it. The old address stops resolving, and everyone who already added the module has to update their configuration. 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 store page | Republishes your marketplace listing — description, category, icon, media |
| 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 store page 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, and is independent of whether you've published:
| Setting | Effect |
|---|---|
| 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. |
| Organization — team projects | Hidden from the marketplace. Only members of the owning organization can install or call it. |
Private and Organization are the same underlying setting; the label changes because a personal organization has one member, so "only the organization" and "only you" are the same sentence.
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
The Access section also shows which organization owns the module, and can transfer it to another one. Transferring requires you to be an owner or admin of both the current organization and the destination, so you can't push a module into an org you don't administer. Organization members without an admin role can't change visibility or ownership at all.
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 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.