Ona (formerly Gitpod)
A managed service that can put runners in your own cloud account. That is not the same as self-hosting, the vendor's own documentation disagrees with its pricing page about who operates them, and an acquisition is pending.
What It Is
The rebuilt Gitpod, repositioned around agents rather than browsers
Ona is the current name of Gitpod, the product that arguably created the mainstream expectation that a development environment could be a URL. It provisions ephemeral, prebuilt environments from a repository and connects them to VS Code, JetBrains IDEs, or a browser session. The rename came with a shift in emphasis: the environments are now presented as somewhere coding agents work as much as somewhere people do.
Two structural facts matter more than any feature in the product, and both are easy to miss because the vendor's own materials handle them loosely. The first is what "self-hosted" means here. The second is that the company has entered into an agreement to join OpenAI, and that agreement had not closed when this page was written.
Neither is a reason to dismiss the product. Ona is a mature, capable platform with a real answer for teams that need source code to stay inside their own cloud account, and that answer is genuinely rarer than it was two years ago. But both facts change what you are signing up for, and both belong in the first conversation rather than the last.
Naming, so you can follow older material. Gitpod became Ona. "Gitpod Classic" is the older hosted product, whose pay-as-you-go option was sunset on 10-15-2025. The AGPL-licensed gitpod-io/gitpod repository is a third thing again, and is discussed further down. Comparison articles frequently blend all three.
Who It Suits, and Who It Does Not
Mostly a question of how much unresolved ownership risk your timeline can absorb
A good fit
- Teams that need source code and execution to stay inside their own AWS or GCP account but do not want to operate a control plane.
- Multi-repository web development, where prebuilds and fast environment startup pay for themselves daily.
- Organizations not on GitHub. Unlike Codespaces, Ona is not tied to a single forge.
- Teams running coding agents inside managed environments, which is where the product's current investment is visibly going.
- Buyers who want a published entry price rather than a sales process before they can compare anything.
A poor fit
- Anyone whose requirement is continuity rather than boundary control. You cannot install, fork, or keep operating the control plane without the vendor.
- Organizations making a multi-year standardization decision this quarter. An unclosed acquisition is a poor foundation for one.
- Air-gapped or on-premises environments. The runner model requires a supported public cloud account, not your data center.
- Windows or macOS toolchains. Ona environments are Linux, and the operating system is not a configurable dimension.
- Buyers who need cost certainty. The billing unit blends agent token consumption with infrastructure runtime, which is harder to forecast than an hourly machine rate.
The question that decides it
Ask why you wanted self-hosting. If the answer is "our code cannot leave our network", Ona's runner model probably satisfies you and is one of the few remaining products in the category that does. If the answer is "we need to still be running this if the vendor changes course", it does not satisfy you at all, and the honest shortlist is Coder or Eclipse Che instead. Those two requirements get bundled together in procurement documents constantly, and they eliminate completely different vendors.
Deployment Model
Bring-your-own-cloud runners under a vendor control plane, with the vendor's own wording in conflict
Environments run on "runners". A runner can be Ona Cloud, which is entirely Ona's infrastructure, or an AWS or GCP runner deployed into your own account and VPC on the Enterprise plan. In the second case source code is cloned and executed inside your network, on compute you pay your cloud provider for directly. The orchestration plane that schedules, authenticates, and manages all of it remains Ona's in both cases, and that is the part with no customer-operated option.
Ona's own materials contradict each other on who operates the runner. The pricing page describes the Enterprise deployment as self-hosted in your own VPC and managed by Ona. The runners documentation puts 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 instead of on Ona-managed infrastructure.
Do not resolve this from a web page, and do not let a comparison article resolve it for you. Ask Ona directly, in writing, who is on the hook for patching, upgrading, and responding to an incident on the runner in your account, and get it into the contract. The operational answer determines headcount, and the two published answers imply different staffing.
| Concern | Ona Cloud runner | AWS or GCP runner (Enterprise) |
|---|---|---|
| Control plane | Ona | Ona. No customer-operated option exists. |
| Where source code executes | Ona's infrastructure | Your own AWS or GCP VPC |
| Who pays for compute | Ona, priced into the subscription | You, on your own cloud bill, in addition to the Ona subscription |
| Runner operations | Ona | Disputed between Ona's pricing page and its documentation. Confirm contractually. |
| Availability if Ona stops | Service ends | Service ends. Your VPC keeps the compute; nothing orchestrates it. |
That last row is the one to sit with. Bring-your-own-cloud gives you a network boundary and a data-jurisdiction story, which is real value that a security review will accept. It does not give you an exit. Compare against GitHub Codespaces, which offers regional residency but no runner in your account at all, and against the genuinely self-hostable platforms covered in open source CDEs.
License and Open Source Reality
The commercial product is proprietary. The open repository is real, and the maintainer tells you not to run it.
What you buy is closed
Ona the product is proprietary. There is no source for the control plane, no community edition of the current platform, and nothing you could stand up independently. Treat the open repository below as historical context rather than as a fallback plan.
The AGPL repository still exists
gitpod-io/gitpod is AGPL-3.0, public, and not archived. Its README states that Gitpod has been renamed to Ona and that this version is no longer recommended, directing readers to the free tier or to sales. The separate gitpod-io/self-hosted repository has carried a deprecation notice since Gitpod 0.5.0 and was archived read-only on 04-24-2026.
What open-but-discouraged code is actually worth
Less than a license badge implies. You have the source under a strong copyleft license, which is not nothing. You do not have security patching, an upgrade path, compatible documentation, or any commitment that the next commit will land. A repository whose own maintainer recommends against running it is a reference implementation, not a supported product, and staffing a fork of a platform this size is a decision with a headcount attached.
It is also worth saying that Ona has been unusually clear about this. The README says plainly that the project was renamed and is no longer recommended, rather than quietly leaving a stale repository to imply an option that does not exist. That is more honest than several vendors in this category manage.
Pricing
An entry price is published. The unit it is denominated in is the complicated part.
| Plan | Price, as of July 2026 | What it includes |
|---|---|---|
| Core | From $20 per month | 80 to 2,200 OCUs, up to 100 members, environments on Ona's AWS infrastructure up to 32 vCPU, 128 GB RAM, 200 GB disk. Additional OCUs from $10 per 40 OCUs. |
| Enterprise | Custom, not published | Adds AWS and GCP runners in your own VPC, single sign-on, and audit trails. Your cloud bill is separate and additional. |
Figures above are from Ona's own pricing page as of July 2026: ona.com/pricing. Enterprise pricing is not published, so no total-cost comparison against a per-hour competitor is possible without entering a sales process.
Understand the OCU before you model anything
Ona bills in Ona Compute Units. Its documentation describes an OCU as a normalized measure of resource consumption covering two things: agent token usage from planning, coding, and automation tasks, and the infrastructure resources consumed while development environments are running. That is a blended unit, not a machine-hour.
The practical consequence is that your bill moves with how much your agents talk, not only with how long your environments are up. That is defensible as a pricing design - it reflects what the vendor actually spends - but it makes forecasting harder than an hourly rate card, and it means a change in agent usage patterns can move spend without anyone changing a machine size. Run a metered pilot and measure OCU consumption against real workloads before extrapolating. FinOps for development environments covers the controls for exactly this failure mode.
One further budgeting note for the Enterprise path: the subscription does not include the compute. Runners in your own account bill to your own cloud provider, so the total is the Ona contract plus the AWS or GCP spend the environments generate. Cost analysis works through comparisons that account for both sides.
Architecture and Isolation
Ephemeral VMs, prebuilds, and a boundary you can audit at the VPC
VM-based environments
Ona's documentation describes environments as secure, ephemeral VMs provisioned from a Dev Container configuration, each with its own compute, storage, and networking. Note the direction of that sentence: the Dev Container file is the input, and what it produces is a virtual machine rather than a container. Secondary write-ups routinely get this backwards. The environments are Linux, so a non-Linux toolchain is still out of scope.
Prebuilds as the performance story
Building dependencies ahead of time so an environment resumes rather than compiles is the mechanism behind the product's startup reputation, and it remains one of the more mature implementations in the category.
The security boundary is the VPC
On the runner model, the control you gain and can audit yourself is that execution happens inside your own network, with your own security groups and IAM. The per-environment VM boundary is Ona's own stated design; the network boundary is the part you own.
Agents change the isolation question
Ona positions environments as a place for coding agents to work, and putting an agent in an ephemeral VM inside your own VPC is a materially better posture than letting it run on a laptop with production credentials. Ona's stated boundary here is stronger than a shared-kernel container, which is worth crediting. It is also a development environment rather than a purpose-built sandbox: if your workload is arbitrary, unreviewed, model-generated code executing at volume, get the isolation mechanism in writing and compare against products designed for that shape of work. See microVM isolation, agent fleets, and the E2B review.
Status and Durability
The section that should carry the most weight in this particular decision
Pending transaction. On 06-11-2026 Ona announced that it had entered into an agreement to join OpenAI as part of the Codex team. Ona's own announcement states that the transaction is subject to customary closing conditions including receipt of required regulatory approvals, and that until close the two remain separate and independent companies. It had not closed as of July 2026. Source: ona.com/stories/ona-joins-openai.
Take the announcement at face value rather than reading either optimism or doom into it. An agreement to be acquired is not an announced shutdown, acquisitions frequently leave products running for years, and being absorbed into a well-funded buyer's flagship coding effort is not obviously worse for the product than remaining independent. Nobody has said Ona is being discontinued, and this page is not predicting that.
What has genuinely not been addressed is everything a buyer would want addressed. There has been no public statement about the future of the Core plan, the bring-your-own-cloud runner model, the AGPL repository, or support commitments for existing customers after close. A buyer standardizing an engineering organization on this platform is making a three-year decision against a set of unanswered questions, and no amount of product quality compensates for that if the timeline is unforgiving.
Track record of change
A rename, a repositioning toward agents, the sunset of Gitpod Classic pay-as-you-go on 10-15-2025, and the archiving of the self-hosted repository on 04-24-2026. That is a lot of movement, and it argues for reading contract terms rather than roadmap slides.
What you would lose
If the product changed direction, the environments themselves are recoverable - configuration is code and the compute may already be yours. The orchestration, prebuild pipeline, and access model are not. Budget the migration as weeks, not days.
Proportionate response
Negotiate term length and exit assistance explicitly, avoid deep coupling to proprietary configuration where a portable equivalent exists, and set a review date rather than assuming you will notice. Re-verify before signing.
Set against the rest of this category the picture is less unusual than it sounds. AWS closed two products to new customers, JetBrains discontinued Space, and Daytona left the category entirely. Ona at least has a well-capitalized acquirer and an operating product. But vendor evaluation and risk management exist precisely for decisions shaped like this one, and skipping them here would be a mistake.
Related
The direct alternatives, and the frameworks for weighing this kind of risk
Coder vs Ona
What changes when you operate the control plane yourself instead of renting it
Ona vs GitHub Codespaces
The two managed options side by side, on runners, data residency, and ownership risk
Self-Hosted vs Managed
The decision this page sits inside, before you compare any two products
GitHub Codespaces
The closest managed competitor, with published hourly pricing and a far more settled ownership question
Open Source CDEs
Where to look if the requirement is continuity rather than a network boundary
Google Cloud Workstations
Another way to keep environments in your own cloud account, if that account happens to be Google's
All CDE Tools
The full field, including the genuinely self-hostable platforms
Risk Management
Treating acquisition and repositioning as risks you plan for rather than react to
Vendor Evaluation
Turning "who actually operates this" into a contractual question with a written answer
FinOps
Controlling a blended billing unit that moves with agent usage as well as runtime
Data Residency
What a runner in your own VPC does and does not satisfy for a compliance reviewer
Sources and Citations
Every figure on this site with its publisher, date, and link
