Self-hosted remote development in 2026: revisit Coder, DevPod and Eclipse Che before you buy another cloud IDE seat

Many teams still treat the laptop as the only place code can live. When that breaks, the next habit is to buy another managed cloud IDE seat, copy the team into a hosted workspace product, and hope the bill and the data residency story stay quiet. That path can be right. It is not the only path, and it is a poor default when you have not asked what you need to operate.

A self-hosted cloud development environment (CDE) keeps the workspace on infrastructure you control. Developers still open VS Code, JetBrains or a browser editor. The difference is that the compile, test and agent loops run in a container, VM or Kubernetes pod that your platform team owns. This post revisits three open-source options that teams still meet when they want that model without renting another seat by habit: Coder, DevPod, and Eclipse Che. Red Hat OpenShift Dev Spaces appears only as the productised Che on OpenShift, not as a fourth peer. The aim is not to crown a winner. The aim is to help you pick something you can operate.

The short version

• Coder: control-plane product with Terraform templates, WireGuard-style networking and a clear OSS vs Premium split. Strong when you want org-wide workspace governance.
• DevPod: client-only Dev Container launcher over Docker, SSH, Kubernetes or cloud VMs. Strong for individuals and small teams that refuse a central server.
• Eclipse Che: Kubernetes-native CDEs defined with Devfile, with browser VS Code by default. Strong when the cluster is already your platform. OpenShift Dev Spaces is Red Hat’s supported Che product on OpenShift.

What a self-hosted remote development platform actually does

Before comparing tools, it helps to be clear about the job. A practical self-hosted CDE usually covers some mix of these:

• Define the workspace as code: Terraform, devcontainer.json, Devfile, or a mix, so a new hire does not rebuild a laptop from chat history.
• Provision compute: start a container, VM or pod with the right CPU, memory, GPU and idle shutdown rules.
• Connect the editor: SSH, VS Code Remote, JetBrains Gateway, browser IDE, or a web terminal, without opening random public ports by hand.
• Keep credentials and source closer to home: sync git and registry credentials carefully, and keep source on infra you can audit.
• Day-2 ops hooks: templates, quotas, auth, audit logs, and a story for upgrades.

It is not magic. You still own the cluster or VMs, DNS, identity, disk and restore drills. The win is that you stop reinventing “works on my machine” for every repo, and you stop treating a managed IDE seat as the only adult option.

Coder: Terraform templates and a control plane you host

History and licence. The project lives at coder/coder. The repository was created in December 2021 under the coder organisation. The open-source core is licensed under the GNU Affero General Public License v3.0 (AGPL-3.0), as stated on GitHub and in the repository LICENSE file. The tree also contains an enterprise/ directory governed by a separate LICENSE.enterprise file: production use of that Enterprise Software requires agreement with Coder’s Terms of Service (or another agreement with Coder). Treat AGPL for the community product and the enterprise licence for Premium features as two different conversations with legal, not one badge on a slide.

How it works. Coder is a self-hosted control plane for cloud development environments and, in current upstream messaging, AI coding agents on your infrastructure. Official README and docs describe workspaces defined with Terraform. Starter paths cover Docker, Kubernetes, cloud VMs and related providers. A Coder agent in the workspace connects back through a secure tunnel (upstream docs describe a WireGuard-based path). Idle resources can shut down automatically when templates allow it. Production installs expect PostgreSQL 13 or later and an external access URL; without those flags, the coder server path is aimed at evaluation.

Developers open workspaces through the dashboard and documented access methods: SSH (coder ssh or coder config-ssh), Visual Studio Code (desktop extension and browser via code-server), JetBrains IDEs through Gateway, web terminal, and other web IDEs that templates can expose. Dev Containers are also documented as a way to build environments on Docker, Kubernetes and OpenShift when that is the template story you want.

At the time of writing, GitHub shows v2.39.0 as a mainline release (3 November 2026). The same day, v2.38.6 is marked Stable (“Stable since November 03, 2026”). Coder’s own release note for v2.39.0 advises enterprise customers without a staging environment to prefer the latest stable release while mainline is refined. Pin the channel you intend to run, and read the breaking-change notes before you upgrade.

Where it is strong.

• Organisations that want one control plane, Terraform-defined environments, and a shared template catalogue for many developers.
• Teams that need first-class SSH, VS Code and JetBrains access without inventing a bastion farm.
• Platform groups that already think in Terraform modules and want workspace infra reviewed like any other IaC change.

What to watch.

• AGPL on the core and a separate enterprise licence for Premium features. Confirm which binaries and features you actually deploy.
• Mainline versus stable: do not assume “latest GitHub tag” is the channel your production policy wants.
• You still operate PostgreSQL, networking, identity and template quality. A bad template scales pain as fast as a good one scales onboarding.
• AI-agent features in current docs add governance value only if you already trust your model routing and audit path.

DevPod: client-only Dev Containers on any backend

History and licence. The project lives at loft-sh/devpod. The repository was created in January 2023 under the loft-sh organisation (Loft Labs). It is licensed under the Mozilla Public License 2.0 (MPL-2.0). Upstream describes DevPod as open-source, client-only and built around the Dev Container standard.

How it works. DevPod is deliberately not a central server you install for the company. The desktop app or CLI runs on the developer machine. It reads a repository’s devcontainer.json (the same family of config used by VS Code Dev Containers and GitHub Codespaces), then asks a provider to create and connect the environment. Official docs list first-party providers maintained by the DevPod team, including Docker, Kubernetes, SSH, AWS, Google Cloud, Azure and DigitalOcean. Providers are either machine providers (they create and lifecycle a VM) or non-machine providers (they run the workspace container directly on Docker, Kubernetes or SSH targets). IDEs include VS Code and the JetBrains suite, with other editors reachable over SSH.

That client-only model is the point: there is no shared DevPod control plane to patch for every developer. The trade-off is also the point: governance, shared templates and central audit are weaker unless you build them around git, image registries and cloud accounts yourself.

Release reality (be honest). The latest non-prerelease tag on GitHub at the time of writing is v0.6.15 (10 March 2025). After that, activity moved into v0.7.0-alpha. prereleases, with v0.7.0-alpha.34* published 23 June 2025. The main repository’s latest push we checked was mid-November 2025. Provider repos such as Kubernetes and DigitalOcean still show later maintenance, but the core DevPod release train has been slow compared with Coder and Che in 2026. Plan for that: pin a known desktop/CLI build, test upgrades, and do not assume a weekly stable cadence.

Upstream marketing also claims large cost savings versus hosted CDE products. Treat those numbers as the vendor’s own comparison, not as an independent benchmark in this post. We did not run cost drills.

Where it is strong.

• Individuals and small teams that already use devcontainer.json and want the same file on a laptop Docker daemon, a spare SSH box, or a cloud VM.
• Groups that refuse to run another company-wide control plane just to get remote environments.
• Engineers who want VS Code or JetBrains against remote compute without learning Kubernetes operators first.

What to watch.

• No central server means no central policy box. SSO, quotas and audit become your cloud and git problem.
• Stable releases have been quiet while alphas continued; verify the exact binary your team installs.
• Some devcontainer.json properties are documented as unsupported in DevPod; read that list before you promise Codespaces parity.
• Shared credentials sync is convenient and also a security design decision. Decide what may leave the laptop.

Eclipse Che: Kubernetes-native CDEs with Devfile

History and licence. The project lives at eclipse-che/che. The repository dates to March 2015. It is licensed under the Eclipse Public License 2.0 (EPL-2.0). Eclipse Che describes itself as a Kubernetes-native platform for cloud development environments aimed at enterprise teams. Workspaces run as containers in Kubernetes or OpenShift pods, with tools, dependencies and IDE access defined together.

How it works. Che workspaces are defined with a Devfile (commonly devfile.yaml in the repo). The Che website notes that Devfile is a CNCF project with contributions from Red Hat, AWS and JetBrains. A factory-style URL can open a Git repository as a workspace on your Che host. Default browser editing uses Microsoft Visual Studio Code - Open Source; JetBrains IntelliJ IDEA can connect through JetBrains Gateway. Platform install is Kubernetes-native (Operator-oriented in current upstream documentation). The chectl CLI manages Che and, as of the 7.124.0 release notes (21 October 2026), includes a built-in workspace command group for creating, listing, starting, stopping, deleting and SSH-connecting DevWorkspaces, so a separate connector tool is no longer required for those flows.

The latest stable Che tag we checked for this post is 7.124.0 (21 October 2026), following a regular 7.x monthly-style cadence through 2026.

OpenShift Dev Spaces (not a fourth peer). Red Hat’s developer product page states that Red Hat OpenShift Dev Spaces provides cloud development environments for enterprise teams and is built on the open-source Eclipse Che project. It ships as part of the OpenShift subscription story and OperatorHub install path. For this comparison, treat Dev Spaces as the supported, productised Che on OpenShift: same Devfile idea, Red Hat packaging and support boundary. If you are already standardised on OpenShift, evaluate Dev Spaces with your Red Hat account team. If you are on vanilla Kubernetes, evaluate upstream Che directly.

Where it is strong.

• Platform teams that already run Kubernetes or OpenShift and want workspaces as ordinary cluster workloads with RBAC and OIDC.
• Organisations that want source and build tools to stay on the cluster rather than on every laptop.
• Teams standardising on Devfile and browser-first onboarding with a link.

What to watch.

• You need a real cluster, storage classes, ingress/TLS and identity integration. Che is not a single-binary laptop toy.
• Devfile and Che operator upgrades are cluster change management, not a desktop app update.
• Editor and extension policy (Open VSX, allowed JetBrains paths) needs an owner, or every workspace drifts.
• OpenShift Dev Spaces vs upstream Che is a support and packaging choice; do not mix docs blindly.

Side by side, without a table

Primary approach

• Coder: self-hosted control plane; workspaces from Terraform templates (Dev Containers also documented).
• DevPod: client-only CLI/desktop; workspaces from devcontainer.json via providers.
• Eclipse Che: Kubernetes/OpenShift-native CDEs from Devfile; OpenShift Dev Spaces is Red Hat’s productised Che.

Licence (as stated upstream)

• Coder: AGPL-3.0 for the open-source core; separate enterprise licence terms for the enterprise/ Premium software.
• DevPod: MPL-2.0.
• Eclipse Che: EPL-2.0.

Latest releases checked for this post (November 2026)

• Coder: mainline v2.39.0 and stable v2.38.6 (both 3 November 2026). Prefer stable for production without staging, per Coder’s own note.
• DevPod: latest stable tag v0.6.15 (10 March 2025); newest prerelease seen v0.7.0-alpha.34 (23 June 2025). Cadence has been slow; verify before you standardise.
• Eclipse Che: 7.124.0 (21 October 2026).

Environment definition

• Coder: Terraform first; Dev Containers supported in docs for some flows.
• DevPod: Dev Container (devcontainer.json) first.
• Eclipse Che: Devfile first.

Where compute runs

• Coder: whatever your templates provision (Docker, Kubernetes, cloud VMs and more).
• DevPod: local Docker, remote SSH host, Kubernetes, or cloud VMs through providers.
• Eclipse Che: Kubernetes or OpenShift pods.

Editor access

• Coder: SSH, VS Code, JetBrains Gateway, code-server/web IDEs, web terminal.
• DevPod: VS Code, JetBrains, SSH for others.
• Eclipse Che: browser VS Code Open Source by default; JetBrains via Gateway; chectl SSH connect for documented desktop/SSH editor flows.

Central governance

• Coder: strong control-plane story (users, templates, access URL, optional Premium features).
• DevPod: weak by design (client-only); governance lives in git, images and cloud accounts.
• Eclipse Che: strong cluster-native story (Operator, OIDC, Kubernetes RBAC).

We did not run install drills or load tests for this post. Prefer the official install guides on disposable infrastructure before you move a whole engineering org.

A practical way to start this week

For an Indian engineering team that is about to renew cloud IDE seats or drown in laptop setup tickets, a calm sequence looks like this:

1. Write down the real pain: slow onboarding, “works on my machine”, data residency, GPU needs, or AI agents that should not hold production API keys on laptops.
2. Pick one disposable environment: a spare VM for Coder or DevPod Docker/SSH tests, or a non-production Kubernetes namespace for Che.
3. If you want org templates and a dashboard, install Coder with the official install path, create the first admin, use a starter Docker or Kubernetes template, and open the same workspace from VS Code and SSH.
4. If you want zero central server and already have devcontainer.json, install DevPod desktop or CLI, add the Docker provider, open one internal repo, then try the same repo on an SSH provider only after local Docker works.
5. If Kubernetes is already your platform, install Eclipse Che with the current upstream admin docs (or evaluate OpenShift Dev Spaces if you are on OpenShift with Red Hat support), add a minimal Devfile to a sample repo, and open it from a factory URL.
6. Agree identity and secrets rules before the pilot grows: who may create templates, which registries are trusted, and whether source may leave the cluster or VPC.
7. Only then move one real internal service team. Keep the old laptop path until the new path survives a recreate, an editor reconnect and an idle shutdown test.

How to choose

• If you need a company control plane, Terraform-defined environments and broad IDE access, start with Coder, and decide AGPL vs Premium with legal early.
• If you want Dev Containers without running a CDE server, and you can accept slower upstream release cadence, start with DevPod.
• If workspaces should be ordinary Kubernetes workloads with Devfile and browser-first onboarding, start with Eclipse Che.
• If you are already on OpenShift and want a supported product, evaluate OpenShift Dev Spaces as productised Che, not as a separate architecture.
• Do not run Coder, Che and a managed cloud IDE “for a month” on the same production cluster without clear owners. Compare on throwaway projects.

Revisit checklist

• Are we buying cloud IDE seats because we measured the need, or because laptop setup tickets felt endless last quarter?
• Is the workspace defined as code (Terraform, Dev Container or Devfile), or only as a wiki page of setup steps?
• Do we know where source code and credentials live when the editor is remote?
• Who owns upgrades: Coder mainline vs stable, DevPod desktop pins, or Che/Dev Spaces operators?
• Can a new teammate open a workspace without receiving a shared SSH key in chat?
• Have we tested recreate, idle shutdown and editor reconnect, not only the happy-path first boot?
• For AI coding agents: do model credentials and audit logs live in the control plane, or on every laptop?

Closing

Treating every laptop as the system of record is a habit worth unlearning. Buying another hosted IDE seat without asking what you must operate is the same habit in a nicer UI. Revisit Coder, DevPod or Eclipse Che with the mindset that fits this site: learn the workspace model, unlearn the assumption that remote development must be a rented product, re-learn the licence and upgrade boundaries, practise on disposable infra, and apply the chosen tool only where it reduces real toil.

Sources

• Coder repository, licence and README: https://github.com/coder/coder
• Coder releases (v2.39.0 mainline, v2.38.6 stable): https://github.com/coder/coder/releases
• Coder workspace access docs: https://coder.com/docs/user-guides/workspace-access
• Coder templates docs: https://coder.com/docs/admin/templates
• Coder enterprise licence file: https://github.com/coder/coder/blob/main/LICENSE.enterprise
• DevPod repository and README: https://github.com/loft-sh/devpod
• DevPod releases: https://github.com/loft-sh/devpod/releases
• DevPod “What is DevPod” docs: https://devpod.sh/docs/what-is-devpod
• DevPod providers docs: https://devpod.sh/docs/managing-providers/what-are-providers and https://devpod.sh/docs/managing-providers/add-provider
• Eclipse Che repository: https://github.com/eclipse-che/che
• Eclipse Che releases (7.124.0): https://github.com/eclipse-che/che/releases
• Eclipse Che “What is Che” docs: https://www.eclipse.org/che/docs/stable/discover/what-is-che/
• Eclipse Che project site: https://eclipse.dev/che/
• Red Hat OpenShift Dev Spaces overview (built on Eclipse Che): https://developers.redhat.com/products/openshift-dev-spaces/overview
• Devfile project site: https://devfile.io/
• chectl releases: https://github.com/che-incubator/chectl/releases