Solutions · Preview & test environments
Give every change a place to prove itself.
Plan isolated environments for review, debugging and testing. Keep the application structure familiar while giving each environment its own configuration and lifecycle.
#142fix/checkout-tax
pr-142.preview.example.app
Pull request #142, branch fix/checkout-tax: preview live for review.#145feat/team-invites
pr-145.preview.example.app
Pull request #145, branch feat/team-invites: preview being created.#139chore/upgrade-orm
pr-139.preview.example.app
Pull request #139, branch chore/upgrade-orm: preview deleted after merge.
- Isolation
- A namespace per environment
- Data
- Seeded or sanitised, never production
- Lifecycle
- Owner and end date set up front
- Status
- Lifecycle controls confirmed at onboarding
The problem
Shared staging is where reviews go to wait.
One staging environment means queues, collisions and a cleanup nobody owns. An environment per change fixes the review, as long as each one has a template, a budget and an end date.
Without: Three branches take turns on one staging.
With Kapten: Each change reviewed in its own isolated environment.
BosunInfrastructureWithout: Reviews run against a copy of production data.
With Kapten: Seeded fixtures and preview-only secrets.
WardenSecurity reviewWithout: Reviewers test the API without the worker it calls.
With Kapten: A preview shape with every service the change needs.
NavigatorArchitectureWithout: Forgotten previews billed for a month.
With Kapten: A daily cap, sleep when idle, deletion planned at the start.
PurserCost
How it works
Make environment ownership explicit.
Review the whole application
An API change often depends on a worker, a database or a frontend. Define the services needed to exercise the change together.
Use data meant for testing
Choose seeded or sanitised data and environment-specific secrets. A review deployment should not need production credentials to be useful.
Set the end date at the start
Assign an owner and a cleanup rule. Include compute, storage and external resources when deciding what should happen after review.
Workflows
Start from a recipe built for this.
Each workflow names the specialists it brings in and where it stops to ask you. Copy the prompt into your agent, or read the run step by step.
All workflowsA preview environment per pull request
Give each pull request a complete, isolated copy of the application with seeded data, and remove it when the branch closes.
› Set up preview environments for every pull request on github.com/acme/atlas. Seed Postgres from fixtures, cap each preview at 2 € a day and delete it on merge.
- Navigator
- Bosun
- Purser
- Kapten
- Helmsman
Database migration rehearsal
Run a risky schema migration against a restored copy of production first, measure it, and only then schedule the real one.
› Rehearse migration 0042_split_orders against a copy of production. Tell me how long it locks, and whether the previous release still works after it.
- Bosun
- Helmsman
- Lookout
- Kapten
Monthly cost review
Find idle environments, oversized nodes and orphaned resources, and get the expected saving for each change before you make it.
› Review last month’s spend for every environment. Find what is idle or oversized and tell me what I would save by fixing it.
- Purser
- Lookout
- Kapten
- Bosun
The crew on this job
Who does what, for you.
Every specialist has a narrow job and a boundary. Nothing reaches your account without a plan you approved.
Meet all eight specialists- NavigatorArchitectureDecides which services a review actually needs.
- BosunInfrastructurePlans an isolated namespace and a throwaway database.
- PurserCostSets the daily cap and the idle and cleanup rules.
- HelmsmanReleasesDeploys the branch and shares the review URL.
- WardenSecurity reviewKeeps production credentials out of every preview.
Read before you start
Guides and papers for this path.
- The agentic SREOperating production with a crew of specialised agents, and keeping humans in charge.Read the whitepaper
- Design a preview environment that has an end dateDecide what to deploy, which data to use and what to remove when a review environment has done its job.
- Containerize any app: a practical Dockerfile checklistTurn a working repository into a reproducible image. Short Dockerfiles for Node, Python and Go, and the ten rules that make them production-worthy.
- Postgres in production: the checklistWhere to run it, how to back it up, how to prove the backup works, how to connect to it, and what to watch once real users depend on it.
FAQ
A few practical questions.
Can I use this for staging as well?
Yes, staging follows the same environment model but usually has a longer lifecycle. Keep its configuration and access separate from production.
Will deleting an environment remove everything?
Confirm the deletion policy for each resource, especially persistent data and services outside the cluster. Your cleanup plan should explicitly cover what is retained.
Does a preview get created on every pull request today?
That is the intended workflow. Pull-request automation and scheduled shutdown are part of early access and may not be available for every project yet. We confirm which lifecycle controls you get during onboarding.
Keep exploring
See how it fits together.
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.