Environments
Design a preview environment that has an end date
Decide what to deploy, which data to use and what to remove when a review environment has done its job.
On this page6 sections
Define what the reviewer needs
A preview should make a change testable. List the components needed for that change and the user journey the reviewer will follow. A frontend-only preview may be enough for a copy update; an API change may need a worker and a database too.
Keep the scope small enough to understand and complete enough to exercise the behaviour you want reviewed.
Separate configuration and data
Use environment-specific configuration and credentials. Decide whether the environment needs seeded data, sanitised data or an empty database. Do not assume a production data copy is the right default.
Check dependencies that can cause real-world effects. Test email delivery, payment integrations and webhooks should use the appropriate test endpoints or controlled substitutes.
| Question | Empty database | Seeded data | Sanitised copy | Production copy |
|---|---|---|---|---|
| Exercises the review journey | No | Yes | Yes | Yes |
| Safe to show every reviewer | Yes | Yes | Partial | No |
| Needs a data owner’s sign-off | No | No | Partial | Yes |
| Kept up to date by | n/a | Seed scripts | The sanitiser | n/a |
Give the environment an owner
Record the change being reviewed, who owns the environment and when it should be removed. Keep that information near the deployment so someone other than its creator can understand why it exists.
- Day 0 · 10:12Pull request openedOwner and expiry recorded with the deployment.
- Day 0 · 10:19Preview deploying, In progressFrontend, API and a seeded database.
- Day 0 · 10:26URL posted on the pull request, LiveReviewers follow the agreed journey.
- Day 2 · 17:40Review complete, PausedWorkloads sleep; volumes and database remain.
- Day 3 · 09:05Branch merged, QueuedCleanup plan lists every resource to remove.
- Day 3 · 09:11Resources deleted, LiveVolumes, database, bucket and DNS record gone.
Define how reviewers find the URL and report a problem. The environment needs to be discoverable to do its job.
Choose a cleanup policy
Agree what ends the environment’s lifecycle: a completed review, a merged branch or a fixed expiry date. Confirm which of those triggers your current tooling supports; use an explicit manual owner until automation is available.
Include persistent volumes, database instances, object storage, DNS records and external resources in the cleanup inventory. Decide what must be retained and for how long.
Review the cost of keeping it alive
Estimate the environment’s baseline spend and compare it with the value of keeping it available. Long-lived staging and short-lived previews usually have different needs.
Sleeping a workload and deleting its resources are different actions. Verify what remains billable in each case before assuming a stopped environment costs nothing.
| Resource | Sleeping | Deleted |
|---|---|---|
| Application containers | No | No |
| Persistent volumes | Yes | No |
| Database instanceStorage keeps billing when stopped | Partial | No |
| Object storage | Yes | No |
| Load balancer | Yes | No |
| DNS records and external resources | Partial | Partial |
Apply the pattern to your team
Use the same questions for staging, debugging and trial environments: purpose, dependencies, data, owner and end date. Read the preview environment solution and confirm available automation during early-access onboarding.
Build with Kapten
Start with one service.
Build from there.
Tell us what you want to deploy. We review each request and follow up about fit and onboarding on your preferred cloud.
Free during early access. No card required. Cloud usage billed separately.