> ## Documentation Index
> Fetch the complete documentation index at: https://docs.convonexai.tech/llms.txt
> Use this file to discover all available pages before exploring further.

# Publish

> One deliberate step from preview to production — with the evidence in front of you before you press the button.

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](/building/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](/shipping/openapi-and-tests).
