System Requirements

Before you plan hardware, plan assumptions. The requirements below are the operating baselines a healthy Rizoma environment is built on.

Host assumptions

Every node, gateway, and control service runs on Linux hosts with stable network reachability and administrative access for enrollment. The platform is delivered with APT, DNF, and YUM oriented packaging, systemd units, and installers — so a node joins the mesh through its package manager and runs as a first-class systemd service, with relay registration and update status handled as part of the lifecycle.

Enrolled agents need the privileges to open a TUN interface and apply routes — that is the kernel surface the mesh is built on.
Hosts should be time-synchronized; the mesh relies on signed, timestamped exchanges for replay protection and audit.
Keep agents current with the same discipline you apply to security patches — peers run better when the mesh runs one version family.

Network and DNS

The mesh addresses its own traffic inside 100.64.0.0/10 and never needs public IPs for node-to-node paths — QUIC rides UDP through most NATs, and relays cover the rest. What you do need is ownership of the DNS names you expose:

DNS ownership for every public ingress you publish, plus valid certificates for those names.
UDP reachability for QUIC between nodes (and toward relays where direct paths fail).
Firewall rules that treat 100.64.0.0/10 as a trusted internal range — nothing else should be able to impersonate it.

Sizing the addressing range

  mesh range:    100.64.0.0/10  (CGNAT space, reserved for private overlays)
  per node:      /32 assignment
  names:         <host>.rizoma.mesh   (Magic DNS, resolved inside the mesh)
  tunnel MTU:    1420
  transport:     QUIC over UDP (firewall-friendly, NAT-friendly)

Storage and state

Stateful services need isolated storage — separate from the OS, separate from other workloads, so snapshots and restores never entangle unrelated state. The coordinator keeps node records, ACLs, relay inventory, events, and snapshots in SQLite or PostgreSQL; choose PostgreSQL when you need multi-instance coordination or centralized operational tooling.

S3 storage is reachable only inside the mesh: the endpoint is the node's mesh IP on port 9000, scoped to 100.64.0.0/10, with no public DNS target and no internet-facing listener. Plan backup paths that stay inside the mesh as well — snapshot streams, not public exports.

Backups are part of requirements. A deployment that cannot restore its coordinator state is a deployment that has not started. Plan snapshot coverage before production traffic — the deployment flow covers where backups belong.

Separating control and workload

Security-sensitive environments should separate control plane services, relays, and customer workloads onto distinct hosts (or at least distinct failure domains). A relay that doubles as a customer workload host becomes both a forwarding chokepoint and an attack surface — the two roles have no business sharing a kernel.

The same logic applies to access: administrative access for enrollment should be scoped per host and rotated like any credential. When hosts are separated and access is scoped, the zero-trust policies page describes how to express that separation in policy rather than in hope.

Previous Architecture Overview Next Deployment Flow