/

/

Isolated by Default: Preview Environments That Unblocked a Product Team

Isolated by Default: Preview Environments That Unblocked a Product Team

How Amoniac gave Greenstep's engineering team a full, isolated copy of the platform for every change, so nothing waits in line to be tested.

Client

Greenstep

Industry

Professional Services / SaaS

Service

Platform Engineering

~15 min

from change request to a working preview link

4-previews

running side by side, with no contention

0-slots

to wait for, instead of one shared staging

~15 min

from change request to a working preview link

4-previews

running side by side, with no contention

0-slots

to wait for, instead of one shared staging

Context

Greenstep is a B2B service provider combining consulting with its own SaaS offering. The SaaS products are developed by centralized teams and extended continuously, with new features shipping regularly. As the products grew, testing became the constraint. Every change in progress shared one staging environment, so showing a work-in-progress feature to a product manager meant waiting for a free slot, and a single unfinished feature could hold up testing for everyone. Validation had turned into a queue.

What We Did

Every change request now gets its own complete copy of the platform to be reviewed against: its own database, its own file storage, its own mail handling. Nothing is shared, so nothing blocks anyone.

When a developer opens a change request, the automation provisions a dedicated environment in about 15 minutes. It is seeded from a synthetic copy of the test dataset, so reviewers see how a feature behaves against realistic volumes and content rather than placeholder rows. Outbound email is captured inside the environment and never delivered, so a preview cannot reach a real recipient. Each preview is reachable only by authenticated Greenstep staff, lives as long as the review, and is destroyed with the branch.

Underneath it: managed Kubernetes with Argo CD and Helm for delivery, CloudNativePG for the per-environment databases, GitHub Actions for the triggers, and several components we built or adapted for Greenstep's setup. Previews run on Hetzner in the EU rather than on a hyperscaler. They live for hours or days, and the cost difference is what makes "open one for every idea" a reasonable default.

Technologies used
Kubernetes
Helm
GitHub Actions
ArgoCD
CI/CD automation
Kubernetes
Helm
GitHub Actions
ArgoCD
CI/CD automation
Results

Staging stopped being a bottleneck. Product managers review features against realistic data inside the change request, days before anything reaches staging. Unfinished work no longer blocks anyone, and an environment that ends up in a bad state is deleted and rebuilt with one click. Releases are paced by the product roadmap instead of by environment availability.

An environment per change has changed how we work. Product reviews happen earlier, releases carry less risk, and nobody waits for a slot to test an idea. It also stayed inside our security model: synthetic data in previews, and access limited securely to our own people.

Jonathan Teir

Partner, Growth, Technology Development & Security @ Greenstep

Delivery Pipeline Optimisation
Zero to Shipped: Full CI/CD Pipeline for a Mobile Health App

From day one of building their React Native health app, we set up the complete delivery pipeline alongside the product — automated builds, test distribution, and direct releases to App Store and Google Play.

Platform Engineering
From Manual to Automated: Full Kubernetes Migration

As Digital Health Outcomes scaled their client base, they needed a fast, repeatable way to deploy to isolated environments. We built the full infrastructure foundation — Docker, Terraform, EKS, Helm — so any new deployment is a single script away.

Ready to move faster?

Tell us about your infrastructure challenges. We'll take it from there.