Self-Hosted Cloud IDEs in 2026: code-server, Coder, and What Running One Really Takes

There are good reasons to want a cloud IDE on your own infrastructure. Code that can't leave your network. Compliance requirements. Hardware you already own. Or simply not wanting a per-seat bill from a vendor whose product might change under you — a lesson a lot of teams learned when Gitpod Classic shut down.

The options range from "one command on a spare server" to "a platform your infrastructure team operates." This guide maps them, and is specific about the work each one leaves with you.

Project status and licensing were checked in September 2026. Open-source projects move; check each repository's recent activity before standardising on it.

First, decide what you're actually building

"Self-hosted cloud IDE" covers two quite different things:

A remote editor for one person. Your editor in a browser, running on a machine with more power than your laptop, reachable from anywhere. Setup is an afternoon.
A development-environment platform for a team. Many users, each with their own isolated workspace, created from a standard template, with authentication, quotas, auditing, and someone responsible when it breaks. Setup is a project; operating it is a job.

Most disappointment with self-hosting comes from starting with a tool for the first and expecting it to become the second.

Remote editors for one person

VS Code Remote-SSH and Remote Tunnels

Not strictly self-hosting an IDE — you keep the desktop VS Code app and point it at a remote machine. Remote-SSH connects over SSH; Remote Tunnels connects through a relay Microsoft runs, so the machine doesn't need an open port.

Why it's often the right answer: you get the real VS Code with the full Microsoft extension marketplace, and nothing to host except the machine itself. If "I want my editor to run on a bigger box" is the whole requirement, start here.

Limits: you need the desktop app (or vscode.dev in a browser for tunnels), and tunnels route through Microsoft's service, which may not fit a strict network policy.

code-server

code-server, from Coder, runs VS Code as a web application: install it on a server, open a browser, and you have VS Code in a tab. It's MIT-licensed, mature, and genuinely a ten-minute setup.

OpenVSCode Server

OpenVSCode Server, originally from Gitpod, does the same job with a thinner layer over upstream VS Code. The choice between the two is mostly taste; code-server has more built-in conveniences, OpenVSCode Server tracks upstream more closely.

The extension catch

Both browser-based options share one limitation worth knowing before you commit: Microsoft's Visual Studio Marketplace terms restrict its extensions to Microsoft's own VS Code products. Open-source builds like these use the Open VSX registry instead. Most popular extensions are there, but some Microsoft-published ones — certain language servers and remote-development tools among them — aren't available or aren't licensed for use outside VS Code. Check your team's must-have extensions against Open VSX first.

Platforms for teams

Coder

Coder is the most established self-hosted platform. Workspaces are defined as Terraform templates, so a workspace can be a Docker container, a Kubernetes pod, or a cloud VM — whatever your template provisions. Developers connect with a browser IDE, desktop VS Code, JetBrains IDEs, or plain SSH. The core is open source, with enterprise features (like advanced access control and auditing) in paid tiers.

Strengths: runs on your infrastructure of choice, very flexible, and built for platform teams that want policy and control. It's where many teams leaving hosted CDEs land.

What it asks of you: Terraform fluency, the underlying infrastructure (a Kubernetes cluster or cloud account), and someone who owns the templates. Coder is excellent at orchestrating workspaces; you still own everything the workspaces run on.

Eclipse Che

Eclipse Che is a Kubernetes-native platform: every workspace is a pod, configured with devfiles. Red Hat sells it commercially as OpenShift Dev Spaces.

Strengths: a natural fit if you already run Kubernetes or OpenShift and want workspaces to be ordinary cluster workloads.

What it asks of you: a Kubernetes cluster and the expertise to run one. It's hard to recommend without both.

DevPod

DevPod takes a different approach: no server at all. A client on your machine creates devcontainer-based workspaces on a provider you choose — local Docker, a cloud VM, a Kubernetes cluster. It was a popular open-source answer to "Codespaces without the vendor."

A caution: upstream development has slowed markedly — no stable release since early 2025 as of this writing — and the community has discussed maintaining a fork. It still works, but check the project's current state before building a team workflow on it.

Other options

JetBrains shops should look at JetBrains' own remote-development tooling, including CodeCanvas for self-hosted environments. And for many small teams, plain devcontainers plus a shared cloud VM get surprisingly far — see What Is a Dev Container?.

What running one really takes

The IDE is the easy part. Here's what self-hosting actually hands you — true of every option above, in varying amounts.

Authentication in front of everything. A browser IDE is a terminal on your server, exposed over HTTP. code-server's built-in password is not enough for the open internet. Put it behind SSO, a VPN, or a private network like Tailscale — never publish it with just a password.

TLS and websockets. You need certificates, and a reverse proxy that handles websocket connections correctly. Misconfigured proxies are the most common cause of "the terminal keeps disconnecting."

Isolation between users. On a team platform, each developer's workspace has to be walled off from the others — separate filesystems, enforced CPU and memory limits, no shared credentials. One developer's runaway build shouldn't freeze everyone else's editor. Linux users on a shared server don't achieve this; containers or VMs do. We explain why in Docker vs Linux Users for Multi-Tenant Isolation.

Persistence and backups. What survives when a workspace restarts? Home directories, uncommitted work, local databases? And who backs up the volumes those live on? A self-hosted IDE with no backup plan loses someone's week eventually.

Updates. Security patches for the host, the IDE server, the base images, the orchestrator. A browser-reachable terminal is not something to leave on last year's version.

Cost you don't see on an invoice. The main pitch for self-hosting is that infrastructure costs a fraction of per-seat pricing, and that's often true. But the comparison has to include the people-hours: the engineer who maintains the templates, answers "my workspace won't start," and gets paged when the cluster has a bad day. We break down that side of the equation in The Real Cost of a Cloud Development Environment.

Choosing

One developer, wants a remote machine: VS Code Remote-SSH, or code-server behind Tailscale. Done by lunch.
Small team, no platform engineers: devcontainers on shared VMs, or a managed platform. Running a team CDE without anyone to own it rarely ends well.
Team with a platform function and compliance needs: Coder. It's what it's built for.
Kubernetes-standardised organisation: Eclipse Che or OpenShift Dev Spaces, or Coder on Kubernetes.
You want workspaces plus the databases, domains, and deployments around them, without operating any of it: that's a managed development platform — a different category from a self-hosted IDE, and worth comparing honestly. Our comparison pages include where each alternative is the better choice.

The honest trade

Self-hosting buys control: over where code lives, what it costs at scale, and whether the product changes under you. It costs operational responsibility, and that cost is easy to underestimate because it doesn't arrive as a bill.

If you have the people to carry that responsibility, self-hosting is a strong position. If you don't, the ten-minute install is the cheapest part of a much longer commitment.

EasySpawn is the managed alternative for people who want persistent cloud workspaces without operating them: isolated containers per workspace, a full terminal reachable from browser, phone, or SSH, managed databases, SSL, and backups — with Claude Code running in the workspace. See how it works or compare the options.