Skip to main content
Publishing puts your app in front of real people at a permanent production URL. It’s the one step in Creator that isn’t reversible by just chatting, so the publish screen is built around a single idea: you see the evidence before you decide.

​
The ledger comes first

Pressing Publish in the workspace opens the publish dialog, and the first thing in it is the verification ledger — one sentence stating the verdict (“All 7 promises were checked, and they held.” / “1 promise did not hold, and 2 were never checked.”), a proportion bar, and the counts:
  • proved by tests — machine-verified promises
  • confirmed by you — promises you judged yourself
  • did not work — checks that ran and failed, each listed by name under “Ran and did not pass”, with a link to review them in the Proof tab
  • not checked — promises nobody checked, each listed under “Going live without”
The failures and gaps are listed, not just counted — “4 not checked” is a number a reader rounds to zero; the four sentences underneath are what makes the gap real enough to act on. What held is available too, collapsed behind “Show what held.” The ledger informs; it doesn’t block. Shipping with a known gap is a legitimate choice people make on purpose — the screen exists so it’s never an accident.

​
The one exception: broken security promises

If a security-relevant promise — one about who can reach data, or whether signing in works — is known broken, pressing Publish diverts once to a second look. It names the failure, states plainly that publishing puts it in front of real people, and offers two buttons: Back (go fix it — the primary choice) and Publish anyway (available, deliberately styled as the secondary one). This happens exactly once per publish, only for security failures, and it is informed consent — not a veto. You can always publish; you just can’t do it by muscle memory past a known security hole.

​
What publishing actually does

Publishing runs in the background after you confirm:
  1. Your app’s backend capabilities are hardened for production — promoted from their sandboxed state to production configuration. The dialog shows which ones, as context.
  2. The app itself is deployed and wired to its public production URL.
  3. The dialog reports “Publishing started — your app is going live”; you can close it, and the workspace shows progress and the live URL when it’s ready.
If a publish fails, you’ll see the error and a Try again — a failed attempt never locks you out of retrying. The production app is separate from your preview: the preview keeps sleeping and waking with you as you work; the published app stays up for your users. Publishing again later ships the current state of the build.

​
Take the contract with you

The publish dialog also offers your app’s API as downloads — the OpenAPI contract and a Bruno test collection. See Your API contract & test collection.