// Tutorial · Docker · Desktop-Umgebung

Webtop: Vollständiger Linux-Desktop im Browser (XFCE)

📅 09.09.2026 ⏱ 10 Min. Lesezeit ✍️ Redaktion

Ein kompletter Linux-Desktop, der nur im Browser lebt? Webtop vom linuxserver-Team macht genau das möglich: Ein Container mit XFCE, Firefox & Co., den du von jedem Gerät aus per KasmVNC im Browser bedienst. Ideal als „immer dabei“-Arbeitsplatz, für Remote-Sessions oder um Container-Tools mit grafischer Oberfläche zu nutzen. In diesem Artikel setzt du Webtop mit Docker Compose auf – in der schlanken XFCE-Variante.

Was ist Webtop?

Webtop (github.com/linuxserver/docker-webtop) ist ein Docker-Image, das eine vollwertige Linux-Desktop-Umgebung in einen Container packt. Über KasmVNC streamst du den Desktop verschlüsselt in den Browser – ohne Remote-Desktop-Client, ohne VPN-Zwang, mit lauffähigen Standard-Apps (Firefox, Dateimanager, Terminal …).

Das linuxserver-Team liefert mehrere Geschmacksrichtungen – allein für Debian gibt es XFCE, MATE, KDE, i3 und OpenBox:

  • XFCE – leichtgewichtig, schnell, ideal für den Start (unser Beispiel)
  • MATE / KDE – mehr Komfort und Optik, dafür ressourcenhungriger
  • i3 / OpenBox – puristische Fenstermanager für Profis

Dazu kommen Basis-Varianten wie alpine, ubuntu oder arch sowie Architekturen wie amd64, arm64 – im Tag amd64-debian-xfce stecken also Architektur, Distro und Desktop.

Das Besondere: Du kannst dem Desktop Ordner, USB-artige Geräte oder sogar den Docker-Socket in den Container reichen – Webtop wird so zur „Schaltzentrale“ im Browser. Genau dort liegt aber auch die größte Gefahr (siehe Abschnitt „Sicherheits-Check“).

Voraussetzungen

  • Einen Debian-13-Server aus Teil 1 mit Docker & Compose (Teil 5)
  • Empfohlen: mind. 2 CPU-Kerne und 4 GB RAM – ein Desktop mit Browser ist kein 100-MB-Spielzeug
  • Optional: eine Domain + Reverse Proxy (Nginx), wenn der Desktop nicht nur im lokalen Netz laufen soll

Installation mit Docker Compose (XFCE)

Verzeichnis anlegen und in den Stack wechseln:

mkdir -p /opt/stacks/webtop
cd /opt/stacks/webtop

Die docker-compose.yml – hier die XFCE-Variante (amd64-debian-xfce) mit allen Optionen im Überblick:

services:
  webtop:
    image: lscr.io/linuxserver/webtop:amd64-debian-xfce
    container_name: webtop
    deploy:
      resources:
        limits:
          cpus: "4.0"
          memory: 8G
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Berlin
      - SUBFOLDER=/ #optional
      - KEYBOARD=de-de-qwertz #optional
      - TITLE=Webtop #optional
      - PASSWORD=Meinl4ng3spassw0rd26#
    volumes:
      - ./config:/config
      - /var/run/docker.sock:/var/run/docker.sock #optional
    ports:
      - 127.0.0.1:50537:3001
    shm_size: 32gb #optional
    restart: unless-stopped
    labels:
      - com.centurylinklabs.watchtower.enable = "false"

Starten und den Container-Status prüfen:

docker compose up -d
docker compose ps

Danach öffnest du im Browser https://127.0.0.1:50537 (auf dem Server selbst) – beim ersten Aufruf erscheint eine Zertifikats-Warnung, weil KasmVNC mit einem selbstsignierten Zertifikat arbeitet. Die bestätigst du und loggst dich mit dem Benutzer abc und dem Passwort aus PASSWORD ein.

Erster Eindruck: XFCE startet mit wenigen hundert MB RAM. Der Firefox liegt schon im Menü – Webtop ist ab Werk fürs „Loslegen“ gebaut. Alle Einstellungen und Dateien landen in ./config und überleben damit jeden Container-Neustart.

Reverse Proxy: Webtop nach außen bringen

Der Container lauscht nur auf 127.0.0.1:50537 – damit der Desktop auch von unterwegs erreichbar ist, stellt der Nginx-Proxy aus der Serie die Verbindung her. Wichtig: KasmVNC nutzt WebSockets, daher braucht der Proxyblock die passenden Upgrade-Header und das Upstream-Zertifikat wird nicht verifiziert (selbstsigniert):

server {
    listen 443 ssl http2;
    server_name desk.deine-domain.de;

    ssl_certificate     /etc/letsencrypt/live/desk.deine-domain.de/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/desk.deine-domain.de/privkey.pem;

    location / {
        proxy_pass https://127.0.0.1:50537;
        proxy_ssl_verify off;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 3600s;
    }
}
sudo nginx -t
sudo systemctl reload nginx
Zugangsschutz nicht vergessen: Ein Browser-Desktop ist ein mächtiges Werkzeug – schütze ihn zusätzlich mit Basic Auth (htpasswd) auf Proxy-Ebene oder einer VPN-Lösung, wenn du ihn nicht öffentlich freigeben willst.

Konfiguration & Umgebungsvariablen

VariableBedeutung
PUID/PGIDUser/Group-ID (1000 = Standard-Benutzer aus Teil 1) – die ./config-Dateien gehören damit dir.
TZZeitzone für Desktop & Apps (Europe/Berlin).
KEYBOARDTastaturlayout der KasmVNC-Session – hier de-de-qwertz.
TITLEAnzeigename im Browser-Tab (optional).
PASSWORDLogin-Passwort für den Webtop-Benutzer abc – großzügig lang wählen!
SUBFOLDERSubpfad, falls Webtop nicht an der Domain-Wurzel hängen soll.
shm_sizeGröße von /dev/shm im Container – Browser (Chromium/Firefox) brauchen hier Platz. 32 GB ist sehr großzügig; 1–2 GB reichen meist, der Wert frisst sonst RAM.

Watchtower-Label

Das Label com.centurylinklabs.watchtower.enable = "false" hält Watchtower von automatischen Updates fern – bei einem Desktop mit laufenden Sessions ist ein unkontrollierter Neustart unerwünscht. Updates machst du bewusst manuell (siehe unten). Achte auf die Schreibweise: Der Wert ist ein String und gehört in Anführungszeichen.

Eigene Apps nachrüsten

Du kannst im laufenden Desktop Software installieren – die Änderungen bleiben aber nur erhalten, wenn du sie in der ./config-Struktur ablegst oder ein eigenes Image vom Webtop-Image ableitest (siehe Dockerfile im Repo). Für „alles nur mal testen“ reicht die Session-Installation im Container.

Sicherheits-Check & Docker-Socket

⚠️ Der Docker-Socket ist Root-Zugriff: Der Mount /var/run/docker.sock:/var/run/docker.sock gibt dem Desktop die volle Kontrolle über deinen Docker-Host – wer im Webtop sitzt (oder ein Exploit in einer Browser-Session), kann damit alle Container, Volumes und den Host selbst kompromittieren. Frage dich ehrlich: Brauchst du Docker wirklich im Desktop? Wenn nicht: Mount weglassen. Wenn ja: Webtop niemals öffentlich erreichbar machen und mit Basic Auth + starkem Passwort schützen.
  • Passwort: PASSWORD ist der einzige Login-Schutz des Desktops – nimm eine lange Passphrase (wie im Beispiel) und ändere sie regelmäßig.
  • Port-Bindung: 127.0.0.1:50537 statt 0.0.0.0 – UFW/nftables bleiben so wirksam (Teil 3 der Serie).
  • Ressourcen-Limits: cpus: 4.0 und memory: 8G verhindern, dass der Desktop den Host lahmlegt.
  • Keine automatischen Updates des Desktop-Containers (Watchtower-Label) – du entscheidest, wann ein Neustart stattfindet.

Betrieb, Updates & Backups

Updates

Da Watchtower für diesen Container deaktiviert ist, aktualisierst du manuell – am besten außerhalb der Arbeitszeit:

cd /opt/stacks/webtop
docker compose pull
docker compose up -d

Backup

Alles Wichtige (Desktop-Einstellungen, Browser-Profil, Dateien im Home) liegt in ./config. Das Backup übernimmt das bewährte Muster aus Teil 4/5 – mit stop statt down und garantiertem Neustart:

#!/bin/sh
cd /opt/stacks/webtop || exit 1
docker compose stop
trap 'docker compose start' EXIT
borg create /mnt/backup/borg-repo::webtop-$(date +%Y-%m-%d) /opt/stacks/webtop/config
borg prune --keep-daily 7 --keep-weekly 4 --keep-monthly 6

Ein Restore ist damit simpel: Stack stoppen, ./config aus dem Borg-Archiv zurückspielen, Stack starten.

Häufige Probleme (FAQ)

ProblemLösung
Login funktioniert nichtBenutzername ist abc, das Passwort kommt aus der Variable PASSWORD. Nach einer Änderung den Container neu erstellen: docker compose up -d --force-recreate.
Passwort vergessenPASSWORD in der Compose-Datei ändern und den Container neu erstellen.
Schwarzer Bildschirm / Desktop startet nichtRAM-Limit prüfen (docker stats) und shm_size erhöhen – Browser ohne Shared Memory crashen gerne. Danach docker compose restart.
Deutsches Tastaturlayout fehltKEYBOARD=de-de-qwertz setzen und Session neu laden – bei laufender Session hilft die Layout-Umschaltung in der KasmVNC-Leiste.
Zertifikats-Warnung im BrowserNormal: KasmVNC nutzt ein selbstsigniertes Zertifikat. Hinter dem Reverse Proxy mit Let's-Encrypt verschwindet die Warnung.
Verbindung bricht ab / ruckeltLatenz prüfen, Qualität in der KasmVNC-Leiste reduzieren und proxy_read_timeout erhöhen (im Nginx-Block oben: 3600s).
Watchtower aktualisiert trotzdemLabel-Schreibweise prüfen: com.centurylinklabs.watchtower.enable = "false" – der Wert muss als String in Anführungszeichen stehen.

Fazit

Webtop liefert dir einen vollständigen Linux-Desktop als Container – mit XFCE leichtgewichtig, mit KasmVNC komfortabel im Browser bedienbar und mit ./config erstaunlich wartungsarm. Die wichtigsten Merksätze:

  1. Port nur auf 127.0.0.1 binden – der Browser-Desktop gehört hinter den Reverse Proxy.
  2. Docker-Socket nur einbinden, wenn du ihn wirklich brauchst – er ist gleichbedeutend mit Root auf dem Host.
  3. Starkes PASSWORD + Basic Auth am Proxy – der Login ist der einzige Türwächter.
  4. Watchtower für diesen Container deaktivieren und Updates bewusst manuell fahren.

Damit hast du einen „Desktop in der Tasche“ – auf jedem Gerät mit Browser. Viel Spaß beim Ausprobieren!

📝
HuuuHosting-Redaktion

Open-Source-Tools für den eigenen Server – getestet, dokumentiert und in der Debian-13-Serie Schritt für Schritt erklärt.