Developers

Staging vs production

How Frontpage separates subdomain staging from custom-domain production, and why agents must not publish by default.

Two surfaces

Surface	URL	Updated by	Audience
Staging	`https://<subdomain>.frontpage.host`	`push`, `prompt`, `edit`, editor UI	You, your team, your agents (preview)
Production	Custom domain (when connected), after publish	`frontpage publish` (or Publish in the editor)	End customers on the live domain

What “goes live” means

When you push or finish an agent run, Frontpage builds the site branch and serves it on the subdomain. That is intentional and expected. Subdomains are the staging area.

There is no separate CLI command agents must run to “deploy staging.” After a build finishes, open the subdomain. Optional: frontpage deploy wait blocks until an in-flight build is done so you do not review a stale page. That command does not promote production.

Publish is a deliberate promote

frontpage publish --site <subdomain>

Publish copies the current staging tip to production. Use it when a human has reviewed staging and wants the custom domain updated.

Agent default: never run publish or unpublish unless the user explicitly asked, or the user built an automation that clearly requires autonomous publishing.

Recommended human workflow

Agent or developer pushes changes.
Review https://<subdomain>.frontpage.host.
If good, human runs Publish in the editor or frontpage publish.
If not, keep iterating on staging.

History markers

frontpage history marks tips with S (staging) and P (production). They can differ when staging is ahead of the last publish.

frontpage history --json

Unpublish

frontpage unpublish takes production offline (admin only). Requires --yes when stdin is not a TTY. Agents must not run this unless explicitly asked.