Preview and production environments

Every app you build in Vorx exists in two places: the preview you work in, and the published version your users visit. Knowing which is which keeps you fast while you build and calm once you launch.

The preview is your working copy

When you describe an app, Vorx builds it and runs it live beside the chat. Every change lands here first. Nothing you do in the preview reaches your users until you publish.

Treat it as a place to be bold. Try a different layout, restructure the data model, rewrite a screen. Every change is a checkpoint, so if one goes the wrong way you roll back — free, and faster than describing your way out of it.

Published is what your users see

Publishing builds your app for production and serves it at your-app.vorx.live, or at your own domain. That version stays exactly as it was at the moment you published, however far your preview wanders afterwards.

Your preview can be halfway through a redesign while your published app keeps serving the stable version your users rely on.

There's no separate promote step. Edits accumulate in the preview and reach your users the next time you publish — which is why it's normal to build for a while and publish once you're happy. Your users stay on the last published version until the new build finishes, so republishing never shows them a half-built app.

Two databases, not one

This is the part that surprises people. Preview and production have separate databases. The records you created while building — the twenty fake customers, the test bookings — live in the preview, and publishing does not copy them across.

That's what you want: your users don't inherit your test data, and clicking around in the preview never touches live records. But it has two consequences worth remembering.

• Your published app starts empty. If it needs reference data — a list of categories, a price table — ask for that to be seeded as part of the app rather than typing it into the preview by hand.
• To check something in live data, look at the production database rather than assuming the preview shows it. Both are under Settings → Cloud → Database.

Keys don't switch themselves either

Secrets are set per project, so an app configured with a provider's test key keeps using that key once published. Before you take real payments or send real email, swap the value under Settings → Cloud → Secrets and publish again. Nothing warns you: test keys fail quietly and look exactly like nothing happening.

A working rhythm

Most people settle into: build in preview, publish when a piece is done, keep improving. You don't need to publish after every tweak — batch related changes, review them together, ship once.

Before you publish:

• Confirm the preview reflects everything you want shipped
• Click through the main flows one last time
• Publish, then open the live URL and repeat one flow there

When something goes wrong live

Go back to the preview, describe the problem, and let Vorx fix it. Verify in the preview, publish again. Because publishing is deliberate, you're always shipping a version you've already checked.

And if the fault is in something running rather than something visible — a job that didn't fire, a function that threw — Settings → Dev Logs has the run with its error, which is far more useful in a prompt than a description of the symptom.

In the docs: Environments and Deploying your app.