Dora NodaThe company that taught developers to throw away localhost just sold itself — not as a dev-environment company, but as a cage-builder for AI agents. On June 11, 2026, OpenAI announced it will acquire Ona, the German cloud-development company known until its September 2025 rebrand as Gitpod, and fold the team into its Codex group. The press release barely mentions developers. It talks about execution: secure, persistent cloud sandboxes where coding agents keep working for hours or days after the laptop closes.
That framing is the story. A company built over years on cloud dev environments for humans concluded that the durable product is agent sandboxes — and the company building the agents agreed strongly enough to buy it. For teams deciding where their agents' compute should run, the deal redraws the map: the self-hostable path just got narrower, and the honest comparison between owning your agent infrastructure and renting it from a model vendor just got urgent.
The deal in five facts
1. The announcement. On June 11, 2026, OpenAI said it will acquire Ona, the Kiel-based startup formerly known as Gitpod GmbH, to give Codex persistent cloud execution environments. The Ona team, led by CEO Johannes Landgraf, will join OpenAI's Codex division once regulatory approvals are finalized. Financial terms were not disclosed.
2. The stated why. Codex agents should take on longer-running, multi-step work — codebase refactors, test runs, multi-day engineering tasks — without being tied to a single device or an active session. OpenAI CFO Sarah Friar put it plainly: the acquisition brings "secure cloud infrastructure into Codex so agents can keep working for longer — over hours or days, not just minutes."
3. The scale. Codex reported more than 5 million weekly users at the time of the announcement, a roughly 400 percent increase from the beginning of the year. Ona, for its part, had served over 2 million developers in its cloud environments. This is not an acqui-hire for a prototype; it is infrastructure for an agent user base that quadrupled in five months.
4. The enterprise shape. Ona's distinctive bet is customer-controlled execution: agents run inside the organization's own cloud environment, behind its own VPC boundary, while the vendor supplies orchestration and intelligence. The package around it is the enterprise checklist — role-based access, single sign-on, audit logging, network controls — which is why Ona could already point to customers in banking and pharmaceuticals. Landgraf's line that agents need "more than intelligence" — they need a "trusted workplace" — is the entire thesis in one sentence.
5. What OpenAI actually bought. Strip away the branding and Ona is a factory for disposable, pre-credentialed workspaces: sandboxed cloud environments pre-loaded with dependencies, authenticated against source control, databases, and secret managers, with auto-checkpointing so work survives interruptions. One industry writeup summarized it as OpenAI buying "a cage, not a coder" — the controls around the agent, not the agent itself.
The pivot that made the deal possible
None of this was a surprise to anyone watching the company's trajectory. The customer changed species — from human developer to AI agent — a full year before the acquisition. The timeline tells it:
| When | What happened | What it signaled |
|---|---|---|
| Oct 2024 | Gitpod ships Flex, a total replatform that abandons Kubernetes after six years | The old architecture could not carry the next product |
| Sep 2025 | Gitpod rebrands as Ona, "mission control for software engineering agents" | Humans stop being the primary user |
| Oct 15, 2025 | Gitpod Classic pay-as-you-go shuts down | The human-CDE business model sunsets with the brand |
| Jun 2026 | OpenAI announces the Ona acquisition | A model vendor prices agent execution above dev environments |
Each step narrowed the company's identity: from "cloud dev environments for every developer" to "secure cloud execution and orchestration for AI agents." By the time OpenAI came calling, Ona had already rebuilt its platform, its brand, and its packaging around the agent as the primary tenant. The acquisition did not change the company's direction; it confirmed that the direction was worth buying.
That is the signal the self-hosting world should take seriously. When the defining CDE vendor of the last decade decides its future is agent sandboxes, "where does agent compute run" stops being a niche infrastructure question and becomes the main event.
The honest comparison: who owns your agents' computer
Here is that comparison with no flattery in either direction. On one side: model-vendor-owned agent execution, the Ona-inside-Codex shape. On the other: self-hosted agent execution in the Coder mold, where the entire agent system — control plane, orchestration, and execution — runs on infrastructure the customer owns and operates. Coder made that positioning explicit with its May 2026 launch of self-hosted, model-agnostic Coder Agents, with CEO Rob Whiteley arguing that "companies are being forced to choose between adopting AI agents and maintaining control over their infrastructure and data" — and that self-hosting removes the tradeoff.
| Dimension | Model-vendor-owned (Ona inside Codex) | Self-hosted (Coder-style, your infra) |
|---|---|---|
| Control plane owner | OpenAI operates orchestration and agent runtime | You operate the control plane on your machines |
| Data plane location | Your cloud/VPC under customer-controlled execution — but wired to the vendor's runtime | Your cloud, your VPC, your runtime; code never leaves your perimeter by construction |
| Model choice | Optimized for Codex; switching models means switching execution stacks | Model-agnostic by design — Anthropic, OpenAI, Google, Bedrock, or self-hosted models behind one execution layer |
| Self-host path | None independent of the vendor: the maker's roadmap now belongs to OpenAI's Codex group | The whole point: runs on your Kubernetes, your VMs, your Terraform |
| Cost shape | Vendor meter on top of cloud spend; agent token bills already run $2,000–$5,000 per developer per month at heavy usage (Gartner via June 2026 reporting), so the meter you pay on matters | Compute at your cloud's raw rate with idle workspaces shut off automatically; Coder prescribes no infrastructure, so workspace cost is whatever your underlying compute costs |
| Acquisition/shutdown exposure | Demonstrated live: your sandbox vendor can become a division of a model vendor | You hold the deployment; a vendor acquisition cannot repossess your running agents |
Two rows deserve emphasis because they cut against lazy assumptions on both sides.
First, the vendor-owned column is not the surveillance nightmare the most ardent self-hoster imagines. Customer-controlled execution — agents running in your VPC with your SSO and your audit logs — answers the compliance objection that killed earlier "send us your repo" products. If your threat model is "code must not leave our perimeter," Ona's architecture genuinely addresses it. The lock-in is softer than it looks at the data layer.
Second, the self-hosted column is not free. "Runs on your machines" means you operate a control plane, you patch it, and you hold the pager when agent orchestration breaks at 2 AM. What self-hosting buys is not cheapness but optionality: model independence, roadmap independence, and immunity to exactly the kind of acquisition this post is about. When your sandbox vendor gets bought by a model vendor, the self-hosted team reads the news over coffee; the hosted team reads the migration guide.
The market is consolidating around hosted cages
The Ona deal is not an isolated event. It is the third move in a consolidation wave that has spent 2026 steadily narrowing the self-hostable path for agent sandboxes:
- Daytona went closed-source in June 2026. The production codebase for one of the most credible E2B alternatives is now hosted-only; the open-source repository is frozen and unmaintained. Teams that picked Daytona as their self-hostable sandbox layer now have a vendor, not a project.
- E2B stays open-source — with an asterisk. Self-hosting E2B means running its Firecracker-plus-Nomad control plane yourself, and only on GCP at general availability, with AWS still in beta. The self-host path exists but carries real operational weight and a short platform list.
- Modal, Blaxel, and Fly.io Sprites are managed-only. There was never a self-host conversation to have; you rent the cage or you do not use it.
- The framework layer now defaults to hosted. OpenAI's April 2026 Agents SDK update wired seven sandbox providers — Blaxel, Cloudflare, Daytona, E2B, Modal, Runloop, and Vercel Sandbox — directly into the framework as swappable backends. Sandbox selection is now a config flag, and every default option is somebody else's cloud.
Read the landscape table that results:
| Sandbox | Isolation tech | Self-host path in Sep 2026 |
|---|---|---|
| Ona (acquired by OpenAI) | Container sandboxes, VPC/customer-cloud execution | None independent of OpenAI's Codex group |
| Daytona | Firecracker microVMs, stateful workspaces | Gone — production source closed June 2026 |
| E2B | Firecracker microVMs | Yes, but Firecracker + Nomad you operate; GCP GA, AWS beta |
| Modal | gVisor containers | None — managed-only |
| Coder Agents | Your VMs/Kubernetes via Terraform | Yes — self-hosting is the product |
The direction of travel is unmistakable: every quarter, another cage gets a landlord. The CDE-to-sandbox pivot that made Ona acquirable is the same pivot pulling the whole category toward hosted execution — because agents, unlike humans, do not complain about latency to a faraway sandbox, do not need a browser tab, and happily run wherever the orchestrator puts them. The economic gravity all points one way.
What this means for self-hosted compute
So where does that leave a team that wants its agents' computer to be its computer? Three questions cut through the noise:
1. Is your execution layer model-independent? The deepest lock-in in the Ona deal is not where containers run — it is that the sandbox roadmap now answers to the Codex roadmap. A self-hosted execution layer that can point at any model provider (or a self-hosted model) survives every future acquisition in this space. Model-agnosticism is the actual moat; everything else is plumbing.
2. Can you still leave? Count your self-hostable options today: Coder Agents on your own infrastructure, E2B self-hosted if you can carry Firecracker-plus-Nomad on GCP, or raw VMs and containers you orchestrate yourself. That list was longer eighteen months ago and will likely be shorter eighteen months from now. Every hosted-only dependency you add is a bet that its vendor's roadmap, pricing, and ownership stay friendly forever — a bet Daytona's self-hosters just lost.
3. Are you buying execution or operations? Here is the gap nobody in the landscape table fills: all seven of the Agents SDK's default sandbox providers are general-purpose code-execution boxes. None of them is a deploy-and-operate primitive — nothing that takes an agent's output and turns it into a running, supervised service on your own fleet with domains, TLS, rollbacks, and logs. Sandboxes run code; they do not operate software. A team that self-hosts execution but still deploys by hand has only done half the job.
That last gap is the opportunity the consolidation wave leaves open. The model vendors are buying cages. The PaaS layer above the cage — git-push to running service, on machines you own, drivable by an agent through a machine-readable API — is still nobody's acquisition target, which means it is still yours to own. Own the fleet, keep the execution layer model-independent, and the next acquisition announcement in this space is someone else's migration project, not yours.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.
