How to Give Developers Self-Service Environments Without Building an IDP from Scratch
Most engineering teams that want self-service environments end up scoping a full internal developer platform — a portal, a service catalog, golden paths, a governance layer. That's a 12-18 month project with a dedicated team behind it. But "developers can get an isolated environment on demand" and "we built an IDP" are not the same requirement, and conflating them is why so many of these projects stall.
The Self-Service Trap
Ask an engineering leader what "self-service environments" means and you'll usually get a platform-shaped answer: a portal developers log into, a catalog of templates, a golden path for provisioning. That's the Backstage playbook, and for some organizations it's the right one. But it's also a much bigger commitment than what most teams are actually trying to solve.
What developers are actually asking for is narrower: "When I open a PR, can I get a real, working copy of the app to test against, without waiting or filing a ticket?" That's an environment provisioning and lifecycle problem — not a portal problem, not a service-catalog problem, and not a golden-path problem. Teams that start by scoping "self-service environments" and end up scoping "an IDP" have quietly signed up for 5-10x the project.
We've written before about why 80% of internal developer platforms fail — bottlenecks, maintenance burden, bus-factor-of-one tribal knowledge. Almost none of those failure modes are specific to the "environments" part of the platform. They're specific to the "we also built a portal, a catalog, and a plugin ecosystem" part. If what you need is on-demand environments, you can get there without any of that.
A Real Migration Story: Built It, Then Bought It
One of our customers — a fintech engineering org of around 20 engineers, running trunk-based development on AWS/EKS with Helm and GitHub Actions — lived through this exact arc. Their platform lead walked us through the whole thing, and it's worth telling in detail because it's such a common shape.
The Dream
The goal was straightforward: give every PR its own preview environment, kill the shared-staging bottleneck, and give developers reproducible, prod-like environments on demand for end-to-end validation. Their developers own quality end-to-end — there's no separate QA team — so on-demand environments weren't a nice-to-have. They were the difference between validating a change properly and shipping on hope.
They got most of the way there. Developers could request an environment and validate changes against a real stack. Functionally, it worked.
Where It Broke
The further they pushed it, the more obvious it became they were maintaining a platform they hadn't budgeted to maintain. Environment creation took 40+ minutes and wasn't reliable enough to trust. Builds failed mid-deploy often enough that developers got into the habit of spinning up four or five environments in parallel, hoping one would land — burning cloud spend on environments most of which died before being used.
Developers context-switched while waiting, and often forgot what they'd been testing by the time an environment was finally ready. Many gave up and pushed straight to shared staging instead — recreating the exact queueing problem the system was built to eliminate. Because their developers own validation themselves, that lost time hit twice: once on the change they were building, and again on the verification work they couldn't run.
The Ripple Effect
PR reviews stalled because reviewers couldn't click around the change. Pre-merge validation piled up at the end of every sprint. Releases went out with less confidence than the team wanted, and sometimes slipped entirely.
The most damaging effect was cultural, not technical: developers stopped trusting the platform and started routing around it. And because no engineer had headcount carved out to own it, the system slowly bit-rotted — every fix was reactive, and the gap between what the platform did and what the team needed widened every quarter.
This is the pattern behind most DIY environment platforms: the failure isn't a single outage, it's a slow erosion of trust. Developers don't file a complaint — they just quietly stop using the thing you built for them.
What Self-Service Actually Requires
Strip away the portal and the catalog, and self-service environments come down to five capabilities:
- On-demand creation — a developer (or CI) can request an environment without waiting on a human.
- Production-like fidelity — the environment reflects real services, real dependencies, real configuration, not a stripped-down sample stack.
- Per-PR / per-branch isolation — no queueing for a shared environment, no "who reset the test data" conflicts.
- Lifecycle management — auto-stop, auto-destroy, schedules, so environments don't become a standing cost nobody notices until the bill arrives.
- CI/CD integration that doesn't require migrating your pipeline — the platform deploys into environments; it doesn't need to own your build process.
None of these require a developer portal. None of them require a service catalog. None of them require you to pick a golden-path abstraction and force every team onto it. They require an orchestration layer over infrastructure you already have.
The Non-Negotiables Checklist
When our customer went looking for a platform instead of continuing to build, their requirements were specific — and they generalize well to almost any team in this position:
- Runs in your own cloud account — single-tenant, your cluster, your network. Not a vendor-hosted sandbox you have to trust with production-adjacent data.
- Native support for how you already package services — Helm, Docker Compose, Terraform, whatever it is. If the platform assumes a standardized stack and you have legacy pieces that don't fit a template, you'll spend your integration budget fighting the tool.
- Full API + CLI parity — anything the UI does has to be scriptable from CI. A self-service platform that's UI-only isn't self-service; it's a different queue.
- Clean CI integration without a rewrite — the platform should slot into GitHub Actions, GitLab CI, or whatever you run today, not require you to migrate your build process to get environments.
- A cost model that doesn't punish growth — pricing that scales linearly (or better) with engineers and services, not exponentially. A platform that gets more expensive every time you hire is a platform you'll be re-evaluating in a year.
- Built-in lifecycle controls — auto-stop, auto-destroy, scheduling — so you're not writing janitor scripts to keep costs sane.
Why the "More Polished" Platforms Often Don't Fit
Our customer evaluated two other Environment-as-a-Service platforms before choosing Bunnyshell, and the pattern they described is common: the more polished platforms tended to assume a more standardized stack, while the platforms flexible enough to fit a heterogeneous, legacy-inclusive setup tended to be slower or less reliable.
Cost was the other differentiator. Beyond being more expensive overall, the pricing models they were quoted would have scaled badly against them — adding engineers or services would have pushed the bill up exponentially. For a growing team, that's not a rounding error; it's a platform choice that punishes you for succeeding.
| What they needed | What 'polished' platforms assumed |
|---|---|
| Legacy services alongside modern ones | A standardized, modern stack |
| Own AWS/EKS account, own cluster | Vendor-hosted or managed compute |
| Native Helm, no pipeline rewrite | Migrate CI to the platform's own build system |
| Predictable cost as team grows | Per-seat or per-environment pricing that compounds |
What Changed After They Bought Instead of Built
The speed change (40+ minutes down to under 5) unlocked behaviors that genuinely weren't possible before:
- Branch-tracking replaced manual deploys. As their CI pipeline produces new builds, environments update automatically via API — no manual redeploys, no babysitting. They didn't have to move their CI build onto the new platform to get this; they kept GitHub Actions as-is and integrated via API.
- Full-stack testing became the default, not the exception. Under the old system, exercising the whole stack against an in-flight change was cumbersome enough that most engineers tested against mocks or a partial subset of services and hoped the rest lined up at integration time. Today, full-stack validation is a click away.
- Pre-merge validation moved onto the PR environment itself — developers exercise the full stack against their own change before merge, instead of discovering integration problems in shared staging or production.
- Product and design started previewing in-flight features — actual interactive environments, not static mockups.
- Bug hunts became a one-shot operation. Reproducing an issue off a specific commit used to mean blocking shared staging or babysitting a flaky environment for hours. Now it doesn't disrupt anyone else.
Release confidence went up on both sides of the equation: they ship more often, and they catch more issues pre-merge, because developers, reviewers, and product are all pointing at the same environment instead of guessing.
Get Self-Service Environments Without Building a Platform
Bunnyshell deploys into your own AWS/GCP/Azure account and Kubernetes cluster — native Helm, Docker Compose, and Terraform support, full API/CLI parity, and lifecycle controls built in.
It's Not Just One Company's Story
The pattern shows up across the industry, not just with one team. In a public review, one engineering user described almost exactly the same arc:
"We had an internal development team maintaining our preview environments that we spin up for automated tests in CI. The previews never worked exactly the way we wanted and [they] took our engineers away from what they needed to be focused on: our product!"
"Build your own environment provisioning" is a trap teams fall into regardless of which platform they eventually land on. The maintenance cost is the part that never shows up in the original build estimate, and it's the part that eventually forces the re-evaluation.
Industry analysis of custom-built internal developer platforms puts the three-year total cost of ownership at roughly 4.5x the initial development estimate — because the standing team required to keep the platform alive (commonly cited at 3-6 engineers) costs more, every year, than the original build. That matches what our customer told us directly: "If we'd kept maintaining the homegrown solution, it would be in worse shape today than when we replaced it... the gap doesn't stay constant — it widens every year you don't invest."
A Practical Path: What to Actually Set Up
If you're trying to get self-service environments live without a platform build, the shape of the work looks like this:
- Define your environments as code — a single manifest (Bunnyshell uses
bunnyshell.yaml) that maps to services you already have, not a new abstraction layer everyone has to learn. - Connect your existing cluster — BYOC (Bring Your Own Cloud): your AWS/GCP/Azure account, your EKS/GKE/AKS cluster, your data never leaves your infrastructure.
- Wire it into CI via API, not by replacing your pipeline — your existing GitHub Actions, GitLab CI, or Jenkins config stays as-is; the platform just deploys the artifacts it produces.
- Set lifecycle policies once — auto-stop overnight and on weekends, auto-destroy after a PR merges or goes stale, so cost stays proportional to actual usage.
- Give developers the CLI/API from day one — so nothing is gated behind a UI-only workflow, and CI can do everything a human can do manually.
None of this requires a service catalog, a golden-path taxonomy, or a dedicated platform team. It requires an orchestration layer you don't have to build or maintain yourself.
Related Reading
- Internal Developer Platform Failures: 5 Reasons Your DIY Platform Is Dying
- Building or Buying Your Development Environments Platform?
- Platform Engineering & Internal Developer Platforms
Self-Service Environments, Without the Platform Team
Full-stack, on-demand, per-PR environments in your own cloud — no portal to build, no catalog to maintain, no 12-18 month timeline.
