Skip to main content
InfraGap.com Logo
Home
Getting Started
Core Concept What is a CDE? How It Works Benefits CDE Assessment Getting Started Guide Inner Loop vs Outer Loop Environment Drift Local vs Cloud CDEs for Startups
AI & Automation
AI Coding Assistants Agentic AI AI-Native IDEs Agentic Engineering AI Agent Orchestration AI Governance AI-Assisted Architecture Shift-Left AI LLMOps Autonomous Development AI/ML Workloads CDEs for Data Science GPU Computing
Agent Infrastructure
Agent Experience (AX) Agent Egress Control Computer Use Agents Agent Evals Agent Runbooks Agent Client Protocol AGENTS.md MCP Servers Git Worktrees Kubernetes Agent Sandbox Agent Fleets Agent Identity Prompt Injection Defense Agent Observability Context Engineering AI Code Review Bottleneck Headless Agents in CI Spec-Driven Development Agent Readiness Code Provenance
Implementation
Architecture Patterns DevContainers Advanced DevContainers Language Quickstarts IDE Integration CI/CD Integration Platform Engineering Developer Portals Container Registry Multi-CDE Strategies Remote Dev Protocols Nix Environments Hermetic Builds OpenTofu for CDEs Kubernetes Development
Operations
Performance Optimization High Availability & DR Disaster Recovery Monitoring Capacity Planning Multi-Cluster Development Troubleshooting Runbooks Ephemeral Environments Sandbox Environments Workspace Snapshots Database Branching
Security
Security Deep Dive Zero Trust Architecture Secrets Management Vulnerability Management Network Security IAM Guide Supply Chain Security Air-Gapped Environments AI Agent Security MicroVM Isolation Compliance Guide EU AI Act Cyber Resilience Act Data Residency Governance
Planning
Pilot Program Design Stakeholder Communication Risk Management Migration Guide Cost Analysis FinOps GreenOps Vendor Evaluation Training Resources Developer Onboarding Team Structure Platform Maturity Model Open Source CDEs AI Productivity Paradox Build vs Buy DevEx Metrics Productivity Engineering Industry Guides CDEs for Healthcare CDEs for Financial Services CDEs for Government Edge Development WebAssembly in CDEs
Resources
Tools Comparison State of CDEs 2026 Isolation Decision Tool Template Library
Learning Paths
All Paths Platform Engineer Security and Compliance Engineering Manager
Vendor Reviews
GitHub Codespaces Coder Ona Google Workstations Microsoft Dev Box Okteto Eclipse Che DevPod Daytona E2B
Head to Head
Coder vs Codespaces Coder vs Ona Ona vs Codespaces Coder vs Okteto Self-Hosted vs Managed E2B vs Daytona CDE Market Guide CDE vs Alternatives Case Studies Lessons Learned Glossary FAQ Sources & Citations

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.

ConcernOna Cloud runnerAWS or GCP runner (Enterprise)
Control planeOnaOna. No customer-operated option exists.
Where source code executesOna's infrastructureYour own AWS or GCP VPC
Who pays for computeOna, priced into the subscriptionYou, on your own cloud bill, in addition to the Ona subscription
Runner operationsOnaDisputed between Ona's pricing page and its documentation. Confirm contractually.
Availability if Ona stopsService endsService 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.

PlanPrice, as of July 2026What it includes
CoreFrom $20 per month80 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.
EnterpriseCustom, not publishedAdds 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.