Preview vs Published

They are different environments

When you build an app in Emergent, you work with two distinct environments:

Coming from another platform? Publishing is the same thing as deploying - what other tools call deploy, deployment, or redeploy, Emergent calls Publish and Re-publish.

Preview - the live sandbox inside the workspace where you test changes as you refine your app with AI agents.
Published - the production environment serving your real users at your published URL.

Each environment runs with its own URL and server instance. On your first publish, Emergent copies your preview's data once into the new production database to seed it; after that the two databases are independent. Later changes you make in preview do not automatically affect the published app until you explicitly push code, and preview edits made after that first publish do not sync back into production data.

Preview is your sandbox

Preview lets you iterate freely, test new features, and fix bugs without risk to your live users. It's the safe place to experiment before committing changes to production.

Why preview changes don't appear live

A common surprise: you've refined your app in preview, the agents have updated the code and tested it successfully - but none of those changes appear in the published app.

This is by design. Emergent keeps the two environments separate so you never accidentally break a live app while iterating. Your published app continues to serve the last version you explicitly pushed, and it will not reflect any preview work until you take action.

Changes stay in preview until re-published

Edits, bug fixes, new features and code improvements remain in the preview environment only. To make them live, you must Re-publish or Replace the published app.

Re-publish vs Replace

When you're ready to push changes from preview to production, Emergent offers two options:

Action	What it updates	Database impact
Re-publish	Code, assets, dependencies	None - keeps existing DB and data
Replace	Swaps a different job onto the live app (blue-green)	Keep existing DB or start with a fresh DB

Use Re-publish when you've only changed UI, logic, styling or dependencies and want to preserve all user data as-is.
Use Replace when you want to perform a blue-green swap of a different job onto your live app.

Re-publish: push latest code

Re-publish copies your preview's code, configuration and assets into a new version alongside the live one and switches traffic at the very end( if it fails, the live app is not affected)- without touching the database.

The published app's existing MongoDB database remains untouched; all user accounts, records and uploads persist.
This is true for every publish after the first. Your very first publish seeds the production database once by copying your preview data; from then on the two databases diverge and re-publish never overwrites production data.
No extra charge for re-publish (beyond the monthly tier fee).
Ideal for rolling out bug fixes, UI tweaks, new pages or backend logic.

Safe for iterative improvements

Re-publish as often as you like. It's the quickest, safest way to keep your live app up to date without risking data loss.

Replace: a blue-green job swap

Replace performs a zero-downtime blue-green swap of a different job onto your live app. When you replace a published app, Emergent carries over your user secrets and prompts you to choose what happens to the production database:

Keep existing data - the new job connects to the existing production database.
Start fresh - the new job gets a new, empty database.

Replace is for swapping a different job

Replace is not the same as re-publishing an update to your current app. Use Re-publish to push code changes from your current preview into the live app.

For a detailed explanation of each database option and safe migration strategies, see the Database (MongoDB) page.

Rolling back to an earlier version

If a change made it live that you need to undo, you can roll back:

From Manage Publishing - each previous published version has a ↺ rollback icon. Click it to restore that version to your live app.
From the chat timeline - open history from the top editor toolbar, pick the message to revert to, review the diff of what changed, then click Rollback. This restores the code from that point.

Rollback affects preview; re-publish to go live

Conversation rollback restores the preview only - your production URL keeps serving the last published version until you Re-publish. Rollback is also destructive: it erases the chat history and code after the selected message, with no roll-forward.

For alternatives to in-place rollback, see Checkpoints: undo anything and Forking.

Updating a live app safely

Once real users are on your published app, updates require extra care:

Test thoroughly in preview first - use the preview environment to verify all changes work as expected.
Choose Re-publish for code-only changes - keeps user data intact and minimizes risk.
Avoid "Start fresh" when replacing onto a live app - this wipes all production data and is almost never appropriate after launch.

Handling data migrations

If you need to transform or backfill data, test the migration logic in preview first, then re-publish or replace as appropriate( for MongoDB only). For complex transformations, consider a maintenance window or phased rollout.

For more on database options during replacement, managing user data safely, and troubleshooting schema conflicts, visit Database (MongoDB).