Open Source Cloud Development Environments
Which CDE platforms are genuinely open source and self-hostable, which only appear to be, and how to judge whether an open core model will still be there in three years.
The Open Side of This Market Has Been Shrinking
Not through license rug-pulls, mostly. Through attrition and repositioning.
"Open source CDE" once described a reasonably crowded field. It no longer does. One well-regarded project shut down when the company behind it dissolved. Another repositioned out of the category entirely. A third is still open and public, but its maintainer now tells readers not to run it. A fourth has an open client and a commercial server - a legitimate model, but not what most people mean when they say a platform is open source.
None of that is scandalous - running a development platform is expensive and the money has to come from somewhere. But it does mean the useful question is no longer "which of these is open source". It is which specific component is open, under what license, and what would have to be true for that to still hold when the vendor next needs revenue. The second half of this page is a set of tests for exactly that. Everything here was checked against primary sources - repository license files, pricing pages, and vendor documentation.
The distinction that does most of the work
"Self-hosted" and "open source" are independent properties, and vendors use both words loosely. You can self-host a proprietary product from a Helm chart, use an open-source client against a proprietary service, or run vendor-managed infrastructure in your own cloud account and reasonably call that self-hosted. Before evaluating anything, decide which property you need: control over where the code runs, or the ability to keep operating if the vendor stops. They eliminate different products.
Where Each Platform Actually Stands
What is open, what you can run yourself, and what it costs to go beyond that
| Platform | What Is Open Source | Self-Host the Control Plane? | Commercial Model |
|---|---|---|---|
| Coder | The platform, AGPL-3.0, with a separate enterprise license covering Premium features | Yes - you run the server and its database | Community free; Premium priced annually per user, figure not published |
| Eclipse Che | The platform, EPL-2.0, under Eclipse Foundation governance | Yes - installs on your own Kubernetes | Support via Red Hat OpenShift Dev Spaces, included with an OpenShift subscription; no standalone price published |
| Okteto | The CLI only, Apache-2.0. The self-hostable Okteto Platform is a commercial Helm distribution. | Yes, but not open - self-hosted, SaaS and bring-your-own-cloud all offered | Starter free up to 5 seats; Scale and Enterprise are contact-sales with no published price |
| DevPod | The client, MPL-2.0 | Not applicable - client-side only, with no server backend to install | No direct monetization; a secondary product at vCluster Labs |
| Devbox (Jetify) | The CLI, Apache-2.0 | No - the CLI builds reproducible local environments; the hosted product is separate | Jetify Devspace under Jetify Cloud, paid, with published tiers plus usage-based charges |
| Ona (formerly Gitpod) | The legacy Gitpod repository, AGPL-3.0, public and not archived - but its README steers users away from running it | No customer-managed option - Enterprise offers Ona-managed runners in your own AWS or GCP account | Published per-user cloud tier; bring-your-own-cloud is Enterprise only |
| Daytona | AGPL-3.0 on tagged releases, including v0.190.0; the current default branch carries no license file and GitHub detects none, because the code is no longer on that branch. See the Daytona review. | No longer a CDE - repositioned to sandbox infrastructure for AI-generated code | Hosted agent sandbox product; core development moved to a private codebase in June 2026 |
| Hocus | MIT, license changed at archival | Discontinued - repository archived September 28, 2024 | None. The startup behind it dissolved. |
Licenses and repository states verified against the projects' own repositories and pricing pages. Anything moving this fast deserves a re-check before a decision rests on it.
The Detail That Changes Decisions
Where a summary would mislead you
Coder and Eclipse Che are the unambiguous cases
These are the two platforms where the thing you self-host is also the thing that is open source. Coder's server is AGPL-3.0 and you run it against your own PostgreSQL; Premium features sit under a separate enterprise license in the same repository, which is a legible arrangement even though the Premium price is not published. Eclipse Che is EPL-2.0, installs onto your own Kubernetes cluster, and has the added durability of Eclipse Foundation governance rather than one company's discretion.
Che's commercial path is worth understanding rather than treating as a catch. Red Hat OpenShift Dev Spaces is the supported downstream distribution, built on Che and included with an OpenShift subscription. If you already run OpenShift, that is close to the best answer available here. If you do not, you get the upstream project with community support - a real option, but a different one.
Okteto: an open CLI, a commercial platform
Okteto is frequently described as open source and self-hostable. That conflates two things. The Okteto CLI is genuinely open source under Apache-2.0, and the project's own documentation distinguishes it from the platform CLI. What you install in your cluster is the commercial Okteto Platform, distributed as a Helm chart. It is self-hostable; it is not open source.
This matters if your reason for wanting open source is continuity rather than inspection: a Helm chart you have a license to run is not something you can fork and maintain if the vendor's plans change. Commercially, Starter is free up to five seats, and Scale and Enterprise are contact-sales with no published figure - so you cannot compare total cost until you have entered a sales process.
DevPod is a client, and it has gone quiet
DevPod is MPL-2.0 and its documentation is admirably direct: it is a client-only tool with no server backend to install. That is a real architectural choice with real advantages - no control plane to operate, no availability requirement, nothing to upgrade centrally. It is also why it does not belong in a like-for-like comparison with Coder or Che. It provisions environments onto infrastructure you already have; it does not manage a fleet.
The current concern is momentum rather than licensing. Loft Labs renamed itself vCluster Labs in August 2025, and the company now centers on its virtual cluster products, with DevPod a secondary item. The repository is not archived and carries no deprecation notice, but it has had no commits since November 2025 and an open issue backlog. It is fair to call it open and available; it is not currently fair to call it actively developed, and anyone adopting it should assume they may become a maintainer.
Ona: read the word "self-hosted" carefully
There is no customer-managed self-hosted Ona. The Enterprise plan offers Ona-managed runners deployed inside your own AWS or GCP account, with environments on your own compute. Ona itself uses "self-hosted" for this, and in the sense that matters to a security team - source code stays inside your network boundary - that is fair. In the sense that matters to a continuity plan it is not: you cannot install, inspect, fork, or keep operating the control plane without the vendor. It is bring-your-own-cloud, which is a different guarantee.
The legacy AGPL-3.0 repository is still public, not archived, and still receiving commits. But its README states that the project has been renamed and that this version is no longer recommended, pointing users to the commercial offering. Open code the maintainer discourages you from running is a narrower asset than it looks: you have the source, and no support, no security patching commitment, and no upgrade path.
Layered on top of that, OpenAI announced on June 11, 2026 that it had agreed to acquire Ona. The transaction remains subject to customary closing conditions and regulatory approval, had not closed as this was written, and the parties remain separate companies until it does. That is not a reason to rule Ona out - acquisitions frequently leave products intact - but a pending acquisition belongs in a three-year platform decision rather than in a footnote.
Daytona has left the category, and Hocus is gone
Daytona is now positioned as elastic infrastructure for running AI-generated code - a sandbox product for agents, not a development environment for people. That is a coherent business, but it means Daytona should not appear on a CDE shortlist. Its public repository is not archived, and the difference is worth stating precisely: it carries an explicit notice that the repository is no longer maintained and that core development moved to a private codebase as of June 2026, and its default branch has had no commits since June 25, 2026. Daytona's own announcement adds that the repository will stay public so anyone who wants to keep using it, fork it, or build on it can continue to do so (Daytona, "Daytona is going closed source", June 11, 2026). Unmaintained and archived are different states, and this one is unmaintained.
The licensing picture rewards checking rather than assuming, and it is the most misread fact on this page. Tagged releases carry AGPL-3.0 and v0.190.0 still does, while the current default branch has no license file and GitHub detects none - the GitHub API returns no license for the repository at all. The reason is that the source itself is no longer on that branch: its root now holds only a README and an assets directory, with the code retained on the tags. The README's license link points at the v0.190.0 tag rather than at the branch, which is exactly why a quick check can suggest the repository is still AGPL-3.0 throughout. If you are relying on that code, pin a tag and read its license yourself. The Daytona review covers the product in full.
Hocus is the starker case. The repository was archived on September 28, 2024 under MIT - the license was changed in the same commit that archived it - and its README states that the project was discontinued because the underlying startup dissolved, with no further features, fixes, or support. It recommends DevPod and Coder as alternatives. It is worth naming because it is the honest version of this outcome: a clear notice, a permissive license, and a pointer elsewhere. Most abandonments are less tidy.
Devbox occupies a different slot entirely
Jetify's Devbox CLI is Apache-2.0 and solves reproducible development environments through Nix - useful, and adjacent to this category rather than inside it. The hosted product, Jetify Devspace under the Jetify Cloud umbrella, is paid, and unlike several vendors here its tiers are published rather than hidden behind a sales conversation. Treat the CLI as an environment definition tool that composes well with a CDE, not as a CDE. See Nix environments.
How to Judge Whether an Open Core Will Last
Six tests you can apply in an afternoon, to any project, without asking the vendor
1. Is the control plane open, or just the client?
The most common way this question gets answered dishonestly. An open client against a proprietary server gives no continuity at all - if the service stops, the client has nothing to talk to. Find the repository containing the scheduler and API server. If it is not public, the platform is not open source however the website is worded.
2. Is there a contributor base, or one company?
Check how many distinct organizations appear in the last year of commits. Single-vendor open source is not illegitimate, but the project is exactly as durable as that company's interest in it. A real external contributor base, or foundation governance, is what makes a fork survivable rather than theoretical.
3. What is the license, and has it moved?
Read the license file on the default branch rather than the README badge, and check that file's history. A project that has relicensed once has shown both the willingness and the legal ability to do it again. A missing license file where one used to be is a signal in its own right - and this category has produced one recently.
4. Is the open edition crippled?
The test is not whether paid features exist - they should. It is whether the open edition can run in production without them. Single sign-on, audit logging, and high availability behind a paywall usually mean the open edition is a demo. Ask what is missing and whether your compliance obligations require it.
5. Does the maintainer recommend running it?
An underrated check this category has made necessary. A repository that is public, unarchived, and actively committed to can still carry a notice telling you not to use it - and that notice says more about the project's future than the commit graph does.
6. Where does the revenue actually come from?
If you cannot describe the business model in a sentence, the pressure to change it later is unbounded. Published pricing is a mild positive signal: a vendor that will tell you the number has a model it will defend. Contact-sales for everything is not disqualifying, but you are planning against an unknown.
The pattern the cautionary cases share
Neither failure here happened the way people expect. There was no dramatic license change and no sudden shutdown. Hocus ended because the company funding it ceased to exist, which no license protects against. Daytona ended as a CDE because a different market looked better, and the code stayed nominally open on its tags while the development that mattered moved elsewhere. Both were single-vendor projects tied to one company's continued interest, and in both cases the repository looked healthy right up until it did not.
The counterexamples share a different property. Coder monetizes a clearly separated tier of the same open platform, so the open edition stays the product rather than a lead magnet. Eclipse Che sits under foundation governance with a commercial distribution downstream, so no single company's strategy change ends it. Neither is a guarantee - nothing here is - but both are structurally more durable than one company's goodwill.
Choosing on This Basis
Three honest positions, depending on what you actually need
If you need continuity
You want to still be running in three years regardless of anyone's business decisions. That narrows the field to platforms where the control plane itself is open and you operate it: Coder or Eclipse Che. It also requires the operational capacity described in build vs buy.
If you need boundary control
Source code and secrets must stay inside your network or jurisdiction. Bring-your-own-cloud arrangements and commercial self-hosted distributions both satisfy this without open source entering into it, which widens the field considerably. Be explicit that you are buying isolation, not independence.
If you want optionality
Neither requirement binds and you simply do not want to be trapped. The highest-value move is not choosing an open platform - it is keeping environment definitions in a portable open format such as dev containers, which preserves most of the exit value at a fraction of the cost.
A final caution about how this page will age. Several claims here contradict what the same vendors' marketing implies, and that gap will not close. A year in this category has been long enough for a license to disappear, a company to be renamed, a product to change markets, and an acquisition to be announced. Re-verify against the repository and the pricing page before a decision rests on any of it, and treat any comparison table - including this one - as a snapshot. Vendor evaluation covers building these tests into a scoring process rather than applying them once.
Related Reading
Selection, economics, and the wider market
CDE Tools
Platform-by-platform capability detail, including the commercial products this page does not cover
Build vs Buy
Whether you have the operational capacity that self-hosting an open control plane actually requires
Vendor Evaluation
Turning the durability tests above into a repeatable scoring process
CDE Market Guide
How the category is currently shaped, and which vendors have entered or left it
CDE Alternatives
Head-to-head comparisons for teams that have already narrowed the field
Cost Analysis
What a free control plane still costs once compute and staffing are included
Platform Engineering Maturity
Assessing honestly whether your organization can operate what it is proposing to adopt
Risk Management
Abandonment, acquisition, and relicensing as risks you plan for rather than react to
Sources and Citations
Every figure on this site with its publisher, year, and link, including the ones we decided not to use