The promise of cloud development environments — every developer on an identical setup, no “works on my machine” — has been clearly understood since GitHub Codespaces launched it into the mainstream. The problem is that Codespaces locks you into GitHub’s infrastructure and pricing. If you’re on GitLab, or if you want to use your own cloud account, or if you want to run environments on-premise, you’re out of luck.

DevPod, from Loft Labs, solves this by separating the dev environment specification from the infrastructure that runs it. It uses the same devcontainer.json format that Codespaces supports — so existing container configurations work without changes — but the environments can run on local Docker, AWS, GCP, Azure, DigitalOcean, Kubernetes, or any SSH-accessible machine.

How DevPod Works

DevPod is a client-only tool. It doesn’t run any server-side infrastructure; it connects to whatever compute backend you configure. The architecture is:

  • devcontainer.json: The specification file that defines the container image, installed tools, extensions, port forwards, and lifecycle scripts. This is the same format used by VS Code Dev Containers and GitHub Codespaces.
  • Providers: Backends that DevPod uses to provision and manage containers. Providers exist for Docker (local), AWS EC2, GCP, Azure, DigitalOcean, Kubernetes, and any SSH host. You can run multiple providers and pick per-workspace.
  • Workspaces: A running dev environment. You create one from a Git repository URL, a local folder, or a devcontainer.json spec.

Because DevPod is client-side only, you’re not paying for any DevPod-specific infrastructure. You’re using compute you already have or paying cloud provider rates directly — typically cheaper than managed Codespaces, especially for larger instances.

Getting Started

Install DevPod from the releases page or via package managers:

# macOS
brew install loft-sh/tap/devpod

# Linux
curl -L -o devpod "https://github.com/loft-sh/devpod/releases/latest/download/devpod-linux-amd64" && \
sudo install -c -m 0755 devpod /usr/local/bin

For local development using Docker, add the Docker provider:

devpod provider add docker

Start a workspace from a Git repository:

devpod up github.com/your-org/your-repo --ide vscode

DevPod will pull the devcontainer.json from the repository, build the container, and open it in VS Code (or JetBrains IDEs, or a browser-based IDE if you prefer). From that point on, it works identically to a VS Code Dev Container — same extensions, same tools, same port forwarding.

Adding Cloud Providers

The practical advantage of DevPod over local dev containers is the ability to offload compute to the cloud when you need more resources — a machine learning project, a large compilation, a database-heavy integration test suite.

Adding an AWS provider:

devpod provider add aws
devpod provider use aws

# Configure the provider with your preferred instance type
devpod provider configure aws \
  --option AWS_REGION=eu-west-1 \
  --option AWS_INSTANCE_TYPE=t3.xlarge

Once configured, devpod up creates an EC2 instance, starts the dev container on it, and tunnels the VS Code connection through. The instance is created fresh for the workspace and can be configured to terminate when the workspace is stopped — avoiding the idle-compute problem.

For teams, DevPod Pro (the commercial version from Loft Labs) adds centralised workspace management, SSO, and audit logging, but the open-source CLI is fully functional for individual and small team use.

devcontainer.json Compatibility

If your repository already has a .devcontainer/devcontainer.json file configured for GitHub Codespaces or VS Code Dev Containers, DevPod uses it as-is. This includes:

  • image: The base container image
  • features: Pre-built toolchain components (Node.js, Python, Rust, etc.) from the Dev Containers specification
  • postCreateCommand / postStartCommand: Setup scripts that run when the container starts
  • customizations.vscode.extensions: VS Code extensions to install automatically
  • forwardPorts: Ports to tunnel to the local machine

The spec compatibility means teams can use the same devcontainer.json for GitHub Codespaces (via GitHub) and DevPod (via any other infrastructure) without maintaining separate configurations.

Kubernetes Provider

For teams already running Kubernetes clusters — common for infrastructure teams, platform engineering teams, or those using cloud-managed clusters — the Kubernetes provider is compelling. Dev environments run as pods in your cluster, using your existing node pool, IAM permissions, and network configuration.

devpod provider add kubernetes
devpod provider configure kubernetes \
  --option KUBERNETES_NAMESPACE=devpod \
  --option KUBERNETES_STORAGE_CLASS=standard

This is useful for workflows where the dev environment needs access to internal cluster services — staging databases, internal APIs, service mesh sidecars — that would otherwise require complex VPN or port-forward configurations.

When DevPod Makes Sense

Use DevPod instead of GitHub Codespaces when:

  • You’re not on GitHub, or want to avoid GitHub’s pricing for larger instances
  • You want environments running in your own cloud account (for compliance, data residency, or cost reasons)
  • You need dev environments with access to internal Kubernetes services
  • You want flexibility to run locally or in the cloud without changing the workflow

Stick with Codespaces (or Gitpod) when:

  • You’re deep in the GitHub ecosystem and the integration simplicity matters
  • You need the managed experience — no infrastructure to configure
  • Your team is small and Codespaces pricing is acceptable

Use VS Code Dev Containers directly when:

  • Local Docker is sufficient and you don’t need cloud burst capacity
  • You want zero external dependencies

DevPod sits between VS Code Dev Containers (local only) and Codespaces (managed but locked in). It’s the right tool when you want the portability of the devcontainer.json standard without being tied to a single cloud provider’s runtime.

References