Per-pull-request stacks
A namespace or stack created on open and reviewed on a unique URL, with the application, database and dependencies deployed together and no crossover with staging.
Platform & Containers
Ephemeral & Preview Environments
A complete environment for every pull request, destroyed the moment the branch merges.
The work
What this actually does
Reviewing a change from a screenshot or a shared staging box hides the bugs that only appear when the whole stack is running. We give each pull request its own namespace or stack: application, database, queues, seeded test data and a URL the reviewer opens in a browser. Nothing is shared with staging, so two branches cannot interfere with each other.
The engineering is mostly in the lifecycle. Environments are created by the pipeline, seeded from anonymised production-shaped data, labelled with an expiry, and reclaimed automatically so the cloud bill stays flat. We also plan the awkward cases: migrations that must run against the new schema, third-party callbacks that need a stable hostname, and services too expensive to duplicate on every branch.
If any of these sound familiar
- Everyone tests on the same staging box and overwrites each other
- Test data is stale, hand-built and looks nothing like production
- Branches stay open for weeks, so environment costs pile up
- Reviewers approve changes they have never actually run
Scope
What's included
Every engagement on this page covers the following, sized to your setup rather than delivered as a fixed package. If something here is not relevant to you, it comes off the scope and off the price.
Seed data pipeline
Anonymised subsets of realistic data loaded into each environment, refreshed on a schedule, so tests exercise the volumes and edge cases production actually contains.
Automatic teardown
Environments expire when the branch merges or after a fixed idle period, with a warning first, so nothing is left running because someone forgot.
Isolation by default
Separate credentials, separate databases and network rules that prevent a preview environment from reaching production data or a colleague's stack.
Stable routing
Predictable hostnames and wildcard DNS so webhooks, OAuth callbacks and third-party integrations point somewhere consistent instead of a new address on every push.
Cost controls
Resource quotas, small instance types and scheduled shutdown for idle environments, with the running cost of previews reported alongside the rest of your cloud spend.
What changes
What teams typically see
1 PREnvironment per change
10 minEnvironment creation time
0Orphaned environments left running
Handover
What you keep
Everything produced during the engagement is yours: the repositories, the accounts, the documentation. There is no proprietary layer and nothing to unlicense if you take the work in-house.
- Environment template for one service or full stack
- Seed and anonymisation scripts for test data
- Pipeline jobs for create, update and teardown
- Expiry and idle-shutdown policy with alerting
- Preview URL convention and access control rules
Tooling
Tools we use here
A starting point, not a requirement. We work in whatever you already run wherever it does the job.
Kubernetes
Helm
GitHub
Terraform
Docker
PostgreSQL
Argo CD
How it runs
From first call to handover
The same four steps on every engagement. You see each one before it starts and can stop at any of them.
- 01
Map the review needs
We find out which changes actually need a running stack and which dependencies have to be real, rather than assuming every service can be duplicated cheaply.
- 02
Build the environment template
Helm charts, Terraform or manifests that stand up the stack from scratch in minutes, parameterised per branch and tested on a throwaway environment.
- 03
Solve data and routing
Seed jobs load a realistic dataset, wildcard DNS gives each environment a stable hostname, and secrets are scoped so previews cannot touch production.
- 04
Automate the lifecycle
Creation on pull request, updates on each push, teardown on merge and a nightly sweep for anything that outlived its branch.
Questions
Asked before we start
Can every service get a preview environment?
Not realistically. Stateful services, expensive data warehouses and anything with a licensed dependency often cannot be duplicated per branch. We identify those first and provide a shared alternative, so the environments you do get are trustworthy.
How do you keep test data realistic without copying production?
We take a production-shaped subset, replace direct identifiers with generated values, and keep the statistical distribution intact. Referential integrity is preserved so joins still work, and the transformation runs on a schedule rather than by hand.
Will this make our cloud bill go up?
Per-preview cost is real, and pretending otherwise is dishonest. We offset it with small instance sizes, idle shutdown and expiry rules, and the savings from people no longer keeping a shared staging stack running around the clock.
Do reviewers need to know Kubernetes to use them?
No. The reviewer gets a URL and a login. Everything below that is the platform's problem, and we write the pipeline so engineers can change the environment definition without understanding the whole cluster.
Platform & Containers
Often needed alongside this
Platform & Containers
Internal Developer Platform
A paved road for your developers: self-service environments and golden-path templates in one portal.
- Backstage portals and service catalogues
- Golden-path scaffolding for new services
- On-demand and ephemeral preview environments
Delivery Automation
CI/CD Pipeline Engineering
Automated build, test and deploy pipelines that turn every commit into a repeatable, auditable release.
- GitHub Actions, GitLab CI, Jenkins & Azure Pipelines
- Parallel builds, caching and artifact promotion
- Quality gates, approvals and rollback on failure
Platform & Containers
Kubernetes & Containers
Production-grade clusters with sane defaults, safe rollouts and an operator experience your team will actually enjoy.
- EKS, AKS, GKE and self-managed clusters
- Helm, Kustomize and GitOps-driven deployments
- Node autoscaling, resource tuning and cost control
Worth a conversation about Ephemeral & Preview Environments?
Bring the specific problem. We will tell you honestly whether this is the service that fixes it, and what it would take.