TL;DR — “Deployed” describes a state: the bytes are on a server. “Promoted” describes a decision: a specific version moved one step along a chain, someone with the right to make that call made it, and a log recorded who, what and when. Custom frontends on CodeMonster promote develop → staging → production, one direction, role-gated, with a rollback that deletes nothing. Platform apps publish through a different, simpler lifecycle, described separately below so the two are never confused.
“Deployed” is a state. “Promoted” is a decision.
Most AI app builders stop at deployed: press publish, the app is on a URL, and the URL is the product. That is fine for a demo — it is what a demo is for. What each of them does and does not gate is set out, sourced and dated, on compare.
Software has a second question a demo never has to answer: how did this exact version get in front of these exact users, and who said yes? Answering it needs three things a single publish button cannot give you — a chain with more than one link, roles that decide who may move something along it, and a record that outlives the person who pressed the button.
The rest of this post is those three things, as they exist in the product today.
The chain: develop → staging → production
↩ rollback · owner / editor / viewer · versioned · audited
Custom frontends — the Vite/React apps you build alongside platform apps — get three environments. Each has its own URL, its own environment variables and its own deployment history. Code enters at develop and moves forward only.
The chain is enforced in code, not in a runbook. Develop is reachable only through deploy. Staging and production are reachable only through promote. Ask to skip a tier and the API refuses with a 409. Ask to promote backwards and it refuses with a 400. Nobody can be talked into an exception at two in the morning, because there is no endpoint that grants one.
Promotion also does not copy mystery bytes between buckets. Each environment is rebuilt with its own variable bundle, so the staging build is a staging build and the production build is a production build. A frozen snapshot of the build environment is kept per deploy, which is how “why did v15 break?” gets answered a month later instead of guessed at.
Roles: owner, editor, viewer
Roles are per app, and there are three.
- Owners hold the production buttons: the promotion into it, and the rollback out of it.
- Editors work the first two tiers — deploy to develop, promote to staging.
- Viewers read: the file tree, the versions, the deployment log. They change nothing.
That split maps onto how teams ship. The person who built the thing gets it in front of the client. The person accountable for production presses the last button. Neither has to trust the other’s memory of who agreed to what, because the roles are the agreement.
Rollback that deletes nothing
Rollback in this model is non-destructive. It creates a new deployment pointing at the previous succeeded version. Nothing is deleted, the version you rolled away from is still there, and the head moves atomically when the new deployment completes. The audit trail gains a line; it never loses one.
One honest boundary: rollback is “restore the last known good,” not time travel. Roll back twice and you alternate between the two most recent succeeded versions. If you need to reach further back, you restore the version you want and walk it through the chain again. Versions are immutable snapshots, so every one of them is still there — but restore overwrites the working copy, so commit or export anything uncommitted first.
Production rollback is owner-only, for the same reason production promotion is.
The log is append-only
Every deployment is a row that says which version went to which environment, who triggered it, when, whether it succeeded, what the error was if it did not, and what URL it served. Nothing updates in place. One query answers “what happened, and when?” without reconstruction.
Together with the frozen build snapshot, that gives you forensics you did not have to design: the version, the environment, the variables, the person, the time.
Platform apps publish differently
Apps assembled from platform primitives — objects, forms, workflows, screens — do not travel the chain above. They have their own lifecycle, and it is simpler on purpose.
Current is the working copy; every committed edit bumps its version. Testing and Production are published snapshots the renderer serves to end users. publish-solution copies Current to Testing and Production in one step. There is no separate staging-to-production gate at that level; who sees what inside a published app is governed by groups and permissions, evaluated server-side. Bench holds frozen backup snapshots you can branch from, and it is never published from.
We describe the two lifecycles separately because they are different, and because the fastest way to lose an IT reviewer’s trust is to let a diagram imply a gate that does not exist. Custom frontends have the three-tier promotion chain. Platform apps have one-step publish with permission-gated visibility. Both are audited.
What this means if you show software for a living
If you are a sales engineer or a solutions consultant, staging is the room where the yes happens.
Build in develop with your agent, promote to staging, and put the staging URL in front of the prospect. It stays there as the reference build while you iterate — no credit balance to watch, so the fourth revision costs the same as the first. When the client says yes, an owner promotes to production. The prospect saw that version, and the log proves it. If Tuesday’s change is wrong, roll back Tuesday; Monday’s app is still there and still audited.
The point is not ceremony. It is that “the demo” and “the software” are the same build, moved along a chain, rather than a demo you rebuild as software after the signature.
What this means if you have to say yes
If you are the IT director or the head of engineering approving this, the chain is the answer to three questions you were going to ask anyway.
Who can push to production? Owners, per app, and nobody else — enforced by the API, not by policy. Can we get back? Yes, non-destructively, and the record of doing so is a new row, not an edited one. Can we prove what ran? Yes: append-only deployment log, immutable version snapshots, frozen build environment per deploy.
None of it is bolted on afterwards, and none of it is a feature tier. It is how the chain works for every custom frontend, from the first deploy.
The full mechanics — including the platform-app lifecycle, per-environment variables and the current limits — are on the environments page. The permission and audit story for the person who has to sign is in governance and audit.