Leaving Gitpod: Where Cloud Dev Environments Went in 2026

If your team was on Gitpod Classic, you've already had this year's unpleasant surprise. The SaaS product shut down in October 2025, Gitpod rebranded to Ona, and the platform was rebuilt on a proprietary, non-Kubernetes runtime with a different centre of gravity: AI agents rather than human-driven workspaces.

That's a legitimate strategic move, and Ona may well be the right destination for some teams. But "the product you bought became a different product" is a migration event whether you wanted one or not.

Here's the landscape, written for someone who has to make a decision rather than admire the market.

First: what were you actually using it for?

This matters more than any feature table, because the alternatives diverge sharply depending on the answer.

Ephemeral per-PR environments. Click a link, get a fresh workspace, review, discard. If this was the value, you want something optimised for fast cold starts and prebuilds.

Standardised team onboarding. One environment definition, everyone gets the same thing, new hires productive on day one. Here, reproducibility and configuration-as-code matter more than startup latency.

Escaping laptop constraints. Builds too heavy for a MacBook, or a monorepo that needs real hardware. You care about machine sizes and cost per hour.

Working from anywhere / BYOD. Contractors without source on their disks, or your own second machine. Access control and persistence matter.

Somewhere for AI agents to work. Newer motivation, increasingly the deciding one. Requirements differ from all of the above — see below.

Teams that migrate badly usually do so by matching on features instead of on which of these they were actually buying.

The realistic options

Ona (the incumbent path)

The least disruptive if your usage maps onto where they're going. You keep the vendor relationship and much of the mental model, and the AI-agent direction is a real bet on where development is heading.

Worth checking: the runtime rewrite means self-hosting characteristics changed. If you were self-hosting on Kubernetes specifically, verify that path still exists in the form you need before assuming continuity.

GitHub Codespaces

The path of least resistance for GitHub-centric teams. Deep integration, devcontainer-based config that's broadly portable, usage-based pricing.

The real constraints: it's GitHub-only, and it gives you a development workspace rather than an environment story. No per-PR preview environments, no staging, no production management — those remain separate problems. Usage-based billing is also genuinely hard to forecast; teams routinely underestimate it because idle time and prebuilds accumulate quietly.

Coder

The enterprise self-hosted answer. Workspaces defined in Terraform, running on your infrastructure — Kubernetes, AWS, GCP, Azure, or bare metal — with RBAC, audit logging, and policy controls owned by your platform team.

The economics are the pitch: per-seat pricing on hosted CDEs adds up fast, and for a team of any size, self-hosted infrastructure cost is often a fraction of it. The trade is that you now operate the platform, which is a real ongoing cost in people, not just money. Coder makes sense with a platform team and stops making sense without one.

DevPod and devcontainer tooling

Open source, client-side, no server component. Runs devcontainers locally, on a VM, or in the cloud, and avoids lock-in almost by construction.

Best fit for individuals and small teams who want reproducibility without a platform. Less compelling if you need centralised control, audit trails, or managed infrastructure — it deliberately doesn't provide those.

Managed development platforms

A different category rather than a like-for-like replacement: the workspace, the managed database, SSL, domains, and deployments come together, and the environment persists rather than being rebuilt per session.

Right when you want infrastructure to disappear entirely and expect AI agents to keep working on a project over time. Wrong if you specifically want ephemeral per-PR environments — that's a different shape, and you should use a tool built for it. (EasySpawn is in this category; more below, honestly labelled.)

A comparison worth trusting

	Ona	Codespaces	Coder	DevPod	Managed platform
Hosting	Vendor	Vendor	Self-hosted	Bring your own	Vendor
Git host	Any	GitHub only	Any	Any	Any
Config as code	Yes	devcontainer	Terraform	devcontainer	Platform-managed
Ephemeral per-PR	Yes	Partial	Yes	Manual	Not the model
Persistent workspaces	Varies	Limited	Yes	Yes	Yes
Managed database	No	No	No	No	Yes
Deployments	No	No	No	No	Yes
Ops burden	Low	Low	High	Medium	Low
Lock-in risk	Medium	Medium	Low	Very low	Medium

No row here is universally "best." A high ops burden buys control; low lock-in costs convenience.

What to verify before you commit

Migration pain is almost never in the features. It's in these:

Startup time on your repo. Vendor benchmarks use small repos. Test yours, cold and warm. The gap between the two tells you how much prebuild infrastructure you'll end up maintaining.
What persists. Ask explicitly: after a restart, do you keep the working tree, uncommitted changes, installed dependencies, and environment variables? Answers vary more than you'd expect.
Region and latency. A workspace 180ms away is a daily tax on everyone. Check where it actually runs.
Real cost at real usage. Model idle time honestly — people leave workspaces running. Per-seat and usage-based pricing fail in opposite directions; know which one punishes your pattern.
The exit. Before migrating in, work out how you'd migrate out. You just learned why this matters.
Config portability. Devcontainer-based setups move between tools reasonably well. Proprietary formats do not.
Agent support, if that's the direction. Can an agent run commands, read output, and be interrupted? Does its work survive between sessions?

Don't migrate the wrong thing

The most common mistake is porting a workflow that was itself a workaround.

If half your Gitpod configuration existed to fight cold starts — elaborate prebuilds, caching layers, warm pools — check whether the new platform makes that unnecessary before you faithfully recreate it. Teams routinely carry years of accumulated workarounds into a new system that didn't have the problem.

Same for the environment definition. A forced migration is a rare, genuinely good moment to delete the accumulated cruft, because you're touching all of it anyway.

Where EasySpawn does and doesn't fit

Being straight about this, since this is our blog.

Good fit if you want infrastructure to be someone else's problem entirely — persistent workspaces with managed Postgres, SSL, domains, and deployments included, and you expect AI agents to keep working on projects over time rather than in one-shot sessions.

Bad fit if you need ephemeral per-PR environments (different model), self-hosting on your own infrastructure (use Coder), or full root access to the machine (use a VPS). We're also pre-launch, which is a real consideration if you're migrating a team on a deadline — evaluate accordingly.

The summary

Gitpod's shutdown forced a decision on a lot of teams. Use it well: work out what you were actually buying, test cold-start and persistence on your own repository, model the cost at realistic usage, and check the exit before you walk in.

And delete the workarounds. They were solving a problem your next platform may not have.

EasySpawn provides managed cloud development environments with persistent workspaces, managed databases, automatic SSL, and deployments. See pricing or join the waitlist.