Preview vs published

Your app exists in two forms while you work: the preview you build against, and the published version your visitors see. Keeping them straight saves a lot of confusion.

The preview

The preview is your working copy. It rebuilds automatically after every change, reflects your latest work within moments, and is visible only to you and your project's collaborators. This is where you try things, test flows, and iterate. Vaulter even repairs it automatically when a change breaks something.

The published version

The published version is the one that is live on the web at your app's address. It only changes when you hit Publish. Between publishes, your visitors keep seeing the last version you published, no matter how much you change in the preview.

The published version is also where the production extras live: search and social tags, visitor analytics on paid plans, and your custom domain. The preview has none of those, by design; it is a workbench, not a public site.

Why the split matters

This separation means you can keep working on your app, even make a mess mid-change, without any of it reaching your users. Nothing goes live by accident: publishing is an explicit act, it requires an admin role on the project, and each publish is recorded in Vault → Deployments so there is always a history of what went live and when.

Some settings follow the same rule. Changes to sign-in providers and app access in the Auth panel take effect on your live app at the next publish, and the panel reminds you with a banner when a republish is needed.

A simple workflow

1. Build and test freely in the preview.
2. Click through the important flows to make sure they work.
3. Publish when you are happy.
4. Repeat for the next round of changes.

If you ever notice your live app is missing a change you made, the usual reason is simple: the change is in your preview but has not been published yet. Hit Publish.