Gitpod Classic Is Gone: Where to Code in the Browser Now
Gitpod Classic pay-as-you-go ended in October 2025. Compare Gitpod alternatives: Ona, Codespaces, or coding in the browser on a computer you already own.
The Coder IDE team · · 6 min read
If you used Gitpod Classic for browser-based coding, the pay-as-you-go plan you relied on is gone, and the product that replaced it has a different focus. You still need somewhere to open a repository in a browser, run it and get work done. This post explains what changed, what former Gitpod users actually need, and how the main options compare, including when your own computer is the better host and when it isn't.
What happened to Gitpod Classic
In September 2025 Gitpod rebranded as Ona and repositioned itself as, in its own words, "the mission control for software engineering agents". Alongside that, the company announced the sunset of Gitpod Classic pay-as-you-go on October 15, 2025. Enterprise customers were on separate timelines.
What that meant in practice for pay-as-you-go users, according to the announcement:
- After October 15, they could no longer log in or start new environments on Gitpod Classic.
- Continuing meant signing up for a new account on Ona.
- Secrets, projects, configuration and workspace data were not moved automatically and had to be migrated by hand.
.gitpod.ymlgave way todevcontainer.jsonplus anautomations.ymlfile, with agitpod env migratecommand to help.
If you missed the deadline, any uncommitted work left in an old workspace is likely gone. Anything you pushed to your Git host is safe, which is the first lesson of every cloud workspace shutdown.
What former Gitpod users actually need
Gitpod meant different things to different people. Before picking a replacement, figure out which of these you were really using it for:
- A browser editor on any device. You coded from a Chromebook, an iPad or a borrowed laptop where you couldn't install anything.
- A ready environment from config. Open a repo, get the right toolchain and dependencies without setting them up.
- Throwaway environments. A fresh workspace per branch or pull request, deleted when done.
- Onboarding. New contributors could start in minutes without a local setup.
- A free allowance. A few hours a month at no cost for side projects.
The right replacement depends on which items on that list matter. If it's mostly the first one, you may not need a cloud environment at all.
It's also worth asking what you'd lose by moving. A cloud workspace hides the cost of setup: someone else maintains the image, the network and the machine. Moving to your own computer means you own that again, which is a small job if your machine is already set up for the project and a bigger one if it isn't. Be honest about which camp you're in before you switch.
Cloud dev environments vs your own machine
There are two broad directions: rent a machine in someone's cloud, or reach the computer you already have from anywhere.
| Cloud environment (Ona, Codespaces) | Your own computer, opened in a browser | |
|---|---|---|
| Where code runs | Provider's VM | Your desktop, laptop or home server |
| Fresh environment per branch | Yes, a core strength | No, it's your one machine |
| Works with the computer off | Yes | No, the host must be on |
| Cost model | Usage, seats or plan tiers | Hardware you already own, plus a flat plan |
| Your local files, GPU, tools | Only what you put in the image | Everything already installed |
| Onboarding strangers | Easy, share a config | Not designed for it |
Cloud environments win on repeatability and on not caring whether your computer is on. Your own computer wins on hardware you've already paid for, a setup you've already tuned, and code that never leaves your desk. There's a longer case for the second approach in your computer is the best cloud dev environment you own.
Your devcontainer config still works locally
The good news from the migration is that the config format moved toward Dev Containers, an open spec that isn't tied to one vendor. A devcontainer.json you write today can be used by Ona, by GitHub Codespaces, or on your own machine with Docker and VS Code's Dev Containers extension or the devcontainer CLI.
That makes the decision lower stakes. You're not locking your environment definition into whichever host you pick next. A sensible migration path for a personal project looks like this:
- Make sure every repo you care about is pushed, including branches that only lived in old workspaces.
- Convert
.gitpod.ymlsetup steps into adevcontainer.json, or into a plain setup script if you don't want containers. - Test it once on your own computer.
- Decide where it runs day to day: a cloud environment, or your own machine opened from wherever you are.
Pricing compared
Prices change, so treat this as a snapshot and check each provider's page before deciding.
| Option | Free | Paid |
|---|---|---|
| Ona | At the September 2025 announcement: up to 3 parallel environments, machines up to 4 vCPUs and 16 GB RAM | Core for teams started at $20/month; Enterprise adds self-hosting in your own VPC |
| GitHub Codespaces | Personal accounts: 120 core-hours and 15 GB storage a month | 2-core machine at $0.18/hour, storage $0.07 per GB-month, billed even while stopped |
| Coder IDE | One computer | Pro $12/month for unlimited computers; Team $49 with seats, shared devices and SSO |
The models aren't directly comparable. Ona and Codespaces sell you compute. Coder IDE doesn't sell compute at all: it runs Microsoft's VS Code server on your computer and lets you open it in any browser or the Android app, so the machine's cost is whatever you already paid for it. The Codespaces comparison walks through the monthly math in more detail.
Where Coder IDE fits, and where it doesn't
Coder IDE is a good Gitpod replacement if your main use was "VS Code in a browser, from any device" and you have a computer that can stay on. You install it with one command on Windows, macOS, Linux or WSL, sign in, and confirm the code from a browser. The machine shows up on your dashboard and you tap Connect to start the editor. There's no port forwarding, VPN or certificates, and it works behind NAT and firewalls.
What you get is the real VS Code with your own extensions, settings, keybindings and terminal. Turn on Allow preview for a dev server's port in the Ports panel and you get a private link, which only opens for you, to check the running app beside your code or in its own tab. You can install it as a web app on a Chromebook or iPad, or use the Android app with a key bar for Esc, Tab, Ctrl, Alt and arrows. If you use Claude Code, you can follow and approve its sessions from your phone too.
It is the wrong choice if:
- You need a fresh environment per pull request. That's what cloud environments are built for.
- Your contributors don't have a capable machine. Coder IDE needs a computer to run on.
- Your laptop is your only computer and it's usually closed. The host has to be on to reach it.
- You need more compute than you own. Renting a big VM by the hour is the honest answer.
Plenty of people will end up with both: a cloud environment for open-source contributions and review branches, and their own machine for daily work.
Wrap-up
Gitpod Classic's end forced a decision that was easy to put off: do you need someone else's computer, or just a way to reach yours? If repeatable, disposable environments are the point, Ona or Codespaces are the natural next stop, and your devcontainer.json goes with you. If you mostly wanted VS Code in a browser on whatever device was nearby, your own computer can do that job without hourly billing.
Start free. The free plan covers one computer, and see how setup works before you install anything.
