What this is #
The LiveKit server (the suite's WebRTC SFU) as an ansible role for srv.ordner.fyi, under meet.ordner.fyi — the same container pattern the OnlyOffice role established: docker.io from Debian main, a pinned image (livekit/livekit-server:v1.13.9, the current release), the auditable compose spec at /opt/livekit/docker-compose.yml.
Layout and exposure:
- The HTTP/WebSocket API (7880) publishes loopback-only behind nginx — the media cannot pass through a reverse proxy, so the RTC transports publish publicly instead: TCP 7881 and the UDP media range 50000–50100 (101 ports, ample for a small deployment; verified free on the box).
- The API key pair is minted on the box (/opt/livekit/keys.yaml, root-only 0600) and included into the server config (livekit.yaml, 0640) — nothing in the playbook, nothing printed. The suite's backend receives the pair when it integrates.
rtc.use_external_ip: true— the node announces its public address for ICE.- The container runs hardened:
no-new-privileges, cap-drop ALL (LiveKit binds no privileged ports; if a future version needs one, the cap set is the place to extend).
The vhosts (the operator's 2026-10-14 direction):
- meet.ordner.fyi: the bare URL redirects (301) to https://srv.ordner.fyi/auth/login — there is nothing to see yet and no reason to expose the SFU's pages. The proxy block for the API/WebSocket sits in the template, commented, ready to flip when the suite's meet integration ships (websocket upgrade headers + a 3600s read timeout included).
- docs.ordner.fyi: the bare URL redirects the same way; the editor's API paths (
/coauthoring,/converter, …) keep serving — a person typing the domain lands on the login, while the integration traffic is untouched.
Idempotence/upgrades: the container is created only when absent; upgrades are a reviewed docker rm + rerun so the pinned version cannot drift.
Wiring: a new livekit tag in site-srv.yml after onlyoffice (the cert must exist first — the role asserts it).