For operators

Host operator guide

Prepare a Linux host for Sibrel: email, S3, LiveKit, HTTPS, backups, updates and federation limitations.

Checked against the project: 2026-10-15 · Support: support@sibrel.net

Before installation

  • Prepare a Linux server, administrative access, a domain and DNS.
  • Identify the operator and support contact; define registration and data handling rules.
  • Prepare SMTP or an authorized Sibrel mail gateway. Registration verification needs working email.
  • Choose S3-compatible storage: local MinIO or an external bucket.
  • Choose local or separate LiveKit for calls.
  • Allow the required ports in the server and provider firewalls.

Installation and readiness

Use the host management wizard in a compatible app or panel version. It asks for SSH access, email, storage and media settings. Allow it to modify only machines intended for Sibrel.

After installation, test GET /api/host/readiness, registration with email, file uploads and downloads, a call between two external networks and a bot connection. A successful HTTP response alone does not verify call quality.

Proxy and Gateway

The reverse proxy must forward WebSocket Upgrade for /api/bots/gateway and client sockets. Do not log the token query parameter in access logs. Renew certificates automatically and monitor their expiry.

Choose LiveKit and TURN ports for your configuration. Separate S3 and media nodes must be reachable from the relevant servers and client networks.

Backups and updates

  • Back up PostgreSQL, object storage, configuration and federation keys to a protected location.
  • Set retention and a backup schedule; regularly test restoration on a separate machine.
  • Before updating, check migrations and client compatibility, and take a backup.
  • Updating wizard-installed hosts may stop the app. Warn users beforehand.
  • A database backup during an update does not mean the database will automatically roll back on every failure.
  • Protect SSH, service secrets and backups against unauthorized access.

Moving services and adding nodes

Additional S3 nodes distribute new uploads but do not replicate old files. Rooms are assigned to media nodes; removing a node from configuration does not migrate existing rooms.

When changing addresses and buckets, preserve access to old objects. File migration, DNS changes and decommissioning old machines are separate tasks. An infrastructure diagram is not proof of successful migration.

Federation and rules

Connect only known hosts with verified keys. Monitor version compatibility, network routes and replay handling. Relay is not a guaranteed queue and does not automatically improve media.

Operators are responsible for their hosts and users within their authority. Read the host creation and use rules and publish your own data handling information.

Registration and access

The host administrator can close public registration and create accounts manually in the admin panel. This setting applies to that host. Apply database migrations, keep a backup and check existing users can sign in before completing a server update.