Preview Deployments (Beta)

Preview deployments are part of the full-stack Beta. Every full-stack build and every change request deploys to a preview first — a real, running copy of your application on its own URL — so you approve what you have actually seen, not a description of it.

How previews work

When a build reaches the preview stage, the platform deploys the build branch to a preview service and runs a health check against it. A preview has one of a few honest states: queued, building, live, or failed — and separately a health result (passed, failed, or unknown until the check has run). A preview URL is never shown as "live" until the deployment actually is.

Your accounts, your infrastructure

Previews run in the same places production does: the code is a branch in your GitHub repository, and the preview service runs in your Render workspace. Preview environments use preview-scoped configuration — your production secrets are never injected into a preview. If your product uses a database, previews are pointed at preview configuration you control, not at your production data, unless you explicitly configure otherwise.

Trying a preview properly

• Register a test account and walk the main journey your customers will take.
• Open the admin area and confirm you can manage the product.
• If the product sends email, trigger one (for example a booking confirmation) and check it arrives — or that it is honestly reported as simulated when no email key is set.
• Check your phone: previews are real deployments, so mobile behavior is real too.

Change requests against a preview

If the preview is close but not right, request changes in plain language from the preview screen. The change is implemented on the build branch and a fresh preview is deployed. Iterating on previews costs build credits like any change request, but it never touches production — you can go around this loop as many times as you need.

Approving to production

Approving a preview is the explicit gate to production. On approval, the branch is merged, production deploys, and health checks run against the production URL before the deployment is considered done. Rejection is just as first-class: rejecting a preview records why, ships nothing, and leaves production exactly as it was.

Honest limits of the Beta

• Previews are temporary by design; do not hand preview URLs to real customers.
• A healthy preview is strong evidence, not a guarantee — health checks confirm the application starts and responds, and the quality report tells you which deeper checks ran.
• Data created in a preview (test bookings, test accounts) does not move to production on approval; production starts with your production data.