Gitpod
Automated, ready-to-code development environments
Gitpod provides ephemeral, automated development environments that spin up from a Git repository. It can run on self-managed Kubernetes infrastructure for full control.
Key features
- Ephemeral dev environments
- Prebuilt workspaces
- Git provider integration
- Browser-based coding
Pros & cons
Strengths
- Reproducible dev environments
- Prebuilds speed startup
- Browser or desktop IDE
Trade-offs
- Self-hosted edition deprecated
- Requires Kubernetes
Gitpod replaces
Last reviewed Sep 13, 2026 · 794 words
Do not plan a new deployment around self-hosted Gitpod. The company retired the self-hosted edition in favour of a managed product that runs single-tenant inside your own cloud account, and while the AGPL-3.0 source is still on GitHub with 13,759 stars, installing it yourself means a Kubernetes cluster, 8 GB of RAM minimum, a wildcard TLS certificate, and an install path the vendor no longer supports. The idea Gitpod pioneered, ephemeral prebuilt dev environments from a Git URL, is very much alive; it has just moved to other tools for anyone hosting their own.
What "deprecated" means in practice
Gitpod Self-Hosted was a Helm-and-installer product that put the full platform on your Kubernetes: workspace manager, image builder, registry facade, proxy, database, and a set of daemonsets that need privileged access to nodes. The open-source repo still builds, and people still run it, but the installer targets Kubernetes versions that age out, the docs for the self-hosted path have been removed or frozen, and you will be debugging an orchestration system with no upstream to ask. For a company with a platform team and a strong reason (data residency, air-gapped networks) it remains technically possible. For a homelab or a small team it is a weekend that ends in a half-working cluster.
The workspace model is the part worth keeping
Gitpod's .gitpod.yml in a repository declares the container image, the tasks to run on start, and the ports to expose. Prebuilds run those tasks ahead of time on every push, so opening a workspace takes seconds instead of the ten minutes a npm install on a monorepo would cost. Editing happens in VS Code in the browser, VS Code desktop over SSH, or a JetBrains IDE through their gateway. This is what you are trying to recreate, and every replacement below implements some or all of it.
Coder is the honest successor for a team
Coder is the closest self-hosted match: a Go server that provisions workspaces from Terraform templates onto Docker, Kubernetes, or plain VMs, with VS Code in the browser, SSH access, JetBrains support, and prebuilt workspaces in recent releases. It runs on a single Docker host with a Postgres database and a couple of GB of RAM, which is where the comparison ends in Coder's favour. The cost is Terraform: templates are HCL, and someone on the team has to own them. Coder also has the Dev Container standard covered through its envbuilder project, so a repository with a .devcontainer/devcontainer.json works without a bespoke template.
code-server and DevPod for one person
If the team is you, the Kubernetes-shaped tools are overkill. code-server is VS Code served from a container on port 8080; put it on a box with your source checked out, behind your reverse proxy with authentication, and you have browser-based coding from any device in ten minutes and about 512 MB of RAM. It does not create environments per repository; it is one persistent machine with an IDE on it, which is what most solo developers actually want. DevPod fills the other gap: a client-side tool that reads devcontainer.json and spins the environment up on your local Docker, a remote SSH host, or a cloud VM, with no server component at all. The pair covers the Gitpod use case for an individual without running a platform.
If you insist on running the source
Budget honestly. You need a Kubernetes cluster (k3s works, but the workspace daemons want real kernel access, so this is a VM per node rather than containers-in-containers), 8 GB of RAM for the control plane before a single workspace, a container registry, a wildcard DNS record and certificate for *.ws.gitpod.example.com style workspace URLs, and an OAuth app on your Git provider. Expect to pin a Kubernetes version and never upgrade it, because nothing tests the combination any more. Treat it as an archaeology project, not infrastructure.
What I'd do
For a team of 3 or more that wants the Gitpod experience on their own hardware, Coder with Docker as the provisioner on one well-specced host, and devcontainer-based templates so the definitions stay portable. For a solo developer, code-server behind a reverse proxy, plus DevPod when a project genuinely needs an isolated environment. For a company evaluating Gitpod itself, use their managed offering in your cloud account and stop reading self-hosting guides. The tools in dev editors that are still maintained are all better bets than reviving the deprecated one, and the thing you actually miss, prebuilds, is the one Coder now covers.
Compare Gitpod
6 head-to-head comparisons.
Similar ides & code editors apps
code-server
IDEs & Code EditorsRun VS Code in the browser on your server
Replaces GitHub Codespaces
Eclipse Theia
IDEs & Code EditorsCloud and desktop IDE platform
Replaces VS Code, GitHub Codespaces
Coder
IDEs & Code EditorsSelf-hosted cloud development environments
Replaces GitHub Codespaces, Gitpod
JupyterLab
IDEs & Code EditorsWeb-based environment for interactive and reproducible computing
Replaces Google Colab
DevPod
IDEs & Code EditorsCodespaces but open-source and self-hosted
Replaces GitHub Codespaces
JupyterHub
IDEs & Code EditorsMulti-user server for Jupyter notebooks
Replaces Google Colab, Deepnote