Engineering·July 2024·9 min read

Cloud-Based Development Environments: Advantages for Web Developers

"Cloud development environment" used to mean a vague promise of accessibility. Now it means a specific file: devcontainer.json, an open specification that GitHub Codespaces, VS Code, and other tools all implement the same way. Write the config once, and any compliant tool can stand up an identical environment.

The pitch for cloud-based development environments used to be abstract: work from anywhere, collaborate in real time, let someone else handle security patches. That pitch was true but vague enough to ignore.

What actually changed the calculus is a specification. The Development Container specification turned "cloud dev environment" from a vendor-specific product into a portable, version-controlled config file that multiple tools implement.

The devcontainer.json standard

A dev container is a Docker container, defined by a devcontainer.json file committed to the repository, that describes exactly what a working development environment needs: base image, extensions, environment variables, post-create commands, and forwarded ports.

What the spec actually standardizes

The Development Container Specification defines the schema for that file and the lifecycle hooks (onCreate, postCreate, postStart) that run at defined points in the container's setup. Any tool that implements the spec reads the same file and produces a functionally identical environment.

{
  "name": "storefront-web",
  "image": "mcr.microsoft.com/devcontainers/typescript-node:20",
  "features": {
    "ghcr.io/devcontainers/features/docker-in-docker:2": {}
  },
  "forwardPorts": [3000],
  "postCreateCommand": "pnpm install",
  "customizations": {
    "vscode": {
      "extensions": ["dbaeumer.vscode-eslint"]
    }
  }
}

That single file, committed alongside the code, is what makes the environment reproducible. A new hire's first commit no longer waits on a day of local setup instructions that are already out of date by the time they're read.

Who actually implements it

GitHub Codespaces, VS Code's Dev Containers extension, and the open-source devcontainer CLI all read the same devcontainer.json. That's the practical payoff of the spec existing: a config written for local VS Code Dev Containers works unchanged in Codespaces, and vice versa.

Features: reusable building blocks instead of copy-pasted install scripts

The spec also defines Dev Container Features: self-contained, versioned units of installation code (a specific Node version, Docker-in-Docker, a cloud CLI) that get declared in the features block instead of hand-written as shell commands. A team no longer copies a 40-line install script between repos and lets it drift.

Multi-service projects aren't left out either. The dev container metadata reference supports referencing a Docker Compose file directly, so a repo needing a database and a cache alongside the app container defines all of it in one place, using the same Compose file a production-adjacent environment might already use.

GitHub Codespaces in practice

A codespace is a development environment hosted in the cloud, backed by a Docker container running on a virtual machine, launched directly from a GitHub repository. Machine sizes range from 2-core, 8 GB RAM, 32 GB storage up to 32-core, 128 GB RAM, 128 GB storage, selected per codespace rather than fixed per developer.

Idle timeout is a cost control, not a bug

The default idle timeout is 30 minutes, after which an unused codespace stops automatically; a developer can raise it up to 240 minutes, and organizations can enforce a stricter cap for cost control. Treat this as a deliberate setting to tune, not a default to fight, since it's the main lever standing between a team's usage and its compute bill.

Prebuilds close the "first build is slow" gap

Without a devcontainer configuration, a new codespace still boots into a generic environment, but adding a dev container configuration lets a team specify exactly which tools and dependencies come pre-installed. Codespaces prebuilds go further, running the setup steps ahead of time so a developer opens an already-built environment instead of waiting through dependency installation.

The dev container config is the onboarding document now. A README that says "install Node 20, then run these five commands" goes stale the day a dependency version changes. A devcontainer.json enforces the same environment for everyone who opens the repo, including CI.

VS Code Dev Containers: the local option that isn't local setup

The same devcontainer.json also works entirely locally through VS Code's Dev Containers extension, running the container on the developer's own machine via Docker instead of in the cloud. This matters for teams that want reproducible environments without paying for hosted compute, or that need to work offline.

The trade-off is the developer's own machine still does the work, so a resource-heavy build (a large monorepo, a data pipeline with big local datasets) runs exactly as fast as the local hardware allows. Codespaces removes that constraint by moving the compute to GitHub's infrastructure, at the cost of ongoing usage billing.

Secrets don't belong in the devcontainer.json

The config file is committed to the repository, which makes it the wrong place for API keys, database passwords, or any credential the environment needs at runtime. GitHub Codespaces addresses this with encrypted Codespaces secrets, scoped per repository or organization and injected as environment variables at container start, never written into the committed config.

The same discipline applies running Dev Containers locally: secrets come from a local .env file excluded via .gitignore, or a secrets manager, not from anything checked into version control. A devcontainer.json that hardcodes a credential defeats the entire point of making the environment shareable.

GitHub's own security model for Codespaces covers the container isolation boundary too: each codespace runs in its own container on a dedicated VM, and network access from inside the container is subject to the same organization policies as any other GitHub-connected compute. That isolation is what makes it reasonable to run untrusted dependency installs inside a codespace in the first place.

A cloud dev environment is not a backup strategy

It's worth stating plainly: a codespace's disk is not where a team's source of truth should live. Git remains the record; the codespace is disposable compute that happens to have a filesystem attached to it.

Committing and pushing work in progress before letting a codespace idle out or get deleted is still the developer's responsibility, exactly as it is on a local machine. Cloud-based doesn't mean the usual git hygiene stops mattering.

Gitpod's shift, and why it matters for anyone evaluating tools now

Gitpod was, for years, the other major implementer of ephemeral cloud dev environments alongside Codespaces. That positioning changed: Gitpod Classic's pay-as-you-go tier sunset on October 15, 2025, with the company repositioning its platform as Ona, aimed at software engineering agents rather than solely human developers in a browser-based IDE.

Anyone comparing tools against older blog posts or vendor comparisons will hit stale information here. Check Gitpod's current documentation directly rather than a cached "Codespaces vs Gitpod" comparison, since the product's actual scope changed, not just its pricing.

Comparing the options

Criterion	GitHub Codespaces	VS Code Dev Containers (local)	Ona (formerly Gitpod)
Where compute runs	GitHub-hosted cloud VM	Developer's own machine, via Docker	Cloud, now positioned around agentic workflows
Config format	devcontainer.json (spec-compliant)	devcontainer.json (spec-compliant)	Own workspace config, evolving post-rebrand
Cost model	Usage-based billing per compute hour	No incremental cost beyond local hardware	Changed with the Ona repositioning; verify current pricing
Best fit	Teams wanting zero local setup, GitHub-native workflow	Teams wanting reproducibility without cloud billing	Teams building around agent-driven engineering workflows
Offline capable	No, requires the hosted session	Yes, once the image is built locally	Depends on current product architecture

Adopting a devcontainer.json in an existing repo

The migration path is incremental, not a rewrite. A team can add the config alongside an existing local setup process and let both coexist until confidence builds.

Start from an existing base image close to the current stack (Microsoft and the community publish a large set of pre-built devcontainer images for common language runtimes).
Add the current install/build commands as postCreateCommand, verifying the container reaches the same state as a working local setup.
Commit the file and have one developer test it fresh, ideally someone who didn't write it, to catch assumptions baked into the original local setup.
Add CI verification that builds the devcontainer image on every pull request, so config drift gets caught before a new hire hits it.

Where this actually pays off

The clearest return is onboarding time and environment-drift bugs, both of which are qualitative until a team measures them directly. A "works on my machine" bug tied to a Node version mismatch simply can't occur once everyone, including CI, launches from the same container image.

Standardization also changes who can safely review whose code. A reviewer running the exact same environment as the author can reproduce a failing test locally in the time it takes to open the codespace, instead of first reconciling two different local toolchains.

Security patching: updating the base image version in one file patches every developer's environment on next rebuild, instead of chasing individual machines.
Consistency with CI: a devcontainer image can double as the CI build image, closing the gap between "works locally" and "works in the pipeline."

A devcontainer.json isn't a convenience feature bolted onto an IDE. It's infrastructure-as-code applied to the one part of the stack most teams still configure by hand: the developer's own machine.

FAQ

Do we need GitHub Codespaces specifically, or does the devcontainer.json approach work with any Git host?

The devcontainer.json file itself is host-agnostic. It works with VS Code's Dev Containers extension against any Git repository; Codespaces is one hosted implementation of the same spec, not a requirement for using it.

What happens to a codespace when it's idle?

Codespaces stop automatically after a period of inactivity to avoid runaway billing, and can be resumed later; the underlying disk state persists between stops within GitHub's retention window.

Is Gitpod (Ona) still usable as a Codespaces alternative today?

Verify current scope and pricing directly against Ona's documentation before assuming feature parity with the older Gitpod Classic product; the October 2025 transition changed both positioning and, in places, the underlying product.

Does a devcontainer.json replace Dockerfile-based CI builds?

It can, since a devcontainer image is a real Docker image, but most teams keep a leaner CI-specific Dockerfile for production builds and use the devcontainer purely for the development experience.

Do JetBrains IDEs support the same devcontainer.json spec?

JetBrains has added dev container support in recent IDE versions; check the specific IDE and version against the spec's list of supporting tools before assuming full compatibility, since implementation completeness varies by tool.

References

From the Destm engineering archive. For current work on this topic, start at Solutions or the blog.