Ein eigener Server für eure Community.

Linux-Server mit Docker

Der empfohlene Weg für einen gemieteten Server: ein Skript, ein paar Fragen, fertig.

Was du brauchst

• Einen Linux-Server (x86_64) mit root-Zugang über sudo, etwa einen gemieteten vServer mit Debian oder Ubuntu, dazu curl. Docker samt Compose-Plugin installiert das Skript bei Bedarf mit. Rund 1 GB Arbeitsspeicher für App, Datenbank und LiveKit zusammen, mehr bei vielen gleichzeitigen Videos.
• Eine eigene Domain, etwa chat.example.org, deren DNS auf den Server zeigt. Browser geben Mikrofon und Kamera nur über HTTPS frei; einzige Ausnahme ist localhost.
• Eingehend 80/tcp und 443/tcp für den mitgelieferten Proxy sowie 7881/tcp und 7882/udp direkt zu LiveKit. Die Medienports laufen nie über einen HTTP-Proxy; hinter einem Router leitest du sie weiter. Sind 7881 oder 7882 schon belegt, wählst du im Skript andere.
• Für Video Upload-Bandbreite am Server: LiveKit leitet jede Kamera an alle Zuschauenden weiter, der Upload wächst also mit Kameras mal Zuschauenden. Ein voller Kanal mit 15 Kameras und 15 Zuschauenden braucht grob 60 Mbit/s Upload und 20 Mbit/s Download – hochgerechnet aus einer Messung von etwa 4 Mbit/s je zuschauender Person. Für große Videokanäle mietest du einen Server; ein Heimanschluss reicht dafür meist nicht.

Belastbare Größenempfehlungen für den Produktivbetrieb oder garantierte Teilnehmerzahlen liegen noch nicht vor. Wer bereits einen Reverse Proxy betreibt, wählt das im Skript aus; mehr dazu unter Vorhandenen Reverse Proxy verwenden.

Installieren

Melde dich per SSH auf dem Server an, lade das Installationsskript und starte es. Es ist ein lesbares Bash-Skript: Vorher ansehen kannst du es auf GitHub.

curl -fsSL https://raw.githubusercontent.com/danielklessa/squorli/main/deploy/install.sh -o install.sh
sudo bash install.sh

Das Skript fragt der Reihe nach, auf Deutsch oder Englisch. Vorschläge in eckigen Klammern übernimmst du mit Enter:

1. Domain – genau der Hostname, den die Browser aufrufen, ohne https://. Das Skript zeigt, auf welche Adresse sie im DNS zeigt.
2. Servername – der Anfangsname, später in der Verwaltung änderbar.
3. Wer sich um HTTPS kümmert – der mitgelieferte Caddy mit Let's-Encrypt-Zertifikat, ein Reverse Proxy auf demselben Rechner oder einer auf einem anderen Rechner (Vorhandenen Reverse Proxy verwenden).
4. Ports – das Skript zeigt, welche Ports es braucht, prüft, ob ein anderer Dienst sie schon belegt, und schlägt dann freie vor. Jeden Port kannst du auch selbst wählen. Nur Caddy braucht fest 80 und 443, weil Let's Encrypt die Domain darüber prüft.
5. Squorli Directory – ja (Vorschlag, bringt deinen Mitgliedern ein globales Konto), nein (der Server arbeitet für sich allein, mit eigenen Serverkonten ~name) oder ein anderes Directory.
6. Wer Eigentümerin wird – dein Squorli-Konto über seinen öffentlichen Schlüssel (nur mit Directory), ein Serverkonto (~name), das du mit einem Einrichtungscode registrierst, den das Skript erzeugt und am Ende anzeigt, oder wer sich zuerst mit einem Konto anmeldet (Erste Anmeldung).
7. Öffentliche IP für Sprache und Video – leer lassen, dann ermittelt LiveKit sie selbst. Nur bei NAT oder mehreren Netzwerkschnittstellen trägst du die öffentliche IP ein.
8. Container-Image – der Vorschlag ist ghcr.io/danielklessa/squorli-server:latest. Für den Produktivbetrieb setzt du einen festen Tag oder Digest von der Paketseite bei GitHub ein.

Nach einer Zusammenfassung und deiner Bestätigung erledigt es den Rest. Fehlt Docker, installiert es Docker nach Rückfrage mit dem offiziellen Skript von get.docker.com. Es legt die Konfiguration in /opt/squorli ab, erzeugt Datenbankpasswort und LiveKit-Geheimnis als Zufallswerte in einer nur für root lesbaren .env, öffnet nach Rückfrage die Ports in einer aktiven ufw- oder firewalld-Firewall, holt die Images, startet die Container und prüft /api/health und /rtc/validate über deine Domain. Eine Firewall beim Hoster und Weiterleitungen im Router richtest du selbst ein.

Am Ende nennt das Skript die Adresse deines Servers. Antwortet sie noch nicht über HTTPS, stimmen meist DNS oder die eingehenden Ports noch nicht; Caddy versucht es von allein weiter (Fehler beheben).

Du kannst das Skript jederzeit erneut ausführen: Es erkennt die bestehende Installation und bietet an, sie zu aktualisieren oder ihre Einstellungen zu ändern. Geheimnisse, Datenbank und Dateien bleiben dabei erhalten, geänderte Dateien sichert es mit der Endung .bak. Das fertige Image gibt es derzeit nur für x86_64 (amd64); auf ARM-Rechnern baust du aus dem Quellcode.

Updates und Backups

Das Installationsskript richtet den Befehl squorli ein, der die Installation in /opt/squorli verwaltet:

# The installer's command for this installation (run as root)
sudo squorli status
sudo squorli logs server
sudo squorli backup
sudo squorli update
# Checks domain, certificate, proxy, LiveKit, media ports and the directory
sudo squorli doctor
# Replaces database and files with a backup (asks first)
sudo squorli restore /opt/squorli/backups/20260925-120000

squorli backup schreibt einen Datenbank-Dump, ein Archiv mit Anhängen und Vorschaubildern und eine Kopie der .env in einen Ordner unter /opt/squorli/backups. Der Identitätsschlüssel des Servers liegt in der Datenbank; Anhänge allein sind kein vollständiges Backup. Bewahre die Kopien außerhalb des Servers auf. squorli restore mit so einem Ordner spielt ihn zurück: Es hält die App an, ersetzt Datenbank und alle Dateien durch die der Sicherung und startet wieder; die .env bleibt, wie sie ist. Für einen Umzug auf einen neuen Host installierst du dort zuerst, kopierst dann den Ordner hinüber und spielst ihn zurück. squorli update holt die aktuellen Images, sichert zuerst, wenn eines davon neu ist, und startet nur die Container neu, deren Image sich geändert hat; die anderen laufen weiter. Das Installationsskript erneut auszuführen und „Aktualisieren“ zu wählen, erneuert zusätzlich die Konfigurationsdateien von Compose, Caddy und LiveKit.

squorli doctor prüft, was bei einer Einrichtung am häufigsten schiefgeht, und benennt die wahrscheinliche Ursache: ob die Domain auflöst und das Zertifikat gilt, ob der Proxy das WebSocket-Upgrade und /rtc zu LiveKit durchreicht, ob LiveKit den API-Schlüssel annimmt, ob der TCP-Medienport erreichbar ist und ob das Directory den Server erreicht. Ist ein Directory eingetragen, wiederholt es die Prüfungen von außen, denn ob die eigenen Ports aus dem Internet offen sind, sieht der Server selbst nicht. Dieselbe Prüfung gibt es im Client unter Verwaltung › Server › „Verbindung prüfen“; dort baut der Browser zusätzlich eine echte Medienverbindung auf und sagt, ob sie über UDP läuft, nur über TCP oder gar nicht.

Notiere die Image-Version: latest ist veränderlich, und Migrationen laufen beim Start – ein Zurücksetzen des Images macht eine Datenbankänderung nicht rückgängig.

Automatische Updates

squorli autoupdate on richtet einen Job ein, der in einem Abstand deiner Wahl, von stündlich bis einmal täglich, nach neuen Images sucht und sie einspielt. Gibt es nichts Neues, startet nichts neu; gibt es etwas, sichert der Job zuerst und startet nur neu, was sich geändert hat. squorli autoupdate zeigt den Stand und die letzten Läufe, squorli autoupdate off entfernt den Job. squorli update --check sieht nur nach.

# Looks for new images every so many hours and installs them; asks for the hours (1 to 24)
sudo squorli autoupdate on
# The state and the last runs
sudo squorli autoupdate
sudo squorli autoupdate off
# Only looks: exit code 10 when something is new, 0 when not
sudo squorli update --check

Kennt dein squorli den Befehl autoupdate noch nicht, führe das Installationsskript erneut aus und wähle „Aktualisieren“: Es schreibt den Befehl neu.

Windows ohne Docker

Für einen Windows-Rechner gibt es ein Paket, das kein Docker braucht: der App-Server mit eigenem Node.js, dazu PostgreSQL, LiveKit und Caddy, eingerichtet als Windows-Dienste. Es ist dasselbe Squorli wie unter Linux, mit denselben Fragen bei der Einrichtung und demselben Befehl squorli zum Verwalten.

Was du brauchst

• Windows 10 ab 22H2, Windows 11 (auch Home) oder Windows Server 2019, 2022 oder 2025, jeweils 64 Bit (x64). Ein Konto mit Administratorrechten, 2 GB freier Speicherplatz, rund 1 GB Arbeitsspeicher. Die Windows PowerShell gehört zu Windows; fehlt die Laufzeit von Microsoft Visual C++, lädt das Setup sie nach Rückfrage von Microsoft.
• Domain, Ports und Bandbreite wie beim Linux-Server: eine Domain, die auf den Rechner zeigt, eingehend 80/tcp und 443/tcp für den mitgelieferten Caddy sowie 7881/tcp und 7882/udp für Sprache und Video.
• Ein PC als Server hat Grenzen: Windows Update startet ihn neu, im Standby ist der Server nicht erreichbar (das Setup bietet an, Standby im Netzbetrieb abzuschalten), und der Upload eines Heimanschlusses ist für Video knapp. Hinter einem Router leitest du die Ports weiter; wechselt die öffentliche Adresse des Anschlusses, braucht die Domain DynDNS.
• Die Programme im Paket sind nicht signiert. Windows fragt deshalb unter Umständen nach, bevor es sie ausführt.

Installieren

Lade auf der Release-Seite bei GitHub aus dem neuesten Release mit dem Namen „Squorli Server“ zwei Dateien in denselben Ordner: squorli-server-<Version>-windows-x64.zip und die gleichnamige Datei mit der Endung .sha256. Öffne dann eine PowerShell als Administrator (Rechtsklick auf Start › Terminal (Administrator)), wechsle in diesen Ordner und führe aus:

# In the folder with the two downloaded files
$zip = Get-Item .\squorli-server-*-windows-x64.zip
# The next two lines must print the same value
(Get-FileHash $zip -Algorithm SHA256).Hash.ToLower()
(Get-Content "$zip.sha256").Split(' ')[0]
Unblock-File $zip
& "$env:SystemRoot\System32\tar.exe" -xf $zip
cd $zip.BaseName
powershell -ExecutionPolicy Bypass -File .\install.ps1

Die beiden ausgegebenen Zeilen müssen gleich sein: Dann ist das Paket das, das veröffentlicht wurde. Das Setup stellt dieselben Fragen wie das Installationsskript für Linux, auf Deutsch oder Englisch – ohne die nach dem Container-Image. Dazu kommt, was Windows braucht:

• Ordner – die Programme liegen in C:\Program Files\Squorli, die Daten in C:\ProgramData\Squorli.
• Alle fünf Ports – neben den Medienports auch die von App-Server, LiveKit-Signalisierung und Datenbank, weil sie hier Ports des Rechners selbst sind. Belegte ersetzt das Setup durch freie.
• Windows-Firewall – nach Rückfrage gibt das Setup die Medienports frei, mit dem mitgelieferten Caddy auch 80 und 443.
• Standby – nur auf einem PC: ob Standby und Ruhezustand im Netzbetrieb abgeschaltet werden.

Danach kopiert es die Programme, schreibt die .env mit frischen Zufallswerten (lesbar nur für Administratoren und den Dienst des App-Servers), legt die Datenbank an und richtet die Dienste SquorliPostgres, SquorliLiveKit, SquorliServer und – mit dem mitgelieferten Caddy – SquorliCaddy ein. Sie starten mit Windows, ohne dass sich jemand anmeldet, laufen jeweils unter einem eigenen Dienstkonto und werden nach einem Absturz neu gestartet. Zum Schluss prüft das Setup /api/health und /rtc/validate und nennt die Adresse und, falls gewählt, den Einrichtungscode für die erste Anmeldung.

Verwalten, Updates und Backups

Das Setup richtet den Befehl squorli ein. Er gilt in neu geöffneten Fenstern und braucht Administratorrechte:

# The setup's command for this installation (in a newly opened window, as administrator)
squorli status
squorli logs server
squorli backup
squorli update
# Checks domain, certificate, proxy, LiveKit, media ports and the directory
squorli doctor
# One service, or all of them, with the services that depend on it
squorli restart server
# Replaces database and files with a backup (asks first); takes a backup of a Linux installation too
squorli restore C:\ProgramData\Squorli\backups\20260928-120000

squorli backup schreibt Datenbank, Dateien und eine Kopie der .env in einen Ordner unter C:\ProgramData\Squorli\backups, den nur Administratoren lesen können; bewahre Kopien außerhalb des Rechners auf. squorli restore spielt so einen Ordner zurück und nimmt auch die Sicherung einer Linux-Installation an – so zieht ein Server von Linux nach Windows um. squorli logs zeigt die letzten Zeilen, mit -Follow liest es weiter mit. squorli doctor prüft dasselbe wie unter Linux.

squorli update holt das neueste Release von GitHub, prüft dessen SHA-256-Prüfsumme, sichert zuerst und führt dann das Setup der neuen Version aus. Angehalten werden nur die Dienste, deren Programme sich geändert haben: Bringt ein Update nur eine neue Version von Squorli, laufen PostgreSQL und LiveKit weiter. Startet die neue Version nicht, holt es die bisherigen Programmdateien zurück. Migrationen der Datenbank macht das nicht rückgängig: Dafür ist die Sicherung da, die das Update zuvor geschrieben hat.

# Change settings: the setup again, it finds the installation
powershell -ExecutionPolicy Bypass -File "C:\Program Files\Squorli\install.ps1"
# Remove services and programs; the data stays unless you type "delete"
powershell -ExecutionPolicy Bypass -File "C:\Program Files\Squorli\uninstall.ps1"

Das Setup erneut auszuführen, ändert die Einstellungen; Geheimnisse, Datenbank und Dateien bleiben. Beim Entfernen bleibt der Datenordner erhalten, solange du nicht ausdrücklich „löschen“ eintippst.

Automatische Updates

squorli autoupdate on richtet in der Aufgabenplanung von Windows eine Aufgabe ein, die in einem Abstand deiner Wahl, von stündlich bis einmal täglich, nach einer neuen Version sucht und sie einspielt. Gibt es keine, wird nichts angehalten; gibt es eine, sichert die Aufgabe zuerst und hält nur an, was sich geändert hat. squorli autoupdate zeigt den Stand und die letzten Läufe, squorli autoupdate off entfernt die Aufgabe. squorli update -Check sieht nur nach.

# Looks for a new version every so many hours and installs it; asks for the hours (1 to 24)
squorli autoupdate on
# The state and the last runs
squorli autoupdate
squorli autoupdate off
# Only looks: exit code 10 when there is a newer version, 0 when not
squorli update -Check

Die Befehle kommen mit der ersten Version nach 0.6.0: Kennt dein squorli den Befehl autoupdate noch nicht, führe einmal squorli update aus.

Mit vorhandenem Webserver

Auf vielen Windows-Servern hält IIS bereits die Ports 80 und 443. Das Setup erkennt das, nennt das Programm und schlägt „Ein Reverse Proxy auf diesem Rechner“ vor: App-Server und LiveKit lauschen dann nur auf 127.0.0.1, und dein Webserver leitet an sie weiter. Vorlagen für nginx, Caddy und IIS (URL Rewrite und Application Request Routing) liegen nach der Installation in C:\Program Files\Squorli\proxies; die für IIS wurde noch nicht mit einer echten Installation geprüft. Was der Proxy können muss, steht unter Vorhandenen Reverse Proxy verwenden.

Von Hand mit Docker Compose

Das Installationsskript für Linux führt nur die folgenden Schritte aus. Wer jeden davon selbst in der Hand behalten möchte, installiert so von Hand – in einem beliebigen Ordner, mit Docker Engine, Compose-Plugin, curl und OpenSSL. Was der Server braucht, steht unter Linux-Server.

Konfiguration herunterladen

mkdir -p squorli/deploy/caddy squorli/deploy/livekit squorli/deploy/proxies
cd squorli
curl -fL https://raw.githubusercontent.com/danielklessa/squorli/main/.env.example -o .env
curl -fL https://raw.githubusercontent.com/danielklessa/squorli/main/deploy/compose.yml -o deploy/compose.yml
curl -fL https://raw.githubusercontent.com/danielklessa/squorli/main/deploy/caddy/Caddyfile -o deploy/caddy/Caddyfile
curl -fL https://raw.githubusercontent.com/danielklessa/squorli/main/deploy/livekit/livekit.yaml -o deploy/livekit/livekit.yaml
curl -fL https://raw.githubusercontent.com/danielklessa/squorli/main/deploy/proxies/nginx.ports.yml -o deploy/proxies/nginx.ports.yml

Diese Befehle laden fünf Konfigurationsdateien in einen neuen Ordner squorli, keinen Quellcode: Anwendung und Webclient kommen aus dem fertigen Container-Image. Das nginx-Overlay brauchst du nur für das Heim-Setup oder einen eigenen Reverse Proxy. Führe den Download einmal in einem neuen Verzeichnis aus – ein erneuter Download würde deine ausgefüllte .env überschreiben. Squorli Server steht unter der Apache License 2.0; siehe LICENSE und NOTICE im Repository.

Die Datei .env ausfüllen

Öffne .env im Ordner squorli mit einem Texteditor und ersetze Hostnamen und Geheimnisse. Die Datei enthält Passwörter: halte sie privat.

PUBLIC_DOMAIN=chat.example.org
SERVER_NAME=My community
APP_IMAGE=ghcr.io/danielklessa/squorli-server:latest
PROXY_MODE=bundled
POSTGRES_PASSWORD=REPLACE_WITH_RANDOM_HEX
LIVEKIT_API_KEY=squorli
LIVEKIT_API_SECRET=REPLACE_WITH_ANOTHER_RANDOM_HEX
DIRECTORY_URL=https://directory.squorli.com
LIVEKIT_NODE_IP=
# Optional: reserve initial ownership for your public key
# OWNER_PUBLIC_KEY=YOUR_64_CHARACTER_HEX_PUBLIC_KEY

Erzeuge für jedes Geheimnis einen eigenen Zufallswert. Ein Hex-Wert vermeidet außerdem reservierte Zeichen in der Datenbank-URL.

openssl rand -hex 32

Alle weiteren Variablen sind in der Umgebungsvorlage dokumentiert, darunter SERVER_NAME (Anfangsname, später in der Verwaltung änderbar), MAX_UPLOAD_MB (Obergrenze für Anhänge, Standard 25), LINK_PREVIEWS (Vorschauen zu verlinkten Seiten, standardmäßig an; false schaltet sie und die ausgehenden Anfragen des Servers ab) und LOG_REQUESTS (eine Log-Zeile pro Anfrage mit IP-Adresse, nur zur Fehlersuche; standardmäßig aus).

Starten und prüfen

cd deploy
docker compose --env-file ../.env --profile bundled pull
docker compose --env-file ../.env --profile bundled up -d --no-build
docker compose --env-file ../.env --profile bundled ps
docker compose --env-file ../.env --profile bundled logs --tail=100 server

Gib immer --env-file ../.env an: ohne diese Angabe bleiben Datenbankpasswort und LiveKit-Schlüssel leer. pull holt das fertige Image, --no-build verhindert einen lokalen Build. Die Datenbankmigrationen laufen beim Start der App automatisch.

Caddy fordert jetzt ein Zertifikat für deine Domain an; dafür müssen DNS und die eingehenden Ports stimmen. Danach prüfst du zwei Adressen:

curl -fsS https://chat.example.org/api/health
curl -s -o /dev/null -w '%{http_code}\n' https://chat.example.org/rtc/validate

Die Health-Antwort nennt ok: true, deine domain und einen serverKey. HTTP 401 von /rtc/validate ist ohne Token richtig und zeigt, dass die Anfrage LiveKit erreicht. Ob Medien fließen, ist damit noch nicht geprüft – das zeigt erst der erste Sprachkanal.

Sichern, aktualisieren, zurückspielen

Du sicherst und aktualisierst aus squorli/deploy mit diesen Befehlen – mit deinem tatsächlichen Profil und deinen Overlays, ohne git pull und ohne die .env erneut herunterzuladen:

# Run from deploy; write a logical database backup to a private location
docker compose --env-file ../.env --profile bundled exec -T postgres pg_dump -U chat -d chat > squorli-database.sql
# Attachments and link preview pictures out of the volume of the project squorli
docker run --rm -v squorli_appdata:/data:ro -v "$PWD":/backup alpine tar czf /backup/squorli-files.tar.gz -C /data .

Pausiere für einen konsistenten Stand die Schreibzugriffe während der Sicherung. Der SQL-Dump enthält Serverdaten, aber weder Anhänge noch .env.

# Run from squorli/deploy after reviewing the update and backing up
docker compose --env-file ../.env --profile bundled pull
docker compose --env-file ../.env --profile bundled up -d --no-build
docker compose --env-file ../.env --profile bundled logs --tail=100 server

Zurückspielen, im Ordner mit den beiden Sicherungsdateien:

# Run from deploy with your profile and overlays; replaces the database and all files
docker compose --env-file ../.env --profile bundled stop server
docker compose --env-file ../.env --profile bundled exec -T postgres psql -U chat -d postgres -c 'DROP DATABASE chat WITH (FORCE)' -c 'CREATE DATABASE chat OWNER chat'
docker compose --env-file ../.env --profile bundled exec -T postgres psql -q -v ON_ERROR_STOP=1 -U chat -d chat < squorli-database.sql
docker run --rm -i -v squorli_appdata:/data alpine sh -c 'find /data -mindepth 1 -delete && tar xzf - -C /data' < squorli-files.tar.gz
docker compose --env-file ../.env --profile bundled up -d --no-build

Notiere die Image-Version: latest ist veränderlich, und Migrationen laufen beim Start – ein Zurücksetzen des Images macht eine Datenbankänderung nicht rückgängig. Vermeide docker compose down -v auf dem Produktivserver: Der Befehl löscht die Volumes mit allen Daten.

Zuhause ausprobieren

Zum Kennenlernen braucht es weder Domain noch Zertifikat: Der Server läuft auf deinem eigenen Rechner, und du rufst ihn unter http://localhost:3000 auf. Weil Browser localhost als sicheren Kontext behandeln, funktionieren dort auch Mikrofon, Kamera und Bildschirmfreigabe.

Mit Docker brauchst du unter Windows Docker Desktop, unter Linux Docker Engine mit dem Compose-Plugin. Dieses Heim-Setup wird von Hand eingerichtet, nicht mit dem Installationsskript.

Hole die Konfiguration – unter Linux mit dem Download-Befehl der Installation von Hand, unter Windows mit diesem Block in einer PowerShell:

mkdir squorli\deploy\caddy, squorli\deploy\livekit, squorli\deploy\proxies
cd squorli
$b = "https://raw.githubusercontent.com/danielklessa/squorli/main"
curl.exe -fL $b/.env.example -o .env
curl.exe -fL $b/deploy/compose.yml -o deploy\compose.yml
curl.exe -fL $b/deploy/caddy/Caddyfile -o deploy\caddy\Caddyfile
curl.exe -fL $b/deploy/livekit/livekit.yaml -o deploy\livekit\livekit.yaml
curl.exe -fL $b/deploy/proxies/nginx.ports.yml -o deploy\proxies\nginx.ports.yml

Danach füllst du .env so aus – der Inhalt ist auf beiden Systemen derselbe:

PUBLIC_DOMAIN=localhost
SERVER_NAME=Test
APP_IMAGE=ghcr.io/danielklessa/squorli-server:latest
PROXY_MODE=external
POSTGRES_PASSWORD=REPLACE_WITH_RANDOM_HEX
LIVEKIT_API_KEY=squorli
LIVEKIT_API_SECRET=REPLACE_WITH_ANOTHER_RANDOM_HEX
# Local test only: the browser reaches LiveKit directly, LiveKit offers itself as 127.0.0.1
LIVEKIT_PUBLIC_URL=ws://localhost:7880
LIVEKIT_NODE_IP=127.0.0.1
# A server on localhost cannot prove its host to the Directory: sign in with a server account (~name)
DIRECTORY_URL=

Die Zufallswerte erzeugst du unter Linux mit openssl rand -hex 32, unter Windows mit der ersten Zeile des folgenden Blocks. notepad .env öffnet die Datei, die letzte Zeile prüft den laufenden Server:

# One random value per secret
-join (1..32 | ForEach-Object { '{0:x2}' -f (Get-Random -Maximum 256) })
notepad .env
# After the start: the server answers on localhost
curl.exe -fsS http://localhost:3000/api/health

Gestartet wird auf beiden Systemen mit demselben Befehl. Das Overlay nginx.ports.yml veröffentlicht App und LiveKit nur auf 127.0.0.1, von außen bleibt alles zu:

cd deploy
docker compose --env-file ../.env -f compose.yml -f proxies/nginx.ports.yml --profile external pull
docker compose --env-file ../.env -f compose.yml -f proxies/nginx.ports.yml --profile external up -d --no-build

Öffne http://localhost:3000 und erstelle ein Serverkonto (~name und Passwort); die erste Anmeldung mit Konto wird Eigentümerin; ein zweites Browserfenster – am besten ein privates Fenster oder ein zweites Profil – ist dein zweites Mitglied. Damit es ohne Einladung hineinkommt, schaltest du in der Verwaltung unter Server den offenen Beitritt ein. Texte, Sprachkanäle, Kamera und Bildschirmfreigabe funktionieren zwischen diesen Fenstern vollständig.

Zwei Grenzen hat der lokale Test: Ein zweites Gerät im Heimnetz kann nicht mitmachen, weil es localhost nicht erreicht und Browser über eine reine HTTP-Adresse kein Mikrofon freigeben. Und ein Directory-Konto funktioniert hier nicht: Das Directory prüft die Kontrolle über die Domain, indem es /api/health abruft – bei localhost landet es bei sich selbst. Melde dich im Test also mit einem Serverkonto an. Zum Aufräumen mit Docker:

# From squorli/deploy: stops the test and deletes its database and files
docker compose --env-file ../.env -f compose.yml -f proxies/nginx.ports.yml --profile external down -v

Vom Test zum echten Heimserver: Sobald Freunde mitmachen sollen, brauchst du eine Domain – auch ein kostenloser DynDNS-Name genügt – und in deinem Router Weiterleitungen für 80/tcp, 443/tcp, 7881/tcp und 7882/udp auf den Rechner, der den Server trägt. Danach installierst du auf einem Linux-Rechner oder einem Windows-Rechner und wählst den mitgelieferten Caddy: Er holt das Zertifikat, und Squorli läuft genauso wie auf einem gemieteten Server. Steht dein Anschluss hinter einem Carrier-Grade-NAT (keine eigene öffentliche IPv4-Adresse), funktionieren Portweiterleitungen nicht – dann bleibt nur ein Server mit öffentlicher Adresse.