Dora NodaNine months before OpenAI wrote a check for it, this company killed its own flagship product on purpose. In September 2025, Gitpod — the cloud-dev-environment company that spent five years selling "we run the workspace so you don't have to" — rebranded to Ona and walked away from managed cloud dev environments entirely. Its replacement shipped self-hosted-only, AWS-only, no exceptions. On June 11, 2026, OpenAI announced it was acquiring what Gitpod had become.
That sequence is the whole story, and it's worth reading closely, because the obvious headline — "OpenAI buys dev-tools startup" — buries the actual decision underneath it: when the best-capitalized AI lab in the world needed infrastructure durable enough for Codex agents to run unattended for hours or days, it didn't build a proprietary managed sandbox on its own cloud. It bought a company whose entire architecture is "this runs inside your VPC, not ours."
The timeline: a company that un-launched itself
Gitpod's pivot wasn't a feature update. It was a full identity change, executed on a public deadline:
- September 3, 2025 — Gitpod rebrands as Ona, repositioning from "cloud dev environments" to what it called "mission control for your personal team of software engineering agents." The Register covered it as exactly what it was: a company abandoning its category.
- October 15, 2025 — Gitpod Classic's pay-as-you-go product shuts down entirely. Not deprecated, not frozen — sunset, with a hard date. (Gitpod Enterprise customers got an exemption from that specific deadline, but the PAYG product line that had defined the company for five years was gone.)
- The replacement, Gitpod Flex (later folded into Ona's "Core" tier), launched self-hosted-only and AWS-only at first — a company that had built its reputation on running infrastructure for customers now shipped a product that runs inside the customer's own cloud account by default.
- June 11, 2026 — OpenAI announces it will acquire Ona outright, folding its cloud-execution and orchestration platform into the Codex ecosystem. Terms weren't disclosed; the deal was still subject to regulatory approval at announcement.
Read end to end, that's a company that bet its survival on one architectural claim — that AI coding agents need infrastructure to run in the customer's own cloud, not a vendor's shared multi-tenant one — and got acquired by OpenAI for making that bet correctly, less than a year after making it.
What Ona actually built (and what OpenAI is buying)
The interesting part isn't the rebrand story — it's what shipped underneath it, because that's the part OpenAI is paying for.
Ona's self-hosted deployment runs on the customer's own AWS or GCP account, with the platform itself reporting a fixed infrastructure cost low enough to sit inside AWS's free tier — around $8/month for the control-plane footprint, with the customer's own compute billed separately at whatever the workload actually uses. On top of that self-hosted base, Ona layered the things an enterprise buyer actually asks for before trusting an agent with real access: role-based access control, SSO, OIDC, and audit logging. Pricing for the managed side runs on "Ona Compute Units" — a free tier, a Core plan starting around $10 for 40 OCUs, and custom enterprise deals — but the deployment topology is the differentiator, not the metering unit.
By the time of the acquisition, Ona was reporting that its own agents co-authored 60% of the pull requests merged to its main branch, and had contributed 72% of the code merged in the week before the deal was announced — the company dogfooding its own thesis that autonomous agents, not autocomplete, were the product.
OpenAI's stated reason for buying this, rather than building it, is specific: Codex needed a way to let agents keep running tests, fixes, and multi-step migrations for hours or days after the developer closed their laptop — and Ona already had the sandboxed, VPC-deployable execution layer built, with the RBAC/audit primitives regulated customers require already attached. The acquisition sits next to OpenAI's earlier purchase of Astral (bringing uv and Ruff into Codex) in the same lane: buying the plumbing that makes an agent credible for sustained engineering work, instead of writing it from scratch.
That plumbing is not a small thing to skip building. A customer-VPC execution model means solving per-tenant network isolation, credential scoping so an agent's cloud IAM role can't reach further than the one workload it's touching, and audit logging detailed enough to answer "what did the agent actually do" after the fact — all before a single line of agent logic runs. Those are exactly the primitives a regulated enterprise's security review asks about first, and they're also exactly the primitives that take a team quarters to get right, not weeks. A lab racing to make Codex credible for sustained, unattended work has an obvious incentive to buy a team that already shipped and hardened that layer rather than rebuild it under its own timeline pressure.
A second reading: self-hosting also solved Ona's own cost problem
There's a second reading worth naming, because it cuts against the neat "self-hosting proved itself" narrative: Ona's pivot to self-hosted-only wasn't originally a grand architectural thesis, it was survival math. A company selling managed cloud dev environments has to carry the compute cost of every idle workspace on its own balance sheet; a company whose product runs on the customer's AWS bill doesn't. Shipping self-hosted-only killed Gitpod Classic's actual cost problem at the same moment it repositioned around agents. That both things happened together doesn't make one a lie — it means the architecture that solved Ona's unit-economics problem was also, independently, the one OpenAI's engineers judged the most credible foundation for agent infrastructure nine months later. Two different problems, the same answer.
The honest counter-read
It would be easy to spin this as "self-hosting won" and stop there, but that overclaims what actually happened. Ona didn't survive as an independent self-hosted company proving out its own thesis for years to come — it sold itself to a hyperscaler-adjacent lab nine months after the bet, which is a very different outcome than "the architecture succeeded on its own terms." A skeptic's read is just as available: maybe this is OpenAI acquiring the tech to eventually fold it into OpenAI's own managed infrastructure, at which point "runs in your VPC" quietly becomes "ran in your VPC, until it didn't."
That's the fair objection, and it's exactly why the deployment topology matters more than the corporate outcome. What OpenAI actually announced buying wasn't a codebase to replatform — it was the customer-controlled-VPC execution model itself, explicitly framed as the answer for "enterprises in regulated industries that cannot use shared cloud environments." If OpenAI's plan were to collapse that back into a fully-managed, OpenAI-run sandbox, there'd be no reason to highlight the VPC deployment story in the acquisition messaging at all — that capability is only valuable to keep if you intend to keep selling it as a capability. The real test, and the one worth watching rather than assuming, is whether Ona's self-hosted deployment option is still on the price list a year from now, or whether it quietly becomes "coming soon" the way acquired products' inconvenient tiers often do.
What a build-vs-buy decision by OpenAI actually signals
Strip away the company drama and one fact stands on its own: OpenAI, facing a real engineering problem (agents that need to keep running after the human walks away), evaluated building a proprietary managed execution layer on its own infrastructure against buying a company whose core product runs inside the customer's own cloud account — and chose to buy the customer-owned-execution architecture.
That's not a hypothetical vendor comparison or a market-research survey saying enterprises say they want control over where agent code executes. It's the best-funded AI lab on the planet putting money behind the specific claim that when an autonomous agent needs real infrastructure — not a sandboxed demo, but something with SSO, audit trails, and a customer's own VPC boundary around it — the credible answer looks like Ona's architecture, not a black box the vendor operates unilaterally.
For a self-hosted PaaS built around AI agents as first-class operators — an agent that pushes a git repo, deploys it, and can roll it back, all against infrastructure the operator actually owns rather than a vendor's opaque control plane — that's not a marketing talking point invented to sound good. It's an unplanned, expensive data point from outside the self-hosting community entirely: even the company that doesn't need anyone's permission to build a proprietary agent-cloud from scratch looked at the problem and bought the "runs on infrastructure you control" answer instead.
What to watch next
The acquisition was still pending regulatory approval when it was announced, and terms weren't disclosed — so the honest scorecard has one entry, not a verdict. Whether this becomes the moment self-hosted, VPC-scoped agent execution went mainstream, or just an efficient way for OpenAI to acquire experienced engineers and a working prototype, depends entirely on whether Ona's self-hosted tier is still sold — unchanged, not quietly deprecated — a year from now. That's the number worth tracking, not the acquisition headline itself.
Bex.co is the open-source, AI-native Render alternative — an AI agent pushes a git repo and gets a running HTTPS service on machines you own, not a vendor's shared control plane. If a hyperscaler lab is buying its way into customer-owned execution for its own agents, see how bex's architecture already treats that as the default.
