---
title: 'VS Code Server'
url: 'https://niklas-stephan.de/de/wiki/free-open-source-software/vs-code-server'
markdown: 'https://niklas-stephan.de/de/wiki/free-open-source-software/vs-code-server.md'
lang: de
date: '2026-11-14'
description: 'VS Code Server Microsofts Visual Studio Code hat sich über die letzten Jahre als Quasi-Standard etabliert – nicht nur für das Editieren von Quellcode in allen möglichen (Programmier-)Sprachen, sondern auch für eine Vielzahl weiterer Operationen. Einer der Kritikpunkte bleibt die durch den Editor v…'
---

# VS Code Server

Microsofts [Visual Studio Code](https://code.visualstudio.com/) hat sich über die letzten Jahre als Quasi-Standard etabliert – nicht nur für das Editieren von Quellcode in allen möglichen (Programmier-)Sprachen, sondern auch für eine Vielzahl weiterer Operationen.

![](https://niklas-stephan.de/images/6/7/c/5/7/67c573d5016771cb77a1f0dbc7dd5c06a6c42ec2-01-vscode.png)

Einer der Kritikpunkte bleibt die durch den Editor verursachte relativ hohe Systemlast, die zwar begründet ist, aber für einen „Texteditor“ doch etwas merkwürdig erscheint. Ein anderer Kritikpunkt ist, dass für das beliebte „Remote SSH“-Plugin, welches es ermöglicht, auf einen beliebigen über SSH erreichbaren Server mit VS Code zu arbeiten, ziemlich viele dynamische Ports geöffnet werden und auch generell einige Firewalls hier Probleme machen können.

Nun basiert VS Code selbst auf dem [Electron-Framework](https://en.wikipedia.org/wiki/Visual_Studio_Code), welches wiederum auf JavaScript aufbaut. Warum also nicht die VS-Code-Installation auf einem Server hosten und per Webinterface zur Verfügung stellen? Das haben sich offensichtlich viele gefragt, und deshalb ist dies mit Hilfe von Docker und Caddy schnell bewerkstelligt.

## Installation

Zur Installation verlassen wir uns wieder auf Docker Compose für die Verwaltung unserer Container und Caddy als Reverse Proxy. Ein passendes und regelmäßig aktualisiertes VS-Code-Image finden wir von [Linuxserver.io](http://Linuxserver.io) auf [Docker Hub](https://hub.docker.com/r/linuxserver/code-server).

Unsere „compose.yml“-Datei kann dann so aussehen:

```yaml
---
version: "2.1"
services:
  code-server:
    image: lscr.io/linuxserver/code-server:latest
    container_name: code-server
    environment:
      - PUID=1001
      - PGID=1001
      - TZ=Etc/UTC
      - PASSWORD=PASSWORT
      #- HASHED_PASSWORD=#optional
      #- SUDO_PASSWORD=#optional
      #- SUDO_PASSWORD_HASH=#optional
      #- PROXY_DOMAIN=#optional
      - DEFAULT_WORKSPACE=ORDNERCONTAINER #optional
    volumes:
      - ./config:/config
      - /ORDNERHOST:/ORDNERCONTAINER
    restart: unless-stopped
    logging:
      options:
        max-size: "10m"
        max-file: "3"
    networks:
        - caddy

volumes:
    data:
    db:
networks:
    caddy:
        external: true
```

Die wichtigsten Parameter hier kurz erläutert:

- environment – PUID: Die Prozess-ID, die möglichst der ID eures Benutzers entsprechen sollte, damit ihr später Berechtigungsproblemen beim Editieren von Dateien aus dem Weg gehen könnt. Eure eigene ID bekommt ihr einfach über die Linux-Kommandozeile mit dem Befehl „id“ heraus.
- environment – PGID: Das Gleiche wie für die PUID, nur dass hier die Gruppen-ID gemeint ist.
- environment – PASSWORD: Das Passwort, das abgefragt wird, wenn man die URL des Containers aufruft. Da nicht einmal ein User gesetzt wird, ist das nicht besonders sicher, und es sollte eine zusätzliche Sicherheitsstufe, z. B. über den Reverse Proxy, geschaffen werden. Siehe Kapitel „Härtung“.
- environment – SUDO\_PASSWORD: Hier lässt sich das sudo-Passwort für den Container setzen. Nach Möglichkeit sollte dies vermieden werden, da man in einem Container nach Security-Best-Practices nie als root arbeiten sollte.
- environment – HASHED\_PASSWORD und SUDO\_PASSWORD\_HASH: Beide Parameter sollen dabei helfen, dass keine Passwörter im Klartext in der „docker-compose.yml“ abgelegt werden müssen. Wie man solch einen Hash-Wert generiert, ist auf der Projektseite erläutert, hat aber zumindest für mich so nicht funktioniert. Auch deshalb ist eine zusätzliche „Härtung“ wie nachfolgend beschrieben erforderlich.
- environment – DEFAULT\_WORKSPACE: Hier geben wir den Pfad auf dem Container an, der nachfolgend unter Volumes spezifiziert ist. Diesen sehen wir dann als Workspace/Ordner in VS Code.
- volumes – /ORDNERHOST:/ORDNERCONTAINER: Wenn gewünscht, können wir hier einen Pfad auf unserem Host(Server) spezifizieren, der in VS Code auftaucht. Die Variable ORDNERCONTAINER ersetzen wir wiederum durch den Wert, den wir als „DEFAULT\_WORKSPACE“ angegeben haben.

Nun können wir den Container mit „docker compose up -d“ starten.

## Härtung und Reverse-Proxy-Konfiguration

In unserem Caddyfile unseres Reverse Proxy ergänzen wir einen Block für die neue VS-Code-Instanz. Das kann so aussehen:

```caddyfile
code.handtrixxx.com {
    basicauth {
        USER HASHWERT
    }
    reverse_proxy code-server:8443
}
```

Man beachte die Werte in den geschweiften Klammern hinter „basicauth“. Diese bringen zusätzlichen Schutz vor möglichen Angreifern, indem sie eine weitere Anmeldung bereitstellen, sobald jemand die URL öffnet. Als USER könnt ihr einen Namen eurer Wahl festlegen; für die Generierung des Hashwerts wechselt man auf der Kommandozeile in den Docker-Compose-Ordner von Caddy und führt dort folgendes Kommando aus: `docker compose exec -w /etc/caddy caddy caddy hash-password`

Den aus der Abfrage resultierenden Wert kopiert ihr einfach als HASHWERT in das Caddyfile.

Nachdem wir die Konfiguration von Caddy neu geladen haben, ist VS Code unter der angegebenen URL erreichbar und die zusätzliche Sicherheitsschicht ist aktiviert.

---

## Navigation

- Parent: [Freie Open-Source-Software](https://niklas-stephan.de/de/wiki/free-open-source-software.md)
- Previous: [🔒 Virtual Private Networking](https://niklas-stephan.de/de/wiki/free-open-source-software/virtual-private-networking.md)
- Next: [🖥️ Webtop](https://niklas-stephan.de/de/wiki/free-open-source-software/webtop.md)