Self-Hosted vs Managed CDE
This decision does not turn on a feature list. It turns on whether you have a funded platform team - and if you do not, self-hosting is a commitment you will quietly default on.
A decision framework, with the deployment models checked against vendor documentation as of July 2026
The Thesis, Stated Plainly
Most evaluations of this question ask the wrong thing first
The usual framing is control versus convenience, and it produces a scoring matrix that both sides can win. The more useful framing is a staffing question: is there a funded, named team whose job description already includes operating internal infrastructure, and does that team have capacity for one more service with a pager attached to it?
If the answer is yes, self-hosting is a reasonable choice and the feature comparison is worth having. If the answer is no, the feature comparison is a distraction, because the failure mode of a self-hosted development platform is not that it lacks a feature. It is that it gets installed by an enthusiastic engineer, works well for a year, falls behind on upgrades when that engineer changes teams, and is quietly abandoned - at which point everyone goes back to local laptops with a worse taste in their mouth than before.
That failure has nothing to do with the software. It is the predictable result of taking on a permanent operational obligation without funding it. Naming the owner before the pilot, rather than after, is the single highest-value step in this entire decision.
This page does not tell you which side to pick. Both are correct under conditions the other cannot meet, and the conditions are set out below. What it does argue is that you should answer the staffing question before you open a single vendor comparison.
There Are Four Positions, Not Two
"Self-hosted" is used loosely enough across this market that the word alone tells you almost nothing
| Position | Who runs the control plane | Could you keep running without the vendor | Examples as of July 2026 |
|---|---|---|---|
| Open and self-operated | You | Yes | Coder Community, AGPL-3.0. E2B, Apache-2.0, with a Terraform self-hosting path documented for Google Cloud and AWS only, and AWS marked beta. |
| Self-operated but licensed | You | Only while the key is valid | Okteto Platform - a Helm chart in your own cluster that requires a license key issued with a subscription |
| Your compute, vendor control plane | The vendor | No | Ona Enterprise runners in your AWS or GCP VPC. Daytona offers the same shape on compute you provide, but it sells agent sandboxes rather than development environments, so it does not belong on a CDE shortlist. |
| Fully managed | The vendor | No | GitHub Codespaces, which has no self-hosted or bring-your-own-cloud form at any tier |
Deployment models in the table are taken from each vendor's own documentation as of July 2026: coder.com/pricing, Okteto's self-hosted documentation, ona.com/pricing, github.com/e2b-dev/E2B, and github.com/features/codespaces. Citation standard: sources.
Rows two and three are where procurement documents go wrong. A requirement written as "must be self-hosted" is usually shorthand for one of two very different things: code must not leave our boundary, or we must be able to keep operating if the vendor changes course. The third row satisfies the first and fails the second completely. The second row satisfies the first, and satisfies the second only for as long as somebody keeps renewing.
Separate those two requirements in writing before you shortlist anything, because they eliminate different vendors and a shortlist built on the merged version will contain products that cannot possibly meet it. Vendor evaluation turns that into a written question a salesperson has to answer.
The Ongoing Cost of Self-Hosting
Vendors of self-hosted products advertise the install. This is the part after the install.
The install genuinely is easy, and the demos are honest about that. What follows is a permanent obligation that no vendor puts on a pricing page, because it is your cost rather than theirs. It is not exotic work - it is ordinary production operations, applied to a system your engineers depend on to do any work at all.
Upgrades, forever
Active projects release often - Coder shipped across parallel version lines through mid-July 2026, with a separate stable line its own release notes recommend for customers without a staging environment. Somebody has to read release notes, maintain that staging environment, and schedule the work. Skipping it for two quarters turns a routine upgrade into a migration.
A database you now own
Coder keeps all platform state in PostgreSQL. That means backups, restore tests, retention, failover, and capacity - the same obligations as any other production database, on a system whose outage stops development entirely rather than degrading a feature.
More components than you think
Okteto's Helm chart brings an ingress controller, an API, a BuildKit build service, a frontend, a migration component, a container registry, and a validation webhook. Coder brings a server, a provisioner, ingress, and a template library. Each is a coherent bundle; none is a single binary.
Templates are a product you maintain
On Coder the workspace definition is Terraform your team writes. That is real power and real ongoing work: base images to patch, provider versions to bump, and a permissive template that nobody reviewed becoming your isolation boundary by accident.
Being on call for developer time
When the control plane is down, nobody can start a workspace. The blast radius is the whole engineering organization, which is a higher severity than most internal tools carry, and it means an actual rotation rather than a best-effort owner.
The cloud bill is yours too
Self-hosting moves compute onto your invoice: every workspace, the storage that persists between sessions, registry traffic, and egress. Auto-stop and quota policy matter more to this number than any license figure, and nobody owns that policy by default.
No credible measured figure exists for this. Nobody has published a defensible, reproducible measurement of the engineer-time required to operate a self-hosted CDE across organizations - and the number would not transfer anyway, because it depends on your existing platform maturity more than on the product. Any comparison quoting a specific figure for this is extrapolating from one deployment that is not yours. Estimate it internally, against your own on-call and upgrade history, and treat that estimate as the load-bearing number in the decision.
The Real Cost of Managed
Cheaper to start is not the same as cheaper, and the risks are different rather than absent
Consumption pricing drifts by default
Managed CDEs bill by usage, and usage grows without anyone deciding it should. GitHub publishes every Codespaces rate, which makes the model honest - but it also means idle time you forgot to stop bills at the same rate as work, and storage keeps accruing on a stopped codespace until it is deleted.
Where the unit is less familiar the drift is harder to see. Ona bills in OCUs, which its documentation describes as covering both agent token usage and environment runtime, so spend can move because agent behavior changed rather than because anyone resized a machine.
Constraints you cannot configure your way out of
A managed product's limits are architectural, not tiered. Codespaces gives you a Linux container on GitHub's infrastructure; there is no Windows build, no macOS, nothing below the container, and no bring-your-own-cloud at any price. If one of those is disqualifying, no negotiation and no future release fixes it.
Data location is the version of this that most often surprises buyers. A regional residency guarantee satisfies a jurisdiction requirement. It does not satisfy "must execute inside our VPC", and the two are routinely conflated. See data residency.
Vendor risk is the cost you pay in one lump, later
This category has churned badly. AWS closed Cloud9 to new customers and then closed CodeCatalyst, JetBrains discontinued Space, Daytona left the category for agent sandbox infrastructure, and Ona has an agreement to join OpenAI that had not closed as of July 2026. A managed product that is discontinued takes your environments with it, and the migration lands on the quarter it happens rather than the quarter you planned. That is exactly the risk a self-hosted deployment converts into a slower, more controllable problem - which is the strongest honest argument for self-hosting, and it is a risk argument rather than a features one.
Who Should Choose Which
Conditions you can check against your own organization chart today
Self-host when
- A funded platform team already runs internal services on a rotation, and you can name the person who will own this one.
- Code must not leave your network, and no regional guarantee satisfies the reviewer who has to sign.
- You are air-gapped or on-premises, where a vendor control plane is disqualifying regardless of everything else.
- Workspaces must be shapes a managed product does not offer - VMs, bare metal, specific GPU hardware, non-Linux toolchains.
- Continuity is a stated requirement, and you want an installation that survives a change of vendor direction.
- Utilization is high and sustained on your own committed-spend or reserved-capacity discounts.
Buy managed when
- You cannot name the owner. This one condition outweighs every feature comparison on the other side.
- Your platform team exists but is fully committed, and this would be an unfunded addition rather than a planned one.
- A Linux container genuinely covers your toolchain and your compliance position.
- Usage is intermittent, so consumption billing works in your favor rather than against it.
- You need this working within weeks, and the realistic alternative is not a self-hosted platform but continuing to do nothing.
- You are validating whether centralized environments help at all, and a reversible pilot beats a permanent obligation.
The middle position, and when it is the right answer
The your-compute-vendor-control-plane row is genuinely useful for one specific organization: one whose security review demands a network boundary but whose engineering organization has no capacity to operate a platform. That is a common shape and it deserves a real option rather than a lecture. Just be precise about what you are buying. You get a boundary and a data-jurisdiction story; you do not get an exit, because nothing in the relationship survives the vendor. Buy it deliberately for the first reason, and do not let anyone record it as satisfying the second.
What Cannot Be Compared
The numbers this framework deliberately refuses to supply
The break-even seat count
There is no publishable number of developers above which self-hosting becomes cheaper. It cannot exist while Coder Premium, Okteto Scale and Enterprise, and Ona Enterprise are all unpublished, and it would still depend on your cloud discounts and your existing platform staffing. Any article giving you a headcount threshold made it up.
Operational effort in engineer-days
No independent measurement of the ongoing cost of running a self-hosted CDE was found, from any publisher. The honest instruction is to estimate it internally from your own upgrade and on-call history, and to weight that estimate heavily rather than treating it as a rounding error.
Reliability, either way
Comparable uptime data for self-hosted deployments does not exist, because those deployments are yours and nobody aggregates them. Assuming a managed service is automatically more reliable than your own platform team is an assumption, not a finding, and it runs in both directions.
Related
The head-to-head comparisons this framework sits underneath
Coder vs GitHub Codespaces
This framework applied to the clearest self-hosted and managed pair in the category
Coder vs Ona
Rows one and three of the table above, compared directly
Coder vs Okteto
Two self-hostable platforms whose open-source claims are not equivalent
Build vs Buy
The same staffing question, applied to building your own rather than adopting one
Platform Engineering
What a funded platform team actually looks like, and how to tell whether you have one
Cost Analysis
Modeling both sides with the staffing line included rather than assumed away
Open Source CDEs
Which products survive the question "could you keep running without the vendor"
Vendor Evaluation
Getting "who operates this" answered in writing before you sign
Sources and Citations
Every figure on this site with its publisher, date, and link