Build vs Buy for Cloud Development Environments
The real cost of self-hosting a development platform against paying someone else to run one, and the organizational conditions that make each choice defensible.
The Question Is Not Really About Money
Every build-vs-buy spreadsheet answers a question that was never the hard one.
A comparison of per-seat license cost against cloud compute cost is easy to produce and usually irrelevant, because on that comparison self-hosting almost always wins and the organizations that lost money self-hosting were never beaten on compute. They were beaten on the labor and attention required to keep a platform working, which does not appear on the same page of the budget as the license fee it replaced.
This page deliberately does not model the cost. Cost analysis covers running the numbers with your own utilization data, and FinOps for CDEs covers keeping the spend visible once you are live. What follows is the part the spreadsheet leaves out: the obligations each choice creates, the risks each one concentrates, and the organizational conditions under which each is the sensible answer.
The single most underestimated fact
A cloud development environment becomes production infrastructure the moment developers cannot work without it, and that moment arrives far earlier than anyone plans for. Before it, an outage is an inconvenience and someone works locally for the afternoon. After it, an outage stops the entire engineering organization and costs a full day of everyone's salary. Teams size the build option against the first case and then find themselves operating in the second, without the on-call rotation, the capacity headroom, or the tested recovery procedure that the second case demands. If you take one thing from this page: decide which case you are in before you decide who runs the platform.
What Building Actually Obliges You To
Six recurring commitments, none of which end
Headcount, Not Heroics
The failure pattern is one talented engineer running the platform alongside another job. That works until they take leave, change teams, or leave the company, and the recovery cost dwarfs whatever was saved. A self-hosted CDE serving a real engineering organization needs enough dedicated people that no single absence is an outage - which in practice means more than one, whatever the initial estimate said.
On-Call for Developer Working Hours
The load profile is unusual and unhelpful. Demand spikes hard at the start of the working day in each region and collapses overnight, so the platform is least resilient exactly when it is most needed. If your engineers span several time zones, "business hours" support means something close to continuous coverage.
Upgrades You Cannot Defer
Control plane releases, Kubernetes version upgrades, and base image patching all arrive on someone else's schedule. Deferring them is possible for a while and then abruptly is not, usually because of a vulnerability disclosure. A vendor absorbs this; self-hosting means you own an upgrade treadmill with a security deadline attached.
Template Maintenance Forever
This is the cost nobody budgets and everybody pays. Every language runtime, toolchain, and dependency in every workspace image needs periodic updating, and each team wants a variation. Templates rot invisibly - nothing breaks, the environment simply drifts from what developers need until they route around it.
Identity and Secrets Integration
Single sign-on, group-based access to workspace classes, credential injection, and audit logging that satisfies whoever audits you. This is a one-time build with a permanent maintenance tail, and it is the piece most often underestimated in regulated environments. See IAM and secrets management.
Being the Support Desk
Somebody has to answer "my workspace will not start" for every developer, every time, and that person cannot also be shipping platform features. Vendor support does not eliminate this - you still triage - but it does give you somewhere to escalate that is not a stack trace and a weekend.
Set against those obligations, the build case is genuinely strong in the right conditions. You get complete control over where source code lives, which matters enormously in some regulatory postures. You get to run whatever hardware shape you need, including GPU classes that hosted products either do not offer or price punitively. You avoid per-seat economics entirely, which changes the calculus at large headcount and lets you extend access to contractors and CI without a procurement conversation. And with a genuinely open-source control plane there is no vendor whose commercial decisions can strand you - a point that is worth more than it used to be, for reasons the next section covers.
What Buying Actually Obliges You To
Fewer people, more dependence
Per-Seat Economics That Scale Against You
Per-user pricing is the right shape at small scale and the wrong shape at large scale, because your cost grows with headcount rather than with usage. It also creates a quiet incentive to withhold access from the people at the margin - contractors, data scientists, support engineers - which undermines the consistency argument that justified the platform. Note that several vendors do not publish enterprise pricing at all, so the number you plan against is one you have to negotiate for before you can compare anything.
Exit Cost Compounds Quietly
Leaving is rarely blocked by the workspace definition, which is usually portable. It is blocked by everything built around it: the CI integration, the identity wiring, the automation that assumed a particular API, the muscle memory of several hundred engineers. Exit cost is a function of how deeply you integrated, so it grows every quarter you are happy with the vendor. The mitigation is to keep the environment definition in an open format such as dev containers and resist proprietary extensions.
Data Residency Is a Hard Constraint
Source code, secrets, and often production-shaped data all pass through a development environment. If your obligations require that this stays in a specific jurisdiction or inside your own network boundary, a large part of the hosted market is simply ineligible regardless of its merits. This is the one constraint that can settle the decision on its own. See data residency and air-gapped environments.
Roadmap Dependence
You get the features the vendor decides to build, on the vendor's timeline, and you get the ones you did not want as well. When a vendor changes strategic direction - toward agent infrastructure, or toward whichever category is currently attracting capital - the product you bought can change underneath you without any contract being broken.
The buy case is also genuinely strong, and the strongest argument for it is rarely stated well. It is not that buying is cheaper; frequently it is not. It is that buying converts an open-ended operational commitment into a predictable line item, and it does so at the exact moment in a company's life when platform engineering attention is the scarcest resource it has. A team of forty engineers with no platform function does not have a spare person to operate a control plane, and pretending otherwise produces a platform that is technically self-hosted and practically unmaintained.
Vendor Risk Is Unusually Concrete Here
A shortlist assembled two years ago would be substantially wrong today
Vendor risk is normally an abstraction in procurement documents. In this category it is a list of events, several of which have already happened to real customers. What follows is not a scare story - none of these left anyone stranded overnight, and most came with generous notice. The point is narrower and more useful: this market has been consolidating and re-forming fast enough that the durability question deserves as much weight in your evaluation as the feature comparison, and that is not true of most software you buy.
| Product | What Happened | Effective |
|---|---|---|
| AWS Cloud9 | Closed to new customer access. Existing customers retained access; no new feature development. | July 25, 2024 |
| JetBrains Space | End of sales, then end of life. Its announced successor, SpaceCode, was itself canceled before general availability in November 2024. | Sales May 28, 2024; EOL May 31, 2025 |
| AWS CodeCatalyst | Closed to new customer access. Existing customers keep existing spaces but cannot create new ones; no new features planned. No end-of-support date has been announced. | November 7, 2025 |
| JetBrains Fleet | Withdrawn from download, having never left public preview. JetBrains cited the confusion of maintaining two general-purpose IDE families, and redirected the work into an agentic development environment. | December 22, 2025 |
| Daytona | Left the category. Now positioned as sandbox infrastructure for running AI-generated code rather than as a development environment. Its public repository carries a notice that it is no longer maintained. | Repository notice, June 2026 |
| Ona (formerly Gitpod) | OpenAI announced an agreement to acquire it. The transaction remains subject to customary closing conditions and regulatory approval, and had not closed as this was written. | Announced June 11, 2026 |
Read this fairly
An acquisition is not a shutdown, and a hyperscaler closing a product to new customers is not the same as switching it off. Every case above came with notice, and in several the existing customers were left materially unaffected. Treating this table as evidence that buying is reckless would be the wrong conclusion.
The right conclusion is that the base rate of category-level change here is high, and that it applies to large vendors as readily as to startups. Two of the six entries are AWS products and two are JetBrains products. "We picked a big company" is not the mitigation people assume it is.
What actually mitigates it
- Keep environment definitions in a portable open format, not vendor-specific configuration
- Know your migration path before you sign, and write it down while you still have leverage
- Contract for data export and a notice period, not just uptime
- Prefer a genuinely open-source control plane if the operational capacity exists to run it - see open source CDEs
- Weight durability explicitly in scoring rather than treating it as a footnote - see vendor evaluation
A Decision Framework Keyed to Conditions
Five questions about your organization, not about the products
| Condition | Points Toward Build | Points Toward Buy |
|---|---|---|
| Do you have a platform team? | A funded team with its own roadmap and existing on-call practice | No platform function, or one already at capacity. This is the strongest single signal. |
| Do you already run Kubernetes in production? | Yes, with people who operate it daily. Most self-hosted CDEs are then an incremental workload, not a new competency. | No. Adopting Kubernetes in order to host development environments is a poor reason to adopt Kubernetes. |
| What is your regulatory posture? | Code or data cannot leave your boundary or jurisdiction; auditors need control you can demonstrate directly | Standard commercial obligations that a vendor's certifications and a data processing agreement can satisfy |
| How many developers? | Large enough that per-seat costs exceed a platform team's fully loaded cost, and that specialized hardware demand is constant | Small or mid-sized, where the fixed operational cost dominates and cannot be amortized |
| Can developers tolerate a self-service gap? | You can commit to closing it, and have budgeted for the interface work rather than only the infrastructure | No. A hosted product ships a polished self-service experience on day one; a self-hosted one ships whatever you build. |
Clear buy
No platform team, no Kubernetes, standard compliance obligations, fewer than a few hundred developers. Buy, keep the environment definition portable, and revisit when any two of those conditions change.
Clear build
An established platform team, Kubernetes already in production, a residency or isolation requirement that eliminates most hosted options, and enough headcount to amortize the operational cost. Build, on an open-source control plane.
The honest middle
Most organizations. Several vendors now offer a bring-your-own-cloud arrangement in which compute runs in your account under vendor management. It addresses egress and residency concerns without the operational burden - but it is not self-hosting, and it does not remove vendor dependence.
Two closing cautions. First, be suspicious of any evaluation that reaches "build" in an organization currently sitting at the bottom of the platform engineering maturity ladder; the decision to self-host is a decision to become a platform organization, and that is a larger commitment than the one being discussed. Second, the choice is reversible in one direction far more cheaply than the other. Moving from a hosted product to self-hosted is a project. Moving from a neglected self-hosted platform back to a vendor happens under pressure, after a bad quarter, with the people who understood it already gone.
Related Reading
The cost modeling, the shortlist, and the operating model
Cost Analysis
Running the numbers with your own utilization data instead of a vendor's worked example
FinOps for CDEs
Keeping the spend attributable and visible once the platform is live, whichever way you went
Vendor Evaluation
The selection process itself, including how to weight durability alongside features
Open Source CDEs
Which platforms are genuinely self-hostable, and how to judge whether an open core will last
Platform Engineering Maturity
Whether your organization can honestly support the operating model that building implies
CDE Market Guide
How the category is currently shaped, and who is still actively in it
CDE Tools
Platform-by-platform detail once the build or buy question is settled
Risk Management
Concentration, exit, and availability risk once the platform is load-bearing
Team Structure
The headcount shapes behind the build option, stated as roles rather than as a wish