All guides

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.

Cover illustration for Design a preview environment that has an end date, intermediate levelEnvironmentsIntermediate · 775f
On this page6 sections
  1. 01Define what the reviewer needs
  2. 02Separate configuration and data
  3. 03Give the environment an owner
  4. 04Choose a cleanup policy
  5. 05Review the cost of keeping it alive
  6. 06Apply the pattern to your team

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.

Which data for a preview?
QuestionEmpty databaseSeeded dataSanitised copyProduction copy
Exercises the review journeyNoYesYesYes
Safe to show every reviewerYesYesPartialNo
Needs a data owner’s sign-offNoNoPartialYes
Kept up to date byn/aSeed scriptsThe sanitisern/a
Figure 1. Choose the data per change. A production copy is never the default: it needs a reason and a data owner’s sign-off.Illustrative · typical trade-offs

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.

A preview, start to end
  1. Day 0 · 10:12
    Pull request opened
    Owner and expiry recorded with the deployment.
  2. Day 0 · 10:19
    Preview deploying, In progress
    Frontend, API and a seeded database.
  3. Day 0 · 10:26
    URL posted on the pull request, Live
    Reviewers follow the agreed journey.
  4. Day 2 · 17:40
    Review complete, Paused
    Workloads sleep; volumes and database remain.
  5. Day 3 · 09:05
    Branch merged, Queued
    Cleanup plan lists every resource to remove.
  6. Day 3 · 09:11
    Resources deleted, Live
    Volumes, database, bucket and DNS record gone.
Figure 2. A preview with an end date: it exists for one change, has one owner, and leaves nothing behind.Illustrative · sample data

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.

Still billable?
ResourceSleepingDeleted
Application containersNoNo
Persistent volumesYesNo
Database instanceStorage keeps billing when stoppedPartialNo
Object storageYesNo
Load balancerYesNo
DNS records and external resourcesPartialPartial
Figure 3. Sleeping stops the workload, not the bill. Typical behaviour; confirm it for your provider and setup.Illustrative · check your provider’s billing rules

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.