Releases, previews & rollback

InfoEmu static hosting is built around one idea: every publish is an immutable release, and going live is just a pointer move. Understanding this model explains why deploys are safe and why rollback is instant.

Releases are immutable

When you publish — whether you upload a built site or send raw content for InfoEmu to build — the result is stored as a release with its own identifier (for example 20260707T120000Z-ab12cd34). Releases don’t change after they’re created. Publishing again creates a new release; it never edits an old one.

Because old releases stick around, “go back to how it was” is always possible.

Going live is atomic

Your live site is a pointer to whichever release is current. Promoting a release swaps that pointer in one atomic step, so visitors never see a half-updated site — they’re on the old release until the instant they’re on the new one.

Preview and stage before production

You don’t have to publish straight to production:

• Preview — every release gets its own preview hostname (r-<release>--yoursite...). Look at the exact bytes that would go live before you promote them.
• Stage — a movable stage--yoursite... alias you can point at any release, for a stable “next” URL to share with reviewers.
• Promote — when you’re happy, promote the release to production.

Preview and stage URLs show unpublished content, so they sit behind HTTP basic auth (production never does). The credentials are per-site: username preview, password returned by GET /api/deploy/{id}/releases under aliases.auth (also shown in the console’s releases panel). Share the password together with the stage URL when you send it to reviewers. These surfaces are also marked noindex, so search engines never list them.

This is the backbone of safe automation: an agent can deploy and share a preview freely, and a human promotes. See Run InfoEmu with AI agents.

Rollback is the undo button

If a promoted release misbehaves, rollback re-points production at the previous release — instantly, because it’s just another pointer move. There’s no rebuild and nothing to restore. (Rolling back twice oscillates between the two most recent releases; rollback answers with a conflict if there’s no previous release yet.)

Builds never break your live site

When InfoEmu builds your site for you (from raw Markdown or a GitHub push), the build runs in an isolated sandbox. If it fails, you get the logs and your live site is untouched — a broken commit can’t take your site down. See Build from Markdown or GitHub.

Putting it together

A typical safe flow:

1. Publish → new release + preview URL.
2. Review the preview (or point stage at it and share, along with the preview credentials).
3. Promote to production.
4. If something’s wrong, rollback first, investigate second.

The how-to for the commands and the API is Deploy a static or docs site.