Give your community its own server.

Linux server with Docker

The recommended way for a rented server: one script, a few questions, done.

What you need

• A Linux server (x86_64) with root access through sudo, such as a rented virtual server running Debian or Ubuntu, plus curl. The installer brings Docker and its Compose plugin along if they are missing. Around 1 GB of memory for the app, the database and LiveKit together, more with many simultaneous video streams.
• A domain of your own, such as chat.example.org, with DNS pointing at the server. Browsers only release microphone and camera over HTTPS; localhost is the single exception.
• Inbound 80/tcp and 443/tcp for the bundled proxy and 7881/tcp and 7882/udp straight to LiveKit. Media never travels through an HTTP proxy; behind a router, forward those ports. If 7881 or 7882 is already taken, choose others in the installer.
• For video, upload bandwidth at the server: LiveKit forwards every camera to every viewer, so the upload grows with cameras times viewers. A full channel with 15 cameras and 15 viewers needs roughly 60 Mbit/s upload and 20 Mbit/s download – a projection from a measurement of about 4 Mbit/s per viewer. For large video channels, rent a server; a home connection is usually too weak.

No validated production sizing or participant guarantee is available yet. If you already run a reverse proxy, choose that in the installer; Use an existing reverse proxy has the details.

Install

Log in to the server over SSH, download the installer and run it. It is a readable Bash script: you can look through it on GitHub beforehand.

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

The installer asks one question after another, in German or English. Press Enter to accept a suggestion in square brackets:

1. Domain – exactly the hostname browsers use, without https://. The installer shows which address it points to in DNS.
2. Server name – the initial name, changeable later in Administration.
3. Who takes care of HTTPS – the bundled Caddy with a Let's Encrypt certificate, a reverse proxy on the same machine, or one on another machine (Use an existing reverse proxy).
4. Ports – the installer shows which ports it needs, checks whether another service already holds them and then suggests free ones. You can also pick every port yourself. Only Caddy needs 80 and 443 fixed, because Let's Encrypt checks the domain over them.
5. Squorli Directory – yes (the suggestion, gives your members a global account), no (the server works on its own, with server accounts ~name of its own), or another directory.
6. Who becomes the owner – your Squorli account by its public key (with a directory only), a server account (~name) you register with a setup code the installer makes and shows at the end, or whoever signs in first with an account (First login).
7. Public IP for voice and video – leave it empty and LiveKit detects it itself. Only with NAT or several network interfaces do you enter the public IP.
8. Container image – the suggestion is ghcr.io/danielklessa/squorli-server:latest. For production, enter a fixed tag or digest from the GitHub container package.

After a summary and your confirmation it does the rest. If Docker is missing, it installs Docker with the official script from get.docker.com after asking. It places the configuration in /opt/squorli, generates the database password and the LiveKit secret as random values in a .env only root can read, opens the ports in an active ufw or firewalld firewall after asking, pulls the images, starts the containers and checks /api/health and /rtc/validate through your domain. A firewall at your hosting provider and port forwardings in a router are yours to set up.

At the end the installer names your server's address. If it does not answer over HTTPS yet, DNS or the inbound ports are usually not right yet; Caddy keeps trying on its own (Troubleshooting).

You can run the installer again at any time: it recognizes the existing installation and offers to update it or to change its settings. Secrets, database and files are kept, and changed files are saved with the extension .bak. The published image exists for x86_64 (amd64) only for now; on ARM machines, build from source.

Updates and backups

The installer sets up the command squorli, which manages the installation in /opt/squorli:

# 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 writes a database dump, an archive of attachments and preview pictures and a copy of .env into a folder under /opt/squorli/backups. The server's identity key lives in the database; attachments alone are not a complete backup. Keep the copies off the server. squorli restore with such a folder puts it back: it stops the app, replaces the database and all files with the backup's and starts again; the .env stays as it is. To move to a new host, install there first, then copy the folder over and restore it. squorli update pulls the current images, backs up first when one of them is new, and restarts only the containers whose image changed; the others keep running. Running the installer again and choosing “Update” also renews the configuration files for Compose, Caddy and LiveKit.

squorli doctor checks what goes wrong most often in a setup and names the likely cause: whether the domain resolves and the certificate is valid, whether the proxy passes the WebSocket upgrade and /rtc to LiveKit, whether LiveKit accepts the API key, whether the TCP media port is reachable and whether the Directory reaches the server. With a Directory configured it repeats the checks from outside, because a server cannot see for itself whether its ports are open from the internet. The same check exists in the client under Verwaltung › Server › “Check the connection”; there the browser also makes a real media connection and tells whether it runs over UDP, over TCP only, or not at all.

Record the image version: latest is mutable, and migrations run at startup – rolling the image back does not undo a database change.

Automatic updates

squorli autoupdate on sets up a job that looks for new images at an interval you choose, from every hour to once a day, and installs them. When nothing is new, nothing is restarted; when something is, the job backs up first and restarts only what changed. squorli autoupdate shows the state and the last runs, squorli autoupdate off removes the job. squorli update --check only looks.

# 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

If your squorli does not know autoupdate yet, run the installer again and choose “Update”: it writes the command anew.

Windows without Docker

For a Windows machine there is a package that needs no Docker: the app server with a Node.js of its own, plus PostgreSQL, LiveKit and Caddy, set up as Windows services. It is the same Squorli as on Linux, with the same questions during setup and the same command squorli to manage it.

What you need

• Windows 10 from 22H2, Windows 11 (Home too) or Windows Server 2019, 2022 or 2025, each 64 bit (x64). An account with administrator rights, 2 GB of free disk space, around 1 GB of memory. Windows PowerShell is part of Windows; if Microsoft's Visual C++ runtime is missing, the setup downloads it from Microsoft after asking.
• Domain, ports and bandwidth as for the Linux server: a domain that points at the machine, inbound 80/tcp and 443/tcp for the bundled Caddy, and 7881/tcp and 7882/udp for voice and video.
• A PC as a server has limits: Windows Update restarts it, in standby the server is unreachable (the setup offers to switch off standby on mains power), and the upload of a home connection is tight for video. Behind a router you forward the ports; if the connection's public address changes, the domain needs dynamic DNS.
• The programs in the package are not signed. Windows may therefore ask before it runs them.

Install

On the release page on GitHub, take two files from the newest release named “Squorli Server” into the same folder: squorli-server-<version>-windows-x64.zip and the file of the same name ending in .sha256. Then open a PowerShell as administrator (right-click Start › Terminal (Admin)), change into that folder and run:

# 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

The two lines printed must be the same: then the package is the one that was published. The setup asks the same questions as the installer for Linux, in German or English – without the one about the container image. It adds what Windows needs:

• Folders – the programs live in C:\Program Files\Squorli, the data in C:\ProgramData\Squorli.
• All five ports – besides the media ports also those of the app server, LiveKit's signaling and the database, because here they are ports of the machine itself. The setup replaces the ones in use by free ones.
• Windows firewall – after asking, the setup opens the media ports, and 80 and 443 with the bundled Caddy.
• Standby – on a PC only: whether standby and hibernation on mains power are switched off.

Then it copies the programs, writes the .env with fresh random values (readable by administrators and the app server's service only), creates the database and sets up the services SquorliPostgres, SquorliLiveKit, SquorliServer and – with the bundled Caddy – SquorliCaddy. They start with Windows without anybody signing in, run under a service account of their own each and are restarted after a crash. At the end the setup checks /api/health and /rtc/validate and names the address and, if chosen, the setup code for the first login.

Managing, updates and backups

The setup installs the command squorli. It works in newly opened windows and needs administrator rights:

# 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 writes the database, the files and a copy of .env into a folder under C:\ProgramData\Squorli\backups that only administrators can read; keep copies off the machine. squorli restore puts such a folder back and also takes the backup of a Linux installation – that is how a server moves from Linux to Windows. squorli logs shows the last lines, with -Follow it keeps reading. squorli doctor checks the same as on Linux.

squorli update fetches the newest release from GitHub, checks its SHA-256 checksum, backs up first and then runs the setup of the new version. It stops only the services whose programs changed: with a new version of Squorli alone, PostgreSQL and LiveKit keep running. If the new version does not start, it brings the previous program files back. That does not undo migrations of the database: the backup the update wrote before is there for that.

# 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"

Running the setup again changes the settings; secrets, database and files stay. When removing, the data folder is kept unless you explicitly type “delete”.

Automatic updates

squorli autoupdate on sets up a task in the Windows task scheduler that looks for a new version at an interval you choose, from every hour to once a day, and installs it. When there is none, nothing is stopped; when there is one, the task backs up first and stops only what changed. squorli autoupdate shows the state and the last runs, squorli autoupdate off removes the task. squorli update -Check only looks.

# 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

The commands arrive with the first version after 0.6.0: if your squorli does not know autoupdate yet, run squorli update once.

With a web server that is there already

On many Windows Servers IIS already holds ports 80 and 443. The setup notices, names the program and suggests “A reverse proxy on this machine”: the app server and LiveKit then listen on 127.0.0.1 only, and your web server forwards to them. Templates for nginx, Caddy and IIS (URL Rewrite and Application Request Routing) are in C:\Program Files\Squorli\proxies after the installation; the one for IIS has not been checked against a real installation yet. What the proxy has to do is described under Use an existing reverse proxy.

By hand with Docker Compose

The installer for Linux only carries out the following steps. If you want to keep each of them in your own hands, install manually like this – in any folder, with Docker Engine, the Compose plugin, curl and OpenSSL. What the server needs is listed under Linux server.

Download the configuration

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

These commands download five configuration files into a new squorli folder, no source code: the application and the web client come from the published container image. You only need the nginx overlay for the home setup or your own reverse proxy. Run the download once in a new directory – downloading again would overwrite the .env you filled in. Squorli Server is licensed under the Apache License 2.0; see LICENSE and NOTICE in the repository.

Fill in the .env file

Open .env in the squorli folder with a text editor and replace the hostname and the secrets. The file holds passwords: keep it private.

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

Generate a separate random value for each secret. A hex value also avoids reserved characters in the database URL.

openssl rand -hex 32

Every other variable is documented in the environment template, among them SERVER_NAME (the initial name, changeable later in Administration), MAX_UPLOAD_MB (attachment limit, 25 by default), LINK_PREVIEWS (previews for linked pages, on by default; false turns them and the server's outgoing requests off) and LOG_REQUESTS (one log line per request with the IP address, for troubleshooting only; off by default).

Start and check

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

Always pass --env-file ../.env: without it the database password and the LiveKit keys stay empty. pull fetches the published image and --no-build keeps Compose from building locally. Database migrations run automatically when the app starts.

Caddy now requests a certificate for your domain, which needs correct DNS and open inbound ports. Then check two addresses:

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

The health response names ok: true, your domain and a serverKey. HTTP 401 from /rtc/validate is correct without a token and shows that the request reaches LiveKit. It does not yet prove that media flows – the first voice channel does.

Back up, update, restore

Back up and update from squorli/deploy with these commands – with your actual profile and overlays, without git pull and without downloading your .env again:

# 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 .

For a consistent snapshot, pause writes during the backup. The SQL dump contains server data, but neither attachments nor .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

Restoring, in the folder with the two backup files:

# 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

Record the image version: latest is mutable, and migrations run at startup – rolling the image back does not undo a database change. Avoid docker compose down -v on a production server: it deletes the volumes with all their data.

Try it at home

To get to know Squorli you need neither a domain nor a certificate: the server runs on your own computer and you open it at http://localhost:3000. Because browsers treat localhost as a secure context, microphone, camera and screen sharing work there too.

With Docker you need Docker Desktop on Windows, on Linux Docker Engine with the Compose plugin. This home setup is done by hand, not with the installer.

Fetch the configuration – on Linux with the download command of the manual installation, on Windows with this block in a 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

Then fill in .env like this – the content is the same on both systems:

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=

Generate the random values with openssl rand -hex 32 on Linux, or with the first line of the following block on Windows. notepad .env opens the file; the last line checks the running 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

Both systems start it with the same command. The overlay nginx.ports.yml publishes the app and LiveKit on 127.0.0.1 only, so nothing is open to the outside:

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

Open http://localhost:3000 and create a server account (~name and password); the first sign-in with an account becomes the owner; a second browser window – ideally a private window or a second profile – is your second member. To let it in without an invitation, switch on open joining under Server in Administration. Text, voice channels, camera and screen sharing work fully between those windows.

The local test has two limits. A second device on your home network cannot take part, because it does not reach localhost and browsers release no microphone over a plain HTTP address. And a Directory account does not work here: the Directory verifies control over the domain by fetching /api/health – with localhost it ends up at itself. So sign in with a server account while testing. To clean up with 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

From the test to a real home server: as soon as friends should join, you need a domain – a free dynamic DNS name will do – and port forwardings in your router for 80/tcp, 443/tcp, 7881/tcp and 7882/udp to the machine that carries the server. Then install on a Linux machine or a Windows machine and choose the bundled Caddy: it obtains the certificate and Squorli runs exactly as it would on a rented server. If your line sits behind carrier-grade NAT (no public IPv4 address of your own), port forwarding cannot work – then only a server with a public address will do.