GitHub Codespaces rechnet nach Nutzung ab: Rechenzeit pro Stunde, Speicher nach belegtem Platz; persönliche Konten haben ein monatliches Kontingent (laut GitHub Docs, Stand: 08.11.2026).
Ein VPS mit code-server rechnet dagegen nach Laufzeit des Servers ab, nicht nach Nutzung der IDE; aktuelle Preise unter /use-case/cloud-ide. Du hast Root-Zugriff, und dein Code liegt auf deinem Server. Extensions kommen bei code-server aus der Open-VSX-Galerie, nicht aus dem Microsoft-Marketplace (laut code-server-FAQ, Stand: 08.11.2026).
Dieser Guide stellt vier Self-Hosted Cloud IDEs vor, zeigt die Installation und nennt, wann sich eigenes Hosting anbietet.
Warum eine eigene Cloud IDE?
Die Abrechnung
Codespaces ist bequem, rechnet aber nach Nutzung ab (siehe oben). Was ein VPS für dein Team kostet, zeigt der Rechner unter /use-case/cloud-ide mit Preis-Stand.
Datenstandort und Datenschutz
Bei Codespaces wird die Region standardmäßig nach deinem Standort gesetzt und ist manuell wählbar (laut GitHub Docs, Stand: 08.11.2026).
Mit einer selbst gehosteten Cloud IDE auf einem VPS (Hetzner, IONOS, Netcup) gilt: Daten auf deinem Server, Standort wählbar; wer Daten anderer verarbeitet, bleibt für die DSGVO-Einhaltung verantwortlich, in der Regel mit AV-Vertrag mit dem Hoster.
Kein Vendor Lock-in
Du bist nicht an einen Anbieter gebunden. Ein Umzug zu einem anderen VPS-Anbieter heißt: Compose-Dateien kopieren, Daten migrieren, DNS umstellen.
Vier Self-Hosted Cloud IDEs im Überblick
code-server und OpenVSCode Server bringen VS Code in den Browser; Coder und DevPod stellen Entwicklungsumgebungen bereit, mit denen sich verschiedene Editoren verbinden. Angaben laut den Projektseiten, Stand: 08.11.2026 (Quellen in den Abschnitten darunter).
| Tool | Typ | Multi-User | Mindestanforderung laut Projekt | Besonderheit |
|---|---|---|---|---|
| code-server | VS Code im Browser | Nein (ein Passwort) | 1 GB RAM, 2 CPU-Kerne | ein Container, Passwort-Login |
| Coder | Workspace-Plattform | Ja (Templates + SSO) | 2 CPU-Kerne, 4 GB (Docker-Installation) | Templates, SSO, Admin-Dashboard |
| OpenVSCode Server | VS Code im Browser | Nein | keine Angabe des Projekts | ohne Docker startbar, Projekt von Gitpod |
| DevPod | Client-Tool | nicht zutreffend (Client-Tool) | je Workspace nach Projekt | devcontainer.json, kein Server-Daemon |
code-server
code-server von Coder läuft z. B. als Docker-Container mit Passwort-Login, VS Code im Browser; als Mindestanforderung nennt das Projekt 1 GB RAM und 2 CPU-Kerne (laut code-server-Doku, Stand: 08.11.2026). Geeignet für Einzelpersonen, die von verschiedenen Geräten auf ihre Projekte zugreifen.
code-server kennt ein einzelnes Passwort; für mehrere Personen empfiehlt das Projekt je Person eine eigene VM (laut code-server-FAQ, Stand: 08.11.2026).
Coder
Coder ist eine Plattform für Team-Workspaces: Jeder Entwickler bekommt seinen Workspace aus einem Terraform-Template. Coder unterstützt Passwort-Login, GitHub OAuth und OpenID Connect, etwa mit Okta (laut Coder-Doku, Stand: 08.11.2026), und hat eine REST-API (laut Coder-Doku, Stand: 08.11.2026). Einige Funktionen gibt es nur mit kostenpflichtiger Lizenz (laut Coder-Doku, Stand: 08.11.2026).
Für den produktiven Betrieb empfiehlt Coder ein externes PostgreSQL ab Version 13; die eingebaute Datenbank ist für Proof-of-Concept gedacht. Die Docker-Installation nennt 2 CPU-Kerne und 4 GB Speicher (laut Coder-Doku, Stand: 08.11.2026).
OpenVSCode Server
OpenVSCode Server von Gitpod startest du aus dem Release-Archiv mit ./bin/openvscode-server, ohne Docker. Die Web-UI startet seit v1.64 ohne Authentifizierung; absichern lässt sie sich mit --connection-token, das Docker-Image läuft mit --without-connection-token (laut README, Stand: 08.11.2026). Davor gehört ein Reverse Proxy mit Authentifizierung oder ein VPN wie Tailscale.
Passt, wenn du den Zugriff über Netzwerk oder VPN absicherst.
DevPod
DevPod, ein Open-Source-Projekt unter github.com/loft-sh, ist ein reines Client-Tool: Es nutzt devcontainer.json-Dateien und startet Workspaces lokal, auf Kubernetes, auf Remote-Maschinen oder Cloud-VMs; neben VS Code unterstützt es JetBrains, andere Editoren per SSH (laut README, Stand: 08.11.2026).
Vorteil: Kein laufender Server-Daemon. Der Ressourcenbedarf hängt vom Dev-Container ab.
Welcher VPS reicht? Hardware-Anforderungen
Die IDE selbst ist schlank – die Last entsteht durch Language Server (TypeScript, Python, Go), Linter, Compiler und Docker-Container. Orientierung von RackDiff, keine Herstellerangabe:
| Szenario | RAM | CPU | Storage |
|---|---|---|---|
| Solo-Dev (code-server) | 4 GB | 2 vCPU | 40 GB NVMe |
| 2–3 Devs (Coder) | 8 GB | 2–4 vCPU | 80 GB NVMe |
| Kleines Team 5+ (Coder) | 16 GB | 4–8 vCPU | 160 GB NVMe |
| DevPod (pro Workspace) | nach Dev-Container | nach Dev-Container | nach Projekt |
Passende Angebote mit Preis-Stand: Cloud-IDE-Rechner und VPS-Vergleich.
Hinweis: Language Server lesen viele kleine Dateien; NVMe-Speicher kann dabei Vorteile bringen.
Wie viel RAM und CPU du brauchst, schätzt der interaktive Cloud-IDE-Rechner nach Teamgröße und Tool.
Installation: code-server mit Docker Compose
Das einfachste Setup: code-server hinter Caddy als Reverse Proxy mit automatischem HTTPS.
Voraussetzungen
- VPS mit Ubuntu 22.04/24.04 und Docker installiert
- Domain oder Subdomain (z.B. code.example.com) mit DNS auf die VPS-IP
Docker Compose
Erstelle auf dem VPS die Datei /opt/code-server/docker-compose.yml:
services:
code-server:
image: codercom/code-server:<version>
container_name: code-server
restart: unless-stopped
environment:
- HASHED_PASSWORD=<dein-argon2-hash, jedes $ als $$>
volumes:
- code-data:/home/coder
networks:
- web
caddy:
image: caddy:2-alpine
container_name: caddy
restart: unless-stopped
ports:
- "80:80"
- "443:443"
volumes:
- ./Caddyfile:/etc/caddy/Caddyfile
- caddy-data:/data
networks:
- web
volumes:
code-data:
caddy-data:
networks:
web:
code-server liest PASSWORD oder HASHED_PASSWORD (laut code-server-Quellcode, Stand: 08.11.2026). Trägst du den Hash direkt in die Compose-Datei ein, wird jedes $ zu $$ (laut code-server-FAQ, Stand: 08.11.2026). Der code-server-Port wird nicht veröffentlicht, nur Caddy ist von außen erreichbar; <version> ersetzt du durch eine feste Version.
Erstelle die Datei Caddyfile im selben Verzeichnis:
code.example.com {
reverse_proxy code-server:8080
}
Starten:
cd /opt/code-server
docker compose up -d
Danach ist VS Code unter https://code.example.com erreichbar. Caddy holt automatisch ein Zertifikat (Let's Encrypt, ersatzweise ZeroSSL), sofern der DNS-Eintrag auf den Server zeigt und die Ports 80 und 443 erreichbar sind (laut Caddy-Doku, Stand: 08.11.2026).
Achtung beim Docker-Socket: Wer den Docker-Daemon steuert, hat faktisch Root-Rechte auf dem Host (laut Docker-Doku, Stand: 08.11.2026). Den Socket in code-server zu mounten passt nur für Single-User-Setups, die du allein nutzt; die Docker-CLI ist im Image nicht enthalten (laut code-server-FAQ, Stand: 08.11.2026).
Installation: Coder für Teams
Für den produktiven Betrieb empfiehlt Coder ein externes PostgreSQL. Als Vorlage dient die offizielle Compose-Datei des Projekts (coder/coder compose.yaml, Stand: 08.11.2026). Drei Punkte passt du an:
- HTTP-Adresse: Die Datei setzt
CODER_HTTP_ADDRESS=0.0.0.0:7080; ohne diese Angabe lauscht Coder nur auf127.0.0.1:3000(laut Coder-Doku, Stand: 08.11.2026). - Kein öffentlicher Port: Veröffentliche den Port nur an
127.0.0.1("127.0.0.1:7080:7080") oder gar nicht und hänge Caddy ins selbe Netz. Von Docker veröffentlichte Ports umgehen ufw (laut Docker-Doku, Stand: 08.11.2026). - Docker-Gruppe und Passwort: Für den Docker-Socket ergänzt du
group_addmit der GID der docker-Gruppe (laut Coder-Doku, Stand: 08.11.2026), und für die Datenbank setzt du ein eigenes langes Passwort.
CODER_ACCESS_URL muss auf die öffentliche URL zeigen, die Nutzer und Workspaces von außen erreichen (laut Coder-Doku, Stand: 08.11.2026).
Richte erst den Reverse Proxy mit HTTPS ein und lege dann unter https://coder.example.com sofort das Admin-Konto an; das beim Setup angelegte Konto ist das Owner-Konto (laut Coder-Doku, Stand: 08.11.2026).
Workspace-Templates
Coder nutzt Terraform-Templates, um Workspaces zu definieren. Ein Template lädst du mit templates push hoch (laut Coder-CLI-Referenz, Stand: 08.11.2026):
coder templates push docker \
--directory ./templates/docker
Für Git nutzt Coder External-Auth-Tokens bzw. ein automatisch erzeugtes SSH-Schlüsselpaar je Nutzer (laut Coder-Doku, Stand: 08.11.2026).
Abrechnung: Self-Hosted vs. Codespaces
Codespaces rechnet nach Nutzung ab (siehe oben); ein VPS rechnet nach Laufzeit des Servers ab. Angebote mit Preis-Stand findest du unter /use-case/cloud-ide. Dafür übernimmst du Einrichtung, Updates und Absicherung selbst.
Sicherheit: HTTPS, Auth und Netzwerk
Eine Cloud IDE im Internet ohne Absicherung ist eine offene Einladung. Die code-server-Doku warnt, die IDE nie ohne Authentifizierung und Verschlüsselung direkt ins Internet zu stellen (laut code-server-Doku, Stand: 08.11.2026). Mindestanforderungen:
- HTTPS: erforderlich. Caddy holt das Zertifikat automatisch (siehe oben).
- Authentifizierung: code-server hat einen Passwort-Login mit Rate-Limit (laut code-server-Doku, Stand: 08.11.2026). Für Coder: GitHub OAuth oder OIDC einrichten.
- Firewall: Interne Dienste nicht mit
ports:veröffentlichen oder nur an127.0.0.1binden; Docker-Ports umgehen ufw (laut Docker-Doku, Stand: 08.11.2026). - SSH-Alternative: Statt Browser-Zugriff kannst du auch VS Code Remote-SSH nutzen und den VPS als reinen Backend-Server verwenden. Dann brauchst du keinen Reverse Proxy.
- Zero Trust: Tailscale oder WireGuard als VPN-Layer vor die IDE – dann ist die IDE selbst nicht öffentlich erreichbar.
Tipps aus der Praxis
Language Server brauchen RAM: Language Server können bei großen Projekten viel RAM belegen; prüfe den Verbrauch im Betrieb (z. B. mit htop) und plane Reserven ein.
Git Credentials: git credential-store speichert Passwörter unverschlüsselt auf der Platte (laut Git-Doku, Stand: 08.11.2026). Nutze einen SSH-Agent oder git credential-cache. Bei Coder gelten External Auth bzw. der SSH-Schlüssel je Nutzer.
Dotfiles automatisieren: Bei Coder geht das mit coder dotfiles <repo> oder einem Dotfiles-Modul im Template (laut Coder-Doku, Stand: 08.11.2026).
Monitoring: Installiere htop oder btop auf dem VPS, um RAM- und CPU-Auslastung zu überwachen.
Fazit
code-server passt für Einzelpersonen, Coder für Teams. Beide laufen auf einem eigenen VPS, der nach Laufzeit abgerechnet wird, nicht nach IDE-Nutzung.
Ob sich das rechnet, hängt von Nutzungsdauer und Teamgröße ab; vergleiche die Abrechnung deines bisherigen Dienstes mit den VPS-Preisen unter /use-case/cloud-ide. Dazu kommen Kontrolle über Datenstandort und Konfiguration.
Cloud IDE Server-Kalkulator
Wie viel RAM und CPU brauchst du? Gib Teamgröße und Tool ein – unser Rechner zeigt dir passende VPS-Angebote mit Preis-Stand.
Zum Cloud IDE Kalkulator

