SimpleTwo

One private network, and every rule is explicit. All the hosts share it: postgres, messaging and calendar on one side of it, redis and the livekit nodes on the other, and nothing between them but rules this control plane writes. The database accepts only the messaging and calendar hosts, each as a /32 in pg_hba; the bus accepts only the services that dial it — the SFU nodes, the SIP bridge, the recorder — as a firewall rule on its own host. Both are re-applied on every state poll, so neither is a rule somebody has to remember to keep true.

The one rule that silently breaks calls. A private address must never be advertised to clients. “Private address” goes in the host’s private address field; the address clients use goes in node IP for an SFU. Put a private address in the second one and every call connects, carries no media and times out with nothing in any log.

Order. 1) postgres → 2) messaging → 3) calendar (then redeploy postgres once: the access rules are narrowed to those hosts’ /32 and cannot be written before the hosts exist — one redeploy covers both) → 4) redis → 5) livekit node A → 6) livekit node B → 7) turn. Calendar is optional and can wait; until a calendar host exists the clients hide their calendar screens rather than offering buttons that fail, which is the honest answer for a deployment that has not stood one up. A second SFU node without redis is refused: two nodes without the bus each keep their own room table, so two people “in the same room” on different nodes cannot see each other and nothing reports a problem.

Sizing to start. postgres 2 vCPU / 4 GB / 40 GB SSD · messaging 2 vCPU / 4 GB (attachments live on its disk until S3 exists) · redis 1 vCPU / 1 GB (it holds room routing, not data) · each livekit 4 vCPU / 8 GB and real bandwidth — an SFU forwards every stream to every participant, so the uplink is the limit long before CPU · turn 2 vCPU / 2 GB, bandwidth-bound for the same reason · egress 4 vCPU / 4 GB per concurrent recording plus scratch disk — the one media role limited by CPU rather than bandwidth, since it records by driving a headless Chrome. It scales with recordings, not participants, and takes its jobs from the bus, so one worker serves the whole pool: put it on an SFU host for a small install and on its own machine once recording is routine · calendar 2 vCPU / 4 GB — it holds no files, and its whole working set is rows in postgres; sized for the polling rather than for the people, since a subscribed Outlook and a CalDAV client come back on their own schedule whether anybody is looking or not · support 1 vCPU / 2 GB / 10 GB — two small Go daemons plus the knowledge base, which is held in memory (a repository the size of this one is ~6k chunks ≈ 100 MB with embeddings, and its file on disk is the same order); searches are index-backed and answer in under a millisecond, so the single core is the model provider's problem, not ours. The thinking happens provider-side, so nothing here grows with chat load the way media hosts do. Deploy it last: it needs messaging live and the Support provisioning (Settings) run, in either order.

Ports the deploy opens for you (host firewall, when ufw or firewalld is present): livekit 7880/tcp, 7881/tcp, 50000-60000/udp · turn 3478/udp+tcp and 49152-65535/udp · messaging its listen port, plus 443 when it terminates its own TLS · calendar its listen port (:8085 by default). Redis is the exception: 6379 is opened only to the addresses that dial the bus — the SFU nodes, mediation, egress — never to the world, and on a host with no firewall tooling the deploy fails rather than leave a database reachable. With one private network that rule is the only boundary the bus has, so it fails whatever address the bus listens on.

Certificates. messaging obtains its own (autocert) for the hostname you set under Settings. Calendar does the same, and for the same reason it is allowed to: it is our own Go service, so it can run ACME itself. An SFU cannot — that is the whole reason edge exists — and the difference is worth knowing when a role seems to be missing a certificate button. Subscription links are built from the calendar's name, so it must already resolve to the host before the certificate can be issued. An SFU needs TLS in front of 7880 for iOS to connect at all, and an enrolled host no longer needs you to arrange that: the coordinator runs the ACME order and the host serves the one challenge file, because the name points at the host while the account key stays here. The edge front then terminates 443 and proxies every path to 7880 — every path, since moderation arrives on the same host and port as the client’s WebSocket, and a front that forwards only the socket breaks mute and remove while calls still look fine.