Rehearsal

Rehearsal is the stage most projects skip and most incidents come from. The app runs on the Rehearsal Server, real AWS infrastructure configured the way production will be.

Telling it apart from Live

The Rehearsal app looks exactly like the live one, so Sapilon marks it: an amber line runs along the top of every page with a Rehearsal tab, and the browser tab’s title starts with “Rehearsal ·”. The live app has neither. The mark arrives with the next release you publish to Rehearsal.

What you rehearse

• The data migration. Import from the old system with realistic volume, and do it more than once. The first run always teaches you something.
• The journeys. The people who will use the app walk through their real work, not a demo script.
• Security posture. Access, secrets, network boundaries, and what is exposed publicly.
• Running cost. What this will cost per month at your actual usage, before it is your production bill.
• Backups and restore. Prove a restore works while nothing depends on it.

Realistic data, safely

Rehearsal wants production-shaped data, which means production-shaped risk. Sensitive fields are masked when data is copied down, so the rehearsal is realistic without spreading personal data into a second environment.

Stopping and starting the Rehearsal Server

A Rehearsal Server that runs your app on always-on containers keeps costing money while nobody is testing on it. If you chose Rehearsal when needed on the Architecture page, you can Stop it from the Rehearsal Server’s card on the Publish page when you are done, and Start it when you need it again.

• What stops: your app’s backend. Anyone who opens the Rehearsal app while it is stopped gets an error until it is started.
• What is kept: the database and its data, sign-in and its users, the web files and the address. Nothing is deleted, so starting it again takes about two minutes and nothing about the server changes.
• What keeps costing: the load balancer in front of the backend. Stopping saves the backend’s own hours, not the whole server.
• Publishing starts it. Publishing to a stopped Rehearsal Server starts it first, so the new release is checked the way it would be on a running one. A publish never leaves it stopped.
• It is not watched for uptime. A server that can be stopped is meant to be off much of the time, so Monitor does not raise an incident when it is.
• It can stop itself. Where automatic stopping is on, a Rehearsal Server nobody has used for the set number of hours stops on its own. The Rehearsal Server’s card says so when it applies.

A Rehearsal Server set to Rehearsal always on, or one whose compute is On demand, has no Stop button: the first stays on by design, and the second already costs next to nothing while nobody uses it.

When a Rehearsal Server is overkill

Not every project needs one. When you move from Build to Rehearsal you choose how the project runs, and a small project with nothing costly riding on it can skip the separate Rehearsal Server: its Live Server serves Rehearsal too, and going Live switches it over. Some projects can’t skip it. A project where a day of downtime would be costly, or a change that alters existing data, needs a Rehearsal Server first.

Skipping it now doesn’t lock you in. You can add a Rehearsal Server later from the Architecture page. Sapilon shows the steps involved before anything starts.

Signs you are ready to leave

• The migration has run cleanly end-to-end, timed, with a rollback you have actually tested.
• No open findings you would be uncomfortable explaining after an incident.
• The monthly cost estimate is one you have accepted.
• Everyone knows what happens to the old system on the day.

Next: Live · Promoting between stages