Staging on TEST, production on LIVE

Before a site goes live, split staging from production. Production uses a LIVE installation and takes real bookings. Staging keeps a TEST installation, so you and the property manager can test checkout with no real charge. Both run from one hosting project with two environments.

Why staging must not share production settings

A hosting project has one set of production settings. If your staging host is served by the production deployment, switching production to LIVE keys makes staging LIVE too: staging then shows live prices and takes real payments. Serve staging from its own branch with its own settings instead.

Target setup

Host	Hosting environment	Branch	Kismet installation	Who can open it
example.com	Production	main	LIVE	Everyone
staging.example.com	Preview	staging	TEST	Anyone with your staging password
Other preview URLs	Preview	Any	TEST	Your hosting team only

Use one hosting project. Do not create a second project for staging: it doubles every setting and deploy, and the two drift apart.

Set it up on Vercel

1. Create a long-lived staging branch from your production branch. If its commit equals the production branch, push one empty commit. Vercel does not rebuild a commit it has already built.
2. Put the TEST settings in the Preview environment. Use your TEST installation’s keys. Settings that only exist in production, such as your staging password, need the Preview environment added to their target. Sensitive values cannot be read back or copied. Extend their target, or issue a new credential and enter it again. See Create an application and key.
3. Assign the staging domain to the branch. In Settings → Domains, edit staging.example.com, choose Preview, and set the Git branch to staging.
4. Add a Deployment Protection Exception. In Settings → Deployment Protection → Deployment Protection Exceptions, add staging.example.com. Standard Protection otherwise puts a hosting login on every non-production domain, so the property manager cannot open staging. Exceptions are available on all plans. Vercel refuses the exception while the domain still points at production, so complete step 3 first.
5. Set the staging site URL. Add NEXT_PUBLIC_SITE_URL and KISMET_SITE_URL as Preview variables for the staging branch, with the value https://staging.example.com. Links on staging then point at the staging host instead of a generated preview URL.
6. Rebuild staging. Push one more commit to staging, so the domain attaches to a build with the new settings.
7. Switch production to LIVE only after staging passes the checks below. Then set production’s KISMET_API_ENVIRONMENT=LIVE and its LIVE keys. See the Go-live checklist, stage B.

Check it

Check	Pass when
Staging asks for your password	curl -sI https://staging.example.com/ returns 401 from your staging password, never a redirect to vercel.com/sso-api
Staging runs on TEST	Behind the password, /llms.txt names TEST
Other previews stay private	A generated preview URL still asks for a hosting login
Production is unchanged	Production pages, keys, and domains match their state before the change
Checkout on staging is safe	A staging checkout uses the TEST installation and creates no real reservation

Keep it working

• Merge your production branch into staging with each release, so staging tests the code you are about to ship.
• Keep staging out of search: staging and previews must not be indexable.
• Never paste key values in chat, pull requests, or commits.

Undo

In Settings → Domains, edit staging.example.com and choose Production. Staging serves the production build again within a minute. Remove the Deployment Protection Exception if you no longer need it.