DE

DevPod

Codespaces but open-source and self-hosted

IDEs & Code Editors ★ 15.2k stars Medium setup MPL-2.0

DevPod creates reproducible developer environments based on the devcontainer standard on any infrastructure you control. It works locally, in the cloud, or on a Kubernetes cluster.

Key features

  • Devcontainer-based environments
  • Runs anywhere
  • Client-only architecture
  • IDE integration

Pros & cons

Strengths

  • Open devcontainer standard
  • Works on any infrastructure
  • Client-only architecture

Trade-offs

  • Provider configuration needed
  • IDE support varies

DevPod replaces

Last reviewed Aug 26, 2026 · 731 words

DevPod has no server component. That sentence saves you an afternoon: there is nothing to host, no database, no dashboard to protect, and the self-hosting question becomes "where do I point it". It is a client, a Go binary plus an optional desktop app, that reads a devcontainer.json, builds the environment on whatever provider you choose, and connects your editor to it. The provider can be Docker on your laptop, a home server over SSH, a Kubernetes cluster, or a cloud VM. MPL-2.0 licensed, about 15,100 GitHub stars, and young: the first release was 2023.

What it is, and what it is not

Codespaces gives you a browser-based VS Code on a VM that GitHub runs. DevPod gives you the same devcontainer standard, so the same .devcontainer/devcontainer.json file works in both, but the compute is yours. What it is not is a portal. There is no web page where a team logs in and sees their workspaces; each developer runs DevPod locally and it talks to the provider directly. If you want the portal, templates and admin controls for a team, that is Coder, which is a server. If you want a persistent browser IDE on one machine, that is code-server. DevPod sits between them: reproducible environments, local tooling, no service to run.

The self-hoster's setup is the SSH provider

The most useful pattern for someone with a home server is to make that server the build host. Install DevPod on the laptop, add the SSH provider pointing at a user on the server that can run Docker, and create a workspace from a repository:

devpod provider add ssh -o HOST=dev@homebox
devpod provider use ssh
devpod up github.com/your-org/your-project --ide vscode

DevPod copies its agent to the server, builds the devcontainer there, and opens VS Code locally with a remote connection tunnelled through SSH. The laptop stays cool, the checkout and dependencies live on the server's disk, and closing the lid loses nothing. Put Tailscale on both ends and the same command works from a coffee shop. devpod stop frees resources, devpod up resumes with state intact, and devpod delete removes the container and its volumes. The Docker provider does the same on the local machine if the laptop is the strongest hardware you own.

IDE support is the part that varies

VS Code is first-class and behaves like the Remote Containers extension. JetBrains IDEs work through Gateway and are noticeably slower to attach. The openvscode option serves a browser IDE from the workspace, which is handy on a machine where you cannot install anything. Neovim and anything else terminal-based works with --ide none followed by devpod ssh, which is how I use it most of the time. Extensions, dotfiles and shell configuration are declared in the devcontainer file or via the dotfiles option, so a workspace on a new provider looks like the last one.

Where the friction is

Providers need configuration, and the cloud providers each want credentials, region, machine size and an idle-shutdown timeout set correctly or you get a bill for a VM that sat there all weekend. Devcontainer features fetch from the network at build time, so an offline build fails unless the image is prebuilt, and DevPod's prebuild command exists exactly for that. Docker-in-Docker inside a workspace works but is the usual privileged-container compromise. Memory on the build host is the constraint that actually bites: the catalogue floor is 512 MB for DevPod itself, but a workspace running a language server and a database easily wants 4 GB, so size the server for the workspaces, not the tool.

What I'd do

One developer, one home server, Tailscale between them: DevPod with the SSH provider is the setup I would choose without hesitation, because it costs nothing to run when idle and the devcontainer file makes the environment portable to Codespaces or a colleague's laptop unchanged. Three or more people who need to see each other's workspaces, enforce templates or hand out access: run Coder instead and accept the server. For the rest of the dev editors category, DevPod is the tool I reach for when I want reproducibility without another service to babysit.

Compare DevPod

6 head-to-head comparisons.

Similar ides & code editors apps