Wer mehrere Linux-Server, einen Proxmox-Host und ein paar Windows-Maschinen betreut, jongliert oft mit PuTTY-Profilen, SSH-Konfigurationsdateien und getrennten RDP-Clients. Termix fasst das in einer selbst gehosteten Weboberfläche zusammen: SSH-Terminal mit Tabs und Split-Screen, SFTP-Dateimanager, SSH-Tunnel, Docker-Verwaltung, Host-Metriken und über den Guacamole-Daemon guacd auch RDP, VNC und Telnet. Das Projekt versteht sich als freie, selbst gehostete Alternative zu Termius.

Diese Anleitung richtet Termix per Docker Compose ein und führt durch Erstkonfiguration, Absicherung, Backup, Restore, Updates und Deinstallation. Alle als getestet markierten Schritte wurden am 25.09.2026 mit Termix 2.8.0 in einer isolierten Testumgebung ausgeführt. Zwei Befunde vorweg: Nach dem Anlegen des ersten Kontos bleibt die Selbstregistrierung offen, und wer bei einem Backup die Datei .env im Datenvolume vergisst, bekommt eine verschlüsselte Datenbank zurück, die sich nicht mehr öffnen lässt.

Was getestet wurde und was nicht

In einer eigenen Testumgebung ausgeführt und bestätigt:

Start des offiziellen Stacks aus docker/docker-compose.yml (Termix plus guacd 1.6.0) mit gepinntem Image ghcr.io/lukegus/termix:2.8.0, Port nur an 127.0.0.1 gebunden
Auswertung der Startlogs, Healthcheck des Containers, Erreichbarkeit von guacd aus dem Termix-Container
Anlegen des ersten Kontos (wird automatisch Admin), Login, falsches Passwort, Abschalten der Registrierung und Gegenprobe
Persistenz nach Neustart, Backup des Volumes als Tar-Archiv, vollständiges Löschen des Volumes und Restore mit Kontrolle eines Markers
Provozierter Schlüsselverlust (fehlende .env) mit echter Fehlermeldung und anschließender Wiederherstellung

Nicht selbst geprüft, Angaben stammen aus der offiziellen Dokumentation: echte SSH-, RDP- oder VNC-Verbindungen zu Zielsystemen, SFTP und Tunnel, OIDC, LDAP und TOTP, der Betrieb hinter einem Reverse Proxy mit TLS, das eingebaute ENABLE_SSL, PostgreSQL oder MySQL als Datenbank, ein Update von einer älteren Version, arm64-Hosts sowie die Bedienung der Weboberfläche im Browser. Die Erstkonfiguration wurde über dieselben HTTP-Endpunkte ausgeführt, die auch die Oberfläche aufruft.

Was Termix ist: Nutzen und Grenzen

Termix ist eine Node.js-Anwendung mit Weboberfläche, die im Container hinter einem internen nginx läuft. Hosts, Zugangsdaten, Snippets und Einstellungen liegen standardmäßig in einer SQLite-Datenbank, die laut Dokumentation als ganze Datei mit AES-256-GCM verschlüsselt auf der Platte liegt. Sensible Felder werden zusätzlich mit einem pro Benutzer abgeleiteten Schlüssel verschlüsselt, der aus dem Passwort entsteht. Neben dem Server gibt es Desktop-Clients für Windows, Linux und macOS, Apps für Android und iOS sowie eine CLI.

Laut GitHub-API (abgerufen am 25.09.2026) hat das Repository Termix-SSH/Termix 15.248 Sterne und 730 Forks, der letzte Push war am 24.09.2026, das Projekt ist nicht archiviert. Das jüngste Release release-2.8.0-tag erschien am 20.09.2026. Die API meldet als Lizenz nur NOASSERTION; die Datei LICENSE im Repository enthält jedoch den Apache-2.0-Lizenztext mit Copyright 2025 Luke Gustafson. Das Projekt betont, dass es keine Abos oder Bezahlstufen gibt.

Wofür Termix sinnvoll ist:

Zentrale Sammlung von Hosts mit Ordnern, Tags und wiederverwendbaren Zugangsdaten statt verstreuter Clientprofile
Zugriff auf Server von wechselnden Geräten, auch vom Tablet, ohne lokale SSH-Clients zu pflegen
Teams mit Rollen: Hosts lassen sich laut Doku mit Benutzern oder Rollen teilen, derzeit nur mit der Stufe Nur-Ansicht
Gelegentliche RDP- und VNC-Sitzungen aus derselben Oberfläche über guacd

Grenzen und Risiken:

Termix speichert Passwörter und private SSH-Schlüssel zu Ihren Servern. Eine kompromittierte Termix-Instanz ist ein Generalschlüssel für die gesamte Infrastruktur. Das bestimmt alle Entscheidungen zu Netzwerk, TLS und Backup weiter unten.
Die Weboberfläche spricht im Container nur HTTP. Laut Sicherheitsdokumentation wird das Passwort beim Login im Klartext im Request-Body übertragen; die Sicherheit hängt vollständig an TLS davor.
Termix sendet laut README einmal täglich einen anonymen Telemetrie-Ping. Abschaltbar mit ENABLE_TELEMETRY=false; im Test gesetzt, ob danach wirklich keine Verbindung mehr aufgebaut wird, wurde nicht per Mitschnitt geprüft.
Die Docker-Funktion ist ausdrücklich kein Ersatz für Portainer oder Dockge, sondern zur Verwaltung vorhandener Container gedacht.

Abgrenzung zu Apache Guacamole: Guacamole ist ein clientloses Remote-Desktop-Gateway mit Schwerpunkt RDP, VNC und SSH als Sitzung. Termix nutzt dessen Daemon guacd für die Remote-Desktop-Protokolle, legt aber den Fokus auf SSH-Arbeit: Terminal-Tabs, SFTP, Tunnel, Snippets, Metriken und Server-Verwaltungskarten. Wer vor allem Windows-Desktops für Anwender im Browser bereitstellen will, ist mit Guacamole weiterhin gut bedient; wer als Admin viele Linux-Server betreut, findet in Termix mehr Werkzeuge.

Voraussetzungen und Ressourcen

Linux-Host mit Docker Engine und Compose-Plugin (docker compose)
Laut offizieller Benchmark-Seite reichen für 1 bis 25 Hosts 1 CPU-Kern, 512 MB RAM und 1 GB Platte, für bis zu 100 Hosts 1 Kern und 1 GB RAM; für Remote Desktop wird ein zusätzlicher Kern und 1 GB empfohlen
Gemessen im Test im Leerlauf nach dem Anlegen des Admins: Termix 225,8 MiB RAM bei 0,14 Prozent CPU, guacd 10,5 MiB
Plattenplatz für Images: Termix 2.8.0 191 MB komprimiert und 902 MB entpackt, guacd 1.6.0 129 MB und 377 MB entpackt
Ein DNS-Name und ein Reverse Proxy mit TLS oder ein VPN, bevor die Instanz produktiv SSH-Zugangsdaten aufnimmt
Ausgehend Zugriff von Termix auf SSH (Port 22) beziehungsweise RDP/VNC der Zielsysteme

Der Erststart dauert spürbar: Im Test brauchte die Initialisierung des Backends 53,7 Sekunden, spätere Neustarts nur rund 5 Sekunden. Die Startseite liefert schon vorher HTTP 200, weil der interne nginx früher bereit ist als die API.

Unterstützte Plattformen und getestete Version

Das Image auf GHCR ist ein Multi-Arch-Image. Das Manifest für 2.8.0 enthielt beim Abruf linux/amd64 und linux/arm64. Getestet wurde ausschließlich auf amd64. Als Alternative zu GHCR nennt die Doku den Docker-Hub-Spiegel bugattiguy527/termix.

Komponente	Getestete Version	Hinweis
Termix	`ghcr.io/lukegus/termix:2.8.0`	Log: `Termix Backend starting - Version: 2.8.0`, der Endpunkt `/version` meldete `up_to_date`
guacd	`guacamole/guacd:1.6.0`	Log: `Guacamole proxy daemon (guacd) version 1.6.0 started`
Datenbank	SQLite (Standard)	Datei `db.sqlite.encrypted` im Volume

Wichtig beim Pinnen: Das GitHub-Release heißt release-2.8.0-tag, dieser Name existiert als Image-Tag aber nicht. Eine Manifest-Abfrage gegen GHCR ergab für 2.8.0 und release-2.8.0 jeweils HTTP 200, für release-2.8.0-tag HTTP 404. Verwenden Sie also 2.8.0. Der Tag :beta ist laut Doku ein wöchentlich überschriebener Entwicklungsstand und gehört nicht in die Produktion.

compose.yaml und .env

Grundlage ist die Datei docker/docker-compose.yml aus dem Repository, nicht das kürzere Beispiel im README. Das README-Beispiel veröffentlicht den guacd-Port 4822 auf dem Host; das ist unnötig, weil Termix guacd über das interne Compose-Netz erreicht, und sollte entfallen. Gegenüber der offiziellen Datei sind hier die Version gepinnt, der Port nur an localhost gebunden, die festen Containernamen entfernt und die Telemetrie abgeschaltet. Im Test standen dieselben Werte direkt in der Datei statt als Variablen.

# Arbeitsverzeichnis anlegen
sudo mkdir -p /opt/termix
cd /opt/termix

Die Datei /opt/termix/compose.yaml:

name: termix
services:
  termix:
    image: ghcr.io/lukegus/termix:${TERMIX_VERSION:-2.8.0}
    restart: unless-stopped
    ports:
      # nur lokal, TLS übernimmt der Reverse Proxy
      - "${TERMIX_BIND:-127.0.0.1}:${TERMIX_PORT:-8080}:8080"
    volumes:
      - termix-data:/app/data
    environment:
      PORT: "8080"
      GUACD_HOST: "guacd"
      GUACD_TUNNEL_HOST: "termix"
      GUACD_RECORDING_PATH: "/termix-data/session_recordings/guacamole"
      GUACD_DRIVE_PATH: "/termix-data/rdp-drive"
      ENABLE_TELEMETRY: "${ENABLE_TELEMETRY:-false}"
    depends_on:
      - guacd
    networks:
      - termix-net

  guacd:
    image: guacamole/guacd:1.6.0
    restart: unless-stopped
    # kein Port nach außen, Termix spricht guacd intern an
    volumes:
      - termix-data:/termix-data
    networks:
      - termix-net

volumes:
  termix-data:

networks:
  termix-net:

Die Datei /opt/termix/.env enthält keine Geheimnisse. Die eigentlichen Schlüssel erzeugt Termix beim ersten Start selbst und legt sie im Datenvolume ab.

# /opt/termix/.env
TERMIX_VERSION=2.8.0
TERMIX_BIND=127.0.0.1
TERMIX_PORT=8080
ENABLE_TELEMETRY=false

Wer keinen Remote Desktop braucht, kann laut README den Dienst guacd, das Netz und die GUACD_*-Variablen weglassen. Dann sollte zusätzlich ENABLE_GUACAMOLE: "false" gesetzt werden (dokumentiert, nicht getestet).

Parameter und Dateipfade erklärt

Parameter	Bedeutung
`PORT: "8080"`	Port des internen nginx im Container. Laut Doku darf er nicht im reservierten Bereich 30001 bis 30005 liegen, dort laufen die Backend-Dienste.
`termix-data:/app/data`	Alle persistenten Daten: verschlüsselte Datenbank, `.env` mit Schlüsseln, Uploads, OPKSSH-Binärdatei, Zertifikate.
`termix-data:/termix-data` bei guacd	Dasselbe Volume, damit `guacd` Sitzungsaufzeichnungen und RDP-Laufwerke ablegen kann, die Termix anschließend liest.
`GUACD_HOST`, `GUACD_TUNNEL_HOST`	Servicename von `guacd` und der Name, unter dem `guacd` Termix für Jump- und Tunnelverbindungen zurück erreicht.
`GUACD_RECORDING_PATH`, `GUACD_DRIVE_PATH`	Pfade im `guacd`-Container für Aufzeichnungen und die Laufwerksumleitung bei RDP.
`ENABLE_TELEMETRY`	`false` schaltet den täglichen anonymen Ping ab und sperrt den Schalter in den Admin-Einstellungen.
`ALLOW_REGISTRATION`	Optional. Überschreibt und sperrt laut Doku den Registrierungsschalter der Oberfläche. Im Test nicht verwendet.
`PUID`, `PGID`	Standard 1000. Der Entrypoint setzt damit die Rechte auf `/app/data` und startet die App als Benutzer `node`.
`DATABASE_DIALECT`, `DATABASE_URL`	Optional `postgres` oder `mysql` statt SQLite, etwa für mehrere Instanzen. Nicht getestet.

Installation und Start

# Konfiguration prüfen, gibt bei Fehlern die Zeile aus
docker compose config -q

# Images laden und Stack im Hintergrund starten
docker compose up -d

# Start verfolgen, bis "Termix backend started successfully" erscheint
docker compose logs -f termix

Im Test erschienen beim Erststart unter anderem diese Zeilen. Sie bestätigen, dass die Schlüssel erzeugt und das Datenverzeichnis beschreibbar ist:

Setting up user permissions (PUID: 1000, PGID: 1000)...
SSL disabled - using HTTP-only configuration (default)
Data directory is writable
[INFO] Termix Backend starting - Version: 2.8.0 [op:startup]
[SUCCESS] JWT secret auto-generated and saved to .env [op:jwt_auto_generated]
[SUCCESS] Database key auto-generated and saved to .env [op:db_key_auto_generated]
[SUCCESS] Database initialized (sqlite) [op:backend_init_db]
[INFO] Guacamole server initialized [op:guac_init]
[SUCCESS] Termix backend started successfully [op:backend_init_complete,duration:53704ms]

Erstkonfiguration: Admin-Konto und Registrierung abschalten

Rufen Sie die Oberfläche auf, bei lokaler Bindung etwa per SSH-Portweiterleitung mit ssh -L 8080:127.0.0.1:8080 admin@server und dann http://localhost:8080. Solange kein Konto existiert, antwortet /users/setup-required mit {"setup_required":true}. Das erste registrierte Konto wird automatisch Administrator; im Test lautete die Antwort {"message":"User created","is_admin":true}.

Achtung, Testbefund: Nach dem ersten Konto bleibt die Registrierung offen. Ein zweites Konto ließ sich ohne Anmeldung anlegen, die Antwort war {"message":"User created","is_admin":false}. Jeder, der die URL erreicht, kann sich also ein Konto erstellen. Legen Sie das Admin-Konto deshalb an, bevor die Instanz über den Reverse Proxy erreichbar ist, und schalten Sie die Registrierung sofort ab.

In der Oberfläche: Admin-Einstellungen über die Schaltfläche mit Ihrem Benutzernamen unten links, dort die Registrierung deaktivieren.
Im Test über denselben Endpunkt, den die Oberfläche nutzt: PATCH /users/registration-allowed mit {"allowed":false}. Danach meldete ein neuer Registrierungsversuch {"error":"Registration is currently disabled"} mit HTTP 403.
Optional dauerhaft festschreiben mit ALLOW_REGISTRATION: "false" in der compose.yaml, nachdem das Admin-Konto existiert (dokumentiert, nicht getestet).
TOTP für das Admin-Konto aktivieren. Laut Doku sind Anmeldeversuche pro IP und Benutzername begrenzt, bei Überschreitung folgt eine Sperre von 10 Minuten.
Einen Eintrag im Log gibt es bei falschem Passwort: [WARN] Login failed: incorrect password. Das eignet sich als Quelle für Fail2ban oder ein zentrales Log.

Für die ersten Hosts empfiehlt sich die Anmeldung per SSH-Schlüssel statt Passwort. Zum Teilen von Hosts mit anderen Benutzern verlangt Termix laut Doku gespeicherte Zugangsdaten (Credentials), weil direkt am Host hinterlegte Geheimnisse mit dem Passwort des Besitzers verschlüsselt sind.

Funktions- und Healthcheck

Das Image bringt einen eigenen Docker-Healthcheck mit, der den internen Backend-Port abfragt. Von außen ist der Pfad /health nicht erreichbar, er liefert über den nginx des Containers HTTP 404. Das ist kein Fehler.

# Containerstatus, termix muss "healthy" zeigen
docker compose ps

# Healthcheck im Container, erwartet HTTP/1.1 200 OK
docker compose exec termix wget -S -qO- http://localhost:30001/health

# Weboberfläche vom Host
curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:8080/

# Status ohne Anmeldung: Einrichtung nötig und Registrierung erlaubt?
curl -s http://127.0.0.1:8080/users/setup-required
curl -s http://127.0.0.1:8080/users/registration-allowed

Im Test lieferte die Oberfläche HTTP 200, docker compose ps zeigte Up 2 minutes (healthy), nach dem Abschalten meldete registration-allowed den Wert {"allowed":false}. Der Endpunkt /users/db-health verlangt eine Anmeldung und gab danach {"status":"ok"} zurück.

Der Container guacd zeigte über Minuten health: starting. Ursache ist der Healthcheck im guacd-Image mit einem Intervall von 300 Sekunden. Die Verbindung von Termix zu guacd auf Port 4822 war im Test sofort erreichbar, und guacd meldete Listening on host 0.0.0.0, port 4822.

Persistente Daten und Rechte

Nach dem ersten Start lag im Volume unter /app/data Folgendes, Eigentümer war node mit UID und GID 1000:

-rw-r--r-- node node    392 .env
drwxr-xr-x node node        .opk
drwxr-xr-x node node        acme-webroot
-rw-r--r-- node node 905456 db.sqlite.encrypted

Die .env enthält JWT_SECRET, DATABASE_KEY, ENCRYPTION_KEY und INTERNAL_AUTH_TOKEN. Ohne DATABASE_KEY ist db.sqlite.encrypted nicht lesbar. Nach dem ersten Neustart legte Termix 2.8.0 zusätzlich eine Sicherung unter backups/pre-database-layer-refactor-<Zeitstempel>/ an, die ebenfalls eine Kopie der .env enthält. Beide Dateien waren mit Modus 644 abgelegt.

Konsequenz: Wer Lesezugriff auf das Docker-Volume hat, also root auf dem Host oder Mitglieder der Gruppe docker, kann die Datenbank entschlüsseln. Die Dokumentation nennt das selbst als Schwachstelle. Betreiben Sie Termix deshalb auf einem Host, auf dem nur Administratoren Docker-Rechte haben, und behandeln Sie jedes Backup wie einen Passworttresor.

Die Datenbank wird laut Doku beim Start in den Speicher entschlüsselt und periodisch zurückgeschrieben. Im Test überlebte ein 45 Sekunden vorher angelegter Eintrag einen normalen docker compose stop und Neustart. Harte Abbrüche wie Stromausfall wurden nicht getestet; stoppen Sie den Dienst für Backups und Wartung deshalb immer sauber.

Netzwerkfreigabe, Reverse Proxy und TLS

Sicherheitswarnung: Termix hält die SSH-Schlüssel und Passwörter Ihrer Server. Veröffentlichen Sie Port 8080 niemals direkt im Internet und niemals ohne TLS. Betreiben Sie Termix ausschließlich hinter einem Reverse Proxy mit gültigem Zertifikat, idealerweise zusätzlich nur aus einem VPN oder mit vorgeschalteter Authentifizierung erreichbar. Legen Sie das Admin-Konto an und sperren Sie die Registrierung, bevor Sie den Proxy freischalten.

Die folgenden Proxy-Konfigurationen stammen aus der offiziellen Doku und wurden nicht selbst geprüft. Entscheidend ist die Weiterleitung von WebSockets, sonst brechen Terminal-Sitzungen ab. Für nginx:

location / {
    proxy_pass http://127.0.0.1:8080;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

Caddy leitet WebSockets von selbst weiter, dort genügt reverse_proxy localhost:8080 im Block der Domain. Für Traefik nennt die Doku Labels mit loadbalancer.server.port=8080. Soll Termix unter einem Unterpfad laufen, gibt es VITE_BASE_PATH und BASE_PATH. Hinter einem Proxy mit OIDC ist laut Doku OIDC_FORCE_HTTPS=true nötig.

Die Trusted-Proxy-Authentifizierung (TRUSTED_PROXY_AUTH_ENABLED) übernimmt Benutzernamen und Rolle aus HTTP-Headern. Aktivieren Sie sie nur, wenn der Container ausschließlich über den Proxy erreichbar ist und TRUSTED_PROXY_AUTH_TRUSTED_PROXIES eng gesetzt ist, sonst kann jeder mit gefälschten Headern ein Admin werden. Alternativ bringt Termix mit ENABLE_SSL=true eine eigene HTTPS-Konfiguration mit, auch das wurde nicht getestet.

Die Weboberfläche setzte im Test bereits eine Content-Security-Policy sowie X-Frame-Options: DENY und X-Content-Type-Options: nosniff.

Backup und Restore

Gesichert wird das komplette Volume termix_termix-data inklusive .env. Stoppen Sie den Stack vorher, damit die im Speicher gehaltene Datenbank sauber geschrieben ist. Die folgende Sequenz wurde im Test mit einem Marker-Eintrag vollständig durchgespielt.

# 1. Stack sauber anhalten
cd /opt/termix
docker compose stop

# 2. Volume als Archiv sichern (Volume nur lesend eingebunden)
mkdir -p /srv/backup/termix
docker run --rm -v termix_termix-data:/data:ro -v /srv/backup/termix:/backup alpine:latest \
  tar czf /backup/termix-data-$(date +%F).tar.gz -C /data .

# 3. Stack wieder starten
docker compose start

# 4. Archiv schützen, es enthält den Datenbankschlüssel
sudo chmod 600 /srv/backup/termix/termix-data-*.tar.gz

Im Test war das Archiv 7,5 MB groß, den Großteil davon macht die mitgesicherte OPKSSH-Binärdatei aus. Es enthält unter anderem ./.env und ./db.sqlite.encrypted. Verschlüsseln Sie das Archiv vor der Ablage außerhalb des Hosts, etwa mit einem verschlüsselnden Backup-Werkzeug.

Restore auf einen leeren Zustand. Im Test wurde das Volume vorher mit docker compose down -v gelöscht:

# 1. Leeres Volume anlegen (Name = Projektname_Volumename)
docker volume create termix_termix-data

# 2. Archiv einspielen und Eigentümer auf node (1000:1000) setzen
docker run --rm -v termix_termix-data:/data -v /srv/backup/termix:/backup:ro alpine:latest \
  sh -c 'tar xzf /backup/termix-data-2026-09-25.tar.gz -C /data && chown -R 1000:1000 /data'

# 3. Stack starten
docker compose up -d

Rund 21 Sekunden nach dem Start war die Anmeldung mit dem alten Admin-Passwort wieder möglich, der Marker-Eintrag war vorhanden, die Benutzerzahl stimmte und die abgeschaltete Registrierung blieb abgeschaltet.

Getestetes Fehlerbild Schlüsselverlust: Fehlt die .env, etwa weil ein Backup nur db.sqlite.encrypted gesichert hat, erzeugt Termix beim Start neue Schlüssel und scheitert an der alten Datenbank:

[SUCCESS] Database key auto-generated and saved to .env
[ERROR] Database decryption authentication failed - possible causes: wrong DATABASE_KEY, corrupted files, or interrupted write
Error: Database decryption authentication failed. This usually means:
1. DATABASE_KEY has changed or is missing from /app/data/.env
[ERROR] Failed to initialize backend services [op:startup_failed]

Der Container ging in eine Neustartschleife (Restarting (1)), die API antwortete mit nginx-404. Nach dem Zurückspielen der originalen .env mit Eigentümer 1000:1000 startete Termix normal, alle Daten waren da. Ohne die originale Datei gibt es keinen Weg zurück.

Zusätzlich bietet Termix einen Export von Hosts und Zugangsdaten in der Oberfläche. Die Doku warnt, dass dieser Export unverschlüsselt ist. Für die Wiederherstellung ist das Volume-Backup der robustere Weg.

Updates und Rollback

# 1. Backup wie oben erstellen

# 2. Neue Version in .env eintragen, zum Beispiel
#    TERMIX_VERSION=2.8.1
nano /opt/termix/.env

# 3. Image laden und Container neu erstellen
docker compose pull
docker compose up -d

# 4. Version und Start im Log prüfen
docker compose logs termix | grep "Version:"

Die Release-Notes vor jedem Update lesen. Version 2.8.0 enthält neben neuen Funktionen wie Kollaborationsräumen, Step CA und 1Password Connect auch zahlreiche sicherheitsrelevante Korrekturen, etwa zur Prüfung der Host-Identität bei SSH-Verbindungen, zur TOTP-Prüfung und zur Integrität der OPKSSH-Binärdatei. Updates zeitnah einzuspielen ist bei einem Werkzeug mit dieser Rolle Pflicht.

Rollback-Grenzen: Termix migriert beim Start das Datenbankschema (im Log Schema migration completed). Ein bloßes Zurücksetzen des Image-Tags auf die alte Version ist nicht als unterstützt dokumentiert und wurde nicht getestet. Der sichere Rollback ist: Stack stoppen, Volume löschen, das Backup von vor dem Update einspielen und die alte Version starten. Änderungen seit dem Backup gehen dabei verloren.

Typische Fehler mit Diagnose und Lösung

Symptom	Diagnose	Lösung
Container startet immer neu, Log zeigt `Database decryption authentication failed`	`.env` fehlt oder enthält einen anderen `DATABASE_KEY` als beim Anlegen der Datenbank (im Test provoziert)	Originale `.env` aus dem Backup ins Volume kopieren, Eigentümer 1000:1000, neu starten
Startseite lädt, Anmeldung schlägt mit 404 fehl	Backend noch in der Initialisierung (Erststart im Test 53,7 s) oder abgestürzt; `docker compose logs termix`	Auf `Termix backend started successfully` warten, sonst den Fehler im Log beheben
`curl https://.../health` liefert 404	Der Healthcheck-Pfad ist nur intern auf Port 30001 erreichbar	`docker compose ps` oder `docker compose exec termix wget -qO- http://localhost:30001/health` nutzen
`guacd` bleibt lange auf `health: starting`	Healthcheck-Intervall des Images 300 s	Abwarten; Erreichbarkeit im Log (`Listening on ... port 4822`) prüfen
Pull scheitert mit `not found`	Release-Name `release-2.8.0-tag` als Tag verwendet (Manifest-Abfrage lieferte 404)	Tag `2.8.0` oder `release-2.8.0` verwenden
Fremde Konten tauchen in der Benutzerliste auf	Registrierung nach dem ersten Konto offen geblieben (im Test bestätigt)	Registrierung abschalten, unbekannte Konten löschen, Zugangsdaten rotieren
Terminal trennt hinter dem Proxy sofort	WebSocket-Upgrade fehlt (laut Doku)	`Upgrade`- und `Connection`-Header im Proxy setzen
Termix verweigert den Start mit leerem Datenverzeichnis	Laut Doku Schutz gegen versehentlich leeres `DATA_DIR`, wenn anderswo eine Datenbank gefunden wird	Volume-Pfad prüfen; `ALLOW_EMPTY_DATA_DIR=true` nur für einen bewusst frischen Start

Saubere Deinstallation

Warnung vor Datenverlust: Der folgende Befehl mit -v löscht das Volume termix_termix-data unwiderruflich, also alle Hosts, Zugangsdaten, Snippets, Aufzeichnungen und die Schlüssel. Erstellen Sie vorher ein Backup, falls Sie die Daten noch brauchen, und löschen Sie alte Backups anschließend sicher, weil sie weiterhin entschlüsselbare Zugangsdaten enthalten.

# 1. Container, Netz und Volume entfernen
cd /opt/termix
docker compose down -v --remove-orphans

# 2. Images gezielt entfernen
docker rmi ghcr.io/lukegus/termix:2.8.0 guacamole/guacd:1.6.0

# 3. Konfigurationsverzeichnis löschen
sudo rm -rf /opt/termix

# 4. Kontrolle: keine Reste mehr
docker volume ls --filter name=termix
docker ps -a --filter name=termix

Genauso wurde auch die Testumgebung abgebaut. Denken Sie zusätzlich an die Gegenseite: SSH-Schlüssel, die Termix auf Ihre Server verteilt hat, stehen weiterhin in deren authorized_keys und sollten dort entfernt werden.

Passende Anleitungen auf S-EDV

Guacamole auf Synology: RDP, SSH und VNC im Browser: Die Alternative mit Schwerpunkt Remote Desktop, wenn Anwender Windows-Desktops im Browser brauchen.
SSH-Key-Authentifizierung unter Linux und Windows einrichten: Schlüsselpaare erzeugen und verteilen, bevor Sie Hosts in Termix anlegen.
SSH-Hardening mit sshd_config und ssh-audit: Die Zielserver absichern, auf die Termix zugreift.

Quellen

Termix-SSH/Termix auf GitHub: Repository, README und Projektdaten, abgerufen am 25.09.2026.
Release-Notes Termix 2.8.0: Veröffentlicht am 20.09.2026.
Offizielle docker-compose.yml und LICENSE (Apache-2.0).
Termix-Doku: Installation mit Docker: Tags, Docker-Hub-Spiegel, Beta-Kanal.
Termix-Doku: Umgebungsvariablen: Registrierung, Telemetrie, Datenbank, guacd.
Termix-Doku: Sicherheit: Verschlüsselung, Schlüssel in der .env, bekannte Schwächen.
Termix-Doku: Reverse Proxy: nginx, Traefik, Caddy, Basispfad.
Termix-Doku: Benchmarks: Ressourcenempfehlungen nach Anzahl der Hosts.