Coder vs Ona
Both are sold to buyers who said "we need self-hosting". They mean two completely different things by it, and only one of them survives the question "could you keep running without the vendor".
Checked against both vendors' own documentation, pricing pages, and repositories as of July 2026
The Word Doing Two Jobs
Procurement documents bundle two requirements into one phrase, and those requirements eliminate different vendors
With Coder, both halves are yours. You install and operate the control plane, its PostgreSQL database, and the provisioner that runs Terraform, and every workspace runs on compute you own. Coder Technologies operates nothing in the serving path. The platform is AGPL-3.0, so if the company changed direction tomorrow your installation keeps running until you decide otherwise.
With Ona, formerly Gitpod, the split is different. On the Enterprise plan, runners deploy into your own AWS or GCP account and VPC, so source code is cloned and executed inside your network on compute you pay your cloud provider for directly. But the orchestration plane that schedules, authenticates, and manages all of it stays with Ona, and there is no customer-operable version of it at any tier.
That distinction is the whole page. Ona's runner model is a genuine answer to "our code cannot leave our network", and a security reviewer will accept it. It is not an answer to "we need to still be running this if the vendor changes course", because nothing in the Ona relationship survives Ona. Those two requirements arrive stapled together in most procurement documents, and separating them early saves an entire evaluation cycle.
At a Glance
The Ona column below describes the Enterprise runner model, which is the only configuration worth comparing to Coder
| Dimension | Coder | Ona (Enterprise runners) |
|---|---|---|
| Control plane | Yours. You install and run it. | Ona's. No customer-operated option exists. |
| Where code executes | Your cloud, your cluster, or your own hardware | Your own AWS or GCP VPC, on the Enterprise plan |
| Who operates the runtime | You, unambiguously | Disputed by Ona's own materials. See the section below. |
| Workspace shape | Anything Terraform can provision - containers, pods, VMs, bare metal | Ephemeral Linux VMs provisioned from a Dev Container configuration. No Windows or macOS environments are documented, and you do not choose the hardware. |
| Air-gapped or on-premises | Supported | No. The runner model requires a supported public cloud account. |
| Published entry price | Community free. Premium not published - billed annually per user, quote only. | Core from $20 per month. Enterprise not published. |
| Billing unit | Per user annually, plus your own cloud bill | OCUs, a blended unit covering agent tokens and environment runtime, plus your own cloud bill on Enterprise |
| Open source position | AGPL-3.0 platform, actively released; Premium features under a separate commercial license | Product is proprietary. gitpod-io/gitpod is AGPL-3.0 and public, with a README stating it is no longer recommended. |
| If the vendor stops | Your installation keeps running. It becomes a support problem. | Service ends. Your VPC keeps the compute; nothing orchestrates it. |
| Ownership status | Independent, private, venture-backed | Agreement to join OpenAI announced 06-11-2026, not closed as of July 2026, subject to regulatory approval |
Sources: coder.com/pricing, github.com/coder/coder, ona.com/pricing, and Ona's own announcement of the OpenAI agreement, all checked in July 2026. See sources for the citation standard this site publishes against.
A Question Neither Page Answers Consistently
On Coder the operator is obvious. On Ona the vendor's own materials disagree.
Ona's pricing page and its runners documentation do not agree on who manages an AWS or GCP runner. The pricing page describes the Enterprise deployment as running in your own VPC and managed by Ona. The runners documentation places AWS and GCP runners in a "managed by you" column, against Ona Cloud's "managed by Ona", and the AWS overview describes running inside your AWS environment rather than on Ona-managed infrastructure.
This page does not resolve that, because it cannot be resolved from a web page. Ask Ona in writing who patches, upgrades, and responds to an incident on the runner in your account, and get the answer into the contract. The two published answers imply different headcount, and headcount is the thing you are actually comparing against Coder.
That matters because the usual argument for Ona over Coder is "you get the boundary without the operational burden". If the runner in your account turns out to be yours to operate, a meaningful part of that argument moves. You would still avoid running a control plane, which is real, but you would be running compute infrastructure in your own VPC on a vendor's schedule - which is a narrower saving than the pitch implies.
On the Coder side the equivalent question has an unambiguous answer, and it is not the flattering one: everything is yours. The server, the database, the ingress, the upgrade cadence, and the Terraform templates all need a named owner. Coder does not pretend otherwise, and a buyer who cannot name that person should treat that as disqualifying rather than as something to solve later. Vendor evaluation turns "who actually operates this" into a written question.
Cost, and Two Different Kinds of Uncertainty
Neither side can be modeled end to end from public information, but they are unmodelable for different reasons
Ona: a published entry price in an unfamiliar unit
Ona's Core plan starts at $20 per month as of July 2026, covering 80 to 2,200 OCUs and up to 100 members, with additional OCUs from $10 per 40. Having a number at all is an advantage over Coder for procurement. The complication is the unit: Ona's documentation describes an OCU as a normalized measure covering both agent token usage and the infrastructure consumed while environments run. Your bill therefore moves with how much your agents talk, not only with how long an environment is up, which is harder to forecast than a machine-hour and can move without anyone changing a machine size. Enterprise, which is the tier that unlocks runners in your own VPC, is not published at all - and on that tier your cloud bill is separate and additional.
Coder: a free edition with an unpriced tier above it
Coder Community is free and open source, with unlimited workspaces, templates, and members inside a single organization, limited to one platform integration and one external authentication integration. Premium adds multi-organization access control, audit logging, quotas, high availability, workspace proxies, custom roles, and an SLA, and Coder publishes no price for it. Underneath either edition sits your own cloud bill for every workspace, plus the engineering time to own the platform - which on a small team routinely exceeds every license figure in this comparison.
What to do about it
Run a metered pilot on Ona and measure OCU consumption against real workloads rather than extrapolating from the plan description. On Coder, price the cloud footprint of your actual workspace sizes and auto-stop policy first, and only then ask for a Premium quote - the license is usually the smaller number.
The line item nobody budgets
On Coder it is the person who owns the control plane. On Ona Enterprise it is the cloud spend the runners generate, which is invoiced by AWS or GCP rather than by Ona and therefore lands in a different budget from the one the decision was approved against. FinOps covers both.
Who Should Choose Which
Concrete conditions. Each of these decides the question on its own.
Choose Coder when
- The requirement is continuity, not just a boundary - you must be able to keep operating if the vendor's direction changes.
- You are air-gapped, on-premises, or in a data center rather than a supported public cloud.
- Workspaces must run on hardware you choose - bare metal, specific GPU nodes, ARM, or a non-Linux operating system.
- You have a funded platform team already operating Kubernetes, Terraform, and PostgreSQL.
- An unresolved acquisition is unacceptable in a multi-year standardization decision your timeline cannot revisit.
Choose Ona when
- The requirement is a network boundary and a data-jurisdiction story, and a vendor-run control plane clears your security review.
- You have no platform team and no intention of acquiring one, but still cannot let code leave your account.
- Your work is Linux multi-repository development that a Dev Container configuration already describes, where prebuilds pay for themselves daily.
- You want to start against a published entry price this week rather than open a sales process.
- Your horizon is a pilot or a one-year term you are willing to re-evaluate, rather than a five-year commitment.
The single question that sorts most teams
Ask why you wanted self-hosting in the first place, and insist on one answer rather than two. If it is "our code cannot leave our network", Ona's runner model satisfies you and is one of the few products in this category that still does without handing you a control plane. If it is "we need to still be running this in three years regardless of what happens to the company", Ona does not satisfy you at all and no contract term fixes that. Writing the real answer down before the first demo is the highest-value hour in this evaluation.
What Cannot Be Compared
Nobody has measured these, and no comparison that claims to has shown its method
Cost at scale
Coder Premium is unpublished and Ona Enterprise is unpublished. The two configurations a large organization would actually buy therefore have no comparable public prices, and any table that shows them side by side is showing estimates.
Environment startup time
Ona's prebuild mechanism has a strong reputation and Coder's start time depends entirely on your template and provider. No independent benchmark comparing them was found, and the comparison would not generalize across repositories anyway.
Runner operational load
Because Ona's own materials disagree on who manages an in-VPC runner, the operational cost of the Ona side is not knowable from public sources. That is a genuine unknown, not a rounding error, and it is the exact figure the comparison hinges on.
What the acquisition does and does not tell you
On 06-11-2026 Ona announced it had entered into an agreement to join OpenAI as part of the Codex team, subject to customary closing conditions including regulatory approvals, and it had not closed as of July 2026. Nobody has said Ona is being discontinued and this page does not predict that. What is genuinely unaddressed is the future of the Core plan, the runner model, and support commitments after close - and unanswered is different from bad.
What an open repository is worth here
Both products have AGPL-3.0 code on GitHub, and the two situations are not equivalent. Coder's repository is the platform, actively released. The gitpod-io/gitpod repository is public and not archived, but its README says the project was renamed and is no longer recommended, and gitpod-io/self-hosted, already carrying a deprecation notice since Gitpod 0.5.0, was archived read-only on 04-24-2026. A license badge is not a fallback plan; a maintained release line is.
Related
The reviews behind this page, and the frameworks underneath it
Coder vs GitHub Codespaces
The same self-hosted side against the other major managed option
Coder vs Okteto
Coder against the other product teams try to self-host, and why they are not interchangeable
Coder Review
What you take on when every component is yours, and what AGPL-3.0 actually buys
Ona Review
The runner model, the OCU, and the unresolved ownership question in full
Self-Hosted vs Managed
The decision framework, and why it turns on whether you have a funded platform team
Ona vs GitHub Codespaces
The managed-versus-managed comparison, where the boundary is the only real difference
Open Source CDEs
What "open source" covers in each product, license by license
Risk Management
Planning for acquisition and repositioning rather than reacting to them
Vendor Evaluation
Pinning down what a vendor means by "self-hosted" before you sign
FinOps
Controlling a blended billing unit, and the cloud bill that lands in another budget
Sources and Citations
Every figure on this site with its publisher, date, and link