What actually happens when a developer opens a browser tab, clicks a link, and starts writing code two seconds later? Somewhere, a container image was pulled, a disk was mounted, a network namespace was configured, and an identity was checked. Which of those steps the vendor handles for you, and which you have to own, is the real difference between GitHub Codespaces, Gitpod, and Google Cloud Workstations. The marketing pages all promise “instant, secure, consistent dev environments.” The architecture underneath decides whether that promise holds at 50 developers or 5,000.
This article looks at the decisions that shape everything else: where the workspace runs, how it is defined, how it starts fast, and how it connects to the rest of your infrastructure. The framing reflects the state of these platforms in late 2026, not a forecast of what 2027 will bring.
The core split: who owns the control plane
Every cloud development environment has two halves. The control plane decides who gets a workspace, schedules it, and tracks its state. The data plane is where the actual container, disk, and network live. The single most consequential architectural question is who operates the control plane.
| Platform | Control plane | Where workspaces run | Identity model |
|---|---|---|---|
| GitHub Codespaces | GitHub-managed | GitHub-managed Azure VMs | GitHub account and org policies |
| Gitpod (Flex) | Gitpod-managed or self-hosted | Your Kubernetes clusters or Gitpod infrastructure | Configurable, including self-hosted identity |
| Google Cloud Workstations | Google-managed, inside your project | GKE cluster in your GCP project | Google Cloud IAM |
Read that table slowly, because it explains most of the downstream differences. Codespaces is the most hands-off: you enable it, and GitHub does the rest. Cloud Workstations sits inside your own Google Cloud project, so the cluster, the network, and the audit logs are yours even though Google runs the service. Gitpod Flex, announced in 2024, moved toward running workspaces as containers on Kubernetes clusters you control or on Gitpod-managed infrastructure.
If your organization has a rule that source code never leaves a specific network boundary, that rule alone eliminates one or two of these options before any feature comparison begins. Start there, not with the feature matrix.
How each platform defines a workspace
The second decision is how much of your environment lives in version control. This is where portability is won or lost.
GitHub Codespaces is configured through a `devcontainer.json` file stored in the repository. That file is part of an open specification, and the dev container specification maintained by the community documents how images, features, lifecycle commands, and mounts are declared. The practical payoff is that the same configuration can drive Codespaces, VS Code Dev Containers on a laptop, and other tools that implement the spec.
Gitpod also supports devcontainer-compatible configuration, which means a repository set up for Codespaces is not starting from zero on Gitpod. Google Cloud Workstations takes a different path: it is configured through container images and workstation configurations managed in Google Cloud, with persistent home disks attached to each workstation. That model fits teams already standardized on Google Cloud artifacts and IAM, but it is less portable. Moving a Cloud Workstations setup to another vendor means rebuilding the configuration rather than copying a file. (Cloud networking architecture virtual networks actually work) (Cloud computing)
A practical tip from teams that run these platforms: put as much of the environment as possible into the repository-level configuration and as little as possible into vendor console settings. Every setting that lives only in a web console is a setting that will drift, get forgotten, and break a new hire’s first day.
Cold starts: prebuilds, snapshots, and boot disks
Nobody abandons a platform because of a feature list. They abandon it because opening a workspace takes four minutes. Startup time is an architecture problem, and all three vendors attack it the same way: do the expensive work ahead of time and store the result.
- Codespaces prebuilds build the container image and run setup steps ahead of time for a branch, so a new workspace starts from a prepared state.
- Gitpod prebuilds follow the same logic, preparing workspaces so that initialization happens before the developer asks for one.
- Cloud Workstations boot disks persist the state of a workstation’s disk, so a stopped workstation resumes with its installed tools intact.
The trade-off is identical everywhere: you pay for storage and background compute in exchange for faster starts. The mistake teams make is enabling prebuilds for every branch in a busy repository. That multiplies storage cost and queue time for builds nobody will use. A narrower rule works better in practice: prebuild the default branch and release branches, and let feature branches take the cold start.
The other common mistake is treating prebuilds as a fix for a slow setup script. If your configuration installs 40 packages and compiles a large dependency tree on every start, a prebuild hides the problem until it goes stale. Trim the setup first, then prebuild what remains.
Networking, identity, and the enterprise conversation
For a solo developer, networking barely registers. For an organization with a private package registry, a database behind a VPC, and an auditor asking who accessed what, networking is the whole conversation.
Cloud Workstations is built for that context. Because workstations run on GKE inside your project, they can be placed in private networks, reached through private endpoints, and governed by Google Cloud IAM, VPC Service Controls, and audit logging. The workspace is another resource in your cloud estate, subject to the same controls as a VM or a bucket.
Codespaces relies on GitHub identity and organization policies. Access is tied to GitHub accounts, and organization-level settings govern who can create codespaces and what they can reach. For teams whose source already lives on GitHub, this is a short path to a governed environment.
Gitpod Flex supports self-hosted operation, which appeals to organizations that want the control plane inside their own perimeter. Running your own control plane, though, means owning upgrades, availability, and capacity planning. That is a real operational commitment, not a checkbox.
The related discipline of connecting workspaces to private services without exposing them publicly is worth studying separately; the principles behind how cloud VPN architecture and site-to-site tunnels actually work apply directly to giving a remote workspace access to an internal registry or database. Likewise, the way cloud networking architecture and virtual networks actually work explains why placing a workstation in the right subnet matters more than most teams expect.
Storage and persistence: what survives a restart
Development environments are stateful in ways that surprise people. Installed tools, local databases, caches, and uncommitted work all live somewhere. The architecture question is what persists when a workspace stops.
Cloud Workstations attaches a persistent home disk, so the workstation’s filesystem survives shutdowns and restarts. Codespaces persists the repository and its changes, but the container itself is disposable; anything installed outside the configuration is gone when the workspace is rebuilt. Gitpod follows a similar disposable-container model, with persistence handled through the configuration and any explicitly mounted volumes.
This is where the “works on my machine” problem quietly returns. A developer who installs a tool manually inside a Codespace has created a dependency that exists in exactly one place. The fix is cultural as much as technical: treat the container as cattle, not pets, and push every durable change back into the configuration file. The same reasoning shows up in how cloud storage architecture actually works with objects and erasure coding, where durability is designed into the system rather than assumed from any single machine.
What this looks like at scale
At small scale, all three platforms feel similar. At larger scale, the differences compound.
Consider a company with 300 engineers, a private npm registry, and a compliance requirement that production data never touches a developer laptop. Cloud Workstations offers the cleanest story: workstations in a private network, IAM-scoped access, audit logs in the same place as everything else. The cost is tighter coupling to Google Cloud and a configuration model that does not travel.
Now consider an open-source-heavy team that already lives in GitHub pull requests. Codespaces removes almost all setup friction, and the devcontainer configuration doubles as documentation for local development. The trade-off is less control over the network path and a container lifecycle that discards anything not declared.
A platform team that wants a single internal developer platform across multiple source hosts might lean toward Gitpod Flex for its self-hosted control plane and Kubernetes-native model. The trade-off is that the platform team now operates a service, and that service needs an owner. (Docker overview)
None of these is universally right. The decision depends on which constraint is hardest: data boundary, operational appetite, or the pull of the existing toolchain.
Common mistakes worth avoiding
Three patterns show up again and again.
First, choosing on startup speed alone. A fast workspace that cannot reach the internal registry is useless, and a slow one that can is still work.
Second, ignoring the exit path. Before committing, ask what it would take to move a repository to a different platform. If the answer is “rewrite the environment configuration,” that is a cost worth pricing in now.
Third, treating the environment configuration as a one-time setup task. Environments drift. Base images get deprecated, package versions move, and a configuration that worked in January fails in July. Teams that succeed schedule regular rebuilds and treat configuration changes like code changes, reviewed and tested.
The broader shift toward containerized, declarative development environments is part of a larger movement in how cloud native computing architecture and how it works, where the environment becomes an artifact rather than a machine. That framing helps explain why the configuration file matters more than the vendor console.
Conclusion
The choice between Codespaces, Gitpod, and Cloud Workstations is not really a feature comparison. It is a decision about where your control plane lives, how portable your environment definition is, how much operational work you are willing to own, and which network boundary you cannot cross. Codespaces wins on simplicity for GitHub-centric teams. Cloud Workstations wins on governance inside Google Cloud. Gitpod Flex wins on control for platform teams willing to run infrastructure.
Answer those four questions honestly, and the platform choice usually makes itself. Answer them late, after a team has already built workflows around a console-only configuration, and the migration will cost far more than the evaluation would have.
Frequently asked questions
What is the main architectural difference between Codespaces, Gitpod, and Cloud Workstations?
The main difference is who operates the control plane and where workspaces run. Codespaces runs on GitHub-managed infrastructure, Cloud Workstations runs on a GKE cluster inside your own Google Cloud project, and Gitpod Flex can run on Gitpod-managed infrastructure or on Kubernetes clusters you operate yourself.
Can I move a dev environment between these platforms?
It depends on how the environment is defined. A repository configured with a devcontainer file has the best portability, since Codespaces, VS Code Dev Containers, and Gitpod all support that format. Cloud Workstations uses its own container image and configuration model, so moving to or from it generally means rebuilding the setup rather than copying a file.
Why do cloud development environments take so long to start sometimes?
Cold starts happen because the container image must be pulled and setup steps must run. All three platforms offer a way to do that work ahead of time, through prebuilds or persistent boot disks. Slow starts usually mean the setup script is doing too much, prebuilds are not enabled for the branches people actually use, or the image is large and rarely cached.
Is a self-hosted control plane more secure?
Not automatically. Self-hosting puts the control plane inside your perimeter, which can satisfy data-residency and network-boundary requirements. But it also means your team owns patching, availability, and capacity. A managed control plane with strong identity and audit controls can be equally defensible and requires far less operational effort.
What happens to files when a workspace stops?
On Cloud Workstations, the persistent home disk keeps the filesystem intact across shutdowns. On Codespaces and Gitpod, the container is treated as disposable, so committed repository changes persist but manually installed tools and uncommitted local state may not. Anything a developer needs permanently should be declared in the environment configuration.
How should a team decide which platform to standardize on?
Start with the hardest constraint, usually a network or data boundary, and remove options that cannot meet it. Then weigh operational appetite and existing tooling: GitHub-centric teams gain the most from Codespaces, Google Cloud-native organizations from Cloud Workstations, and platform teams that want full control from Gitpod Flex. Test with a real repository before committing.
