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.
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.
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.
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.
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.