The “works on my machine” problem is a cliché precisely because it never actually went away. Teams write elaborate setup docs that go stale. New developers spend their first day installing dependencies rather than writing code. The senior engineer with a non-standard macOS configuration can’t reproduce the CI failure everyone else sees. Dev containers helped, but they still required everyone to have Docker running locally, and the first build always took longer than anyone expected.
GitHub Codespaces is the cleaner answer for a lot of teams. You define the development environment once in a devcontainer.json file, and anyone with repository access can open a fully configured cloud environment in under a minute. No local install, no Docker Desktop subscription disagreement, no “which version of Node are you on” troubleshooting. Just click open Codespaces and start writing code.
What You’re Actually Getting
A Codespace is a Docker container running on cloud compute, accessed through VS Code in the browser or through your local VS Code or JetBrains IDE connecting to the remote container. The environment is defined by a .devcontainer/devcontainer.json file checked into your repository, which specifies the base image, installed tools, VS Code extensions, forwarded ports, and any post-setup scripts to run.
The setup script runs once when the container is first created. After that, your environment persists between sessions — you’re not rebuilding from scratch every time you open Codespaces, just resuming where you left off. Files stored in the container and changes to the workspace persist for the lifetime of the Codespace (which you control; idle Codespaces are suspended after a configurable period to save cost, and deleted after another period of inactivity).
Machine types run from 2-core to 32-core configurations, with storage between 32GB and 64GB. The 2-core option handles most web development and lighter backend work comfortably. 4-core or 8-core machines are sensible for anything that involves longer build times or running multiple services simultaneously.
The Devcontainer Configuration
This is where Codespaces earns its keep for teams. A minimal devcontainer.json might look like:
{
"name": "App Dev",
"image": "mcr.microsoft.com/devcontainers/javascript-node:22",
"postCreateCommand": "npm install",
"customizations": {
"vscode": {
"extensions": ["esbenp.prettier-vscode", "dbaeumer.vscode-eslint"]
}
},
"forwardPorts": [3000, 5432]
}When a new developer opens a Codespace from this configuration, they get Node 22, the right extensions installed, dependencies fetched, and ports forwarded — without touching anything on their local machine. The time from “I’ve been given repo access” to “I’m running the application locally” can genuinely drop from half a day to ten minutes for complex projects.
For more involved setups, you can compose multiple services using Docker Compose in the devcontainer.json, which gives you a full application stack with database, cache, and background workers all starting up together in the cloud environment.
Prebuilds: Solving the Cold Start Problem
The one frustration with Codespaces out of the box is that the postCreateCommand runs every time a new Codespace is created, and for projects with heavy dependency installation or build steps, that’s slow. Prebuilds fix this.
You configure prebuilds in the repository settings, specifying which branches and devcontainer configurations to prebuild. GitHub Actions runs your setup steps in advance on a schedule or after each push, caches the resulting container state, and makes it available as the starting point for new Codespaces. The result is that opening a new Codespace on a prebuild-enabled branch feels almost instant — the dependencies are already there.
Prebuilds have a separate storage cost, but for active development branches where the team opens Codespaces frequently, the productivity win easily justifies it.
New in 2026: Enterprise Data Residency
GitHub launched Codespaces in public preview for GitHub Enterprise Cloud with data residency in January 2026. For organisations that operate under data residency requirements — EU/UK financial services, healthcare companies, or any business with contractual obligations about where compute runs — this removes a previous blocker to using Codespaces.
With data residency enabled, Codespaces containers run in a specified region and data doesn’t leave that geographic boundary. Audit logs through GitHub’s enterprise audit log streaming let you track who opened Codespaces, when, and from where. This won’t satisfy every compliance requirement, but it opens the door for teams that previously couldn’t consider cloud dev environments at all.
Where Codespaces Works Best
Onboarding is the clearest win. A new team member with repository access and a browser can be writing and running code in minutes, on the same environment configuration as everyone else on the team. No setup doc to follow, no OS-specific package manager quirks, no risk that their local environment diverges from what CI runs.
Open-source contribution is another strong use case. Contributing to a project you don’t maintain often means setting up a one-off local environment, dealing with dependency conflicts with your other projects, and forgetting to clean up afterwards. Codespaces gives you an isolated, pre-configured environment for the contribution, accessible from any device, that disappears cleanly when you’re done.
Working across multiple machines is also much smoother. If your workflow involves a work laptop, a personal machine, and occasional access from elsewhere, having your development environment in the cloud means you’re always working in the same context. Extensions, settings, and your current workspace state follow you.
GitHub Copilot is integrated by default in Codespaces environments if you have a Copilot subscription, which removes the extension setup step for teams using it.
Where to Stick With Local
Codespaces isn’t the right tool for everything. If your workflow involves heavy Docker image builds with large layer caches, you’ll find local builds faster in most cases — pulling and building from the cloud environment adds latency to a task that’s already slow.
Hardware-dependent development (iOS simulator on macOS, Windows-specific drivers, embedded hardware targets, GPU-accelerated machine learning with local CUDA setup) can’t run in Codespaces. Same for anything that requires USB device access or very low-latency local network connections.
Cost accumulates for sessions that run long. Codespaces charges per core-hour, so a developer who leaves a 4-core Codespace running over a weekend is burning compute budget. Setting auto-suspend timeouts (30 minutes of inactivity is reasonable) and being disciplined about stopping Codespaces when done keeps the cost predictable.
Pricing
Codespaces is included in GitHub’s paid plans with a monthly allowance before usage charges kick in. GitHub Teams includes 180 core-hours per month per user; GitHub Enterprise Cloud includes more. Beyond the allowance, per-core-hour pricing applies (currently US$0.18/hour for a 2-core machine). Storage for inactive Codespaces costs additionally per GB per month. Prebuilds consume storage as well.
For most development teams, the cost is modest relative to the productivity gain, but it’s worth setting spending limits in your organisation’s billing settings to avoid surprises.
Getting Started
The quickest way to evaluate Codespaces is to open any of your existing GitHub repositories, click the Code button, and choose “Open with Codespaces.” Without any devcontainer.json configuration, GitHub will use a default environment based on detected language. From there, add a .devcontainer/devcontainer.json file tailored to your project, commit it, and your team has a standardised environment waiting for them.