Deployment Flow

A new Rizoma environment comes online in a fixed order. Skip a step and the next one gets harder; follow it and each stage verifies the last.

Prepare DNS and certificates

Decide what the environment will expose publicly before any node joins. Pick the ingress names, point their DNS records, and stage certificates. Public ingress is the only part of the mesh that touches the open internet — everything else stays inside 100.64.0.0/10.

Create the mesh authority

Stand up the coordinator and initialize the MeshCA trust root. Every identity in the environment — nodes, peers, relays, product services — will be issued from this root, so it is the crown jewel of the deployment: keep its keys off shared hosts and back up its state before enrolling anything. Generate a setup key for the first enrollment wave and issue node tokens from the coordinator.

Representative enrollment preparation

  # coordinator: create setup key for the first wave
  coordinator setup-key create --name first-wave --limit 8

  # agent: enroll against the coordinator, receive identity
  agent enroll --coordinator <coordinator-host> --setup-key <key>
  #   &lt;- mesh IP, node token, certificates

Enroll the first nodes

The enrollment loop is: the agent calls /v1/enroll and receives its mesh IP, token, and certificates; from then on its heartbeat publishes endpoints, E2E key material, telemetry, and command results; the coordinator returns peers, relay selection, ACL sync, and ingress assignments. Enroll the control plane hosts first, verify their heartbeats, then add product hosts.

Enrollment exchange (shape)

  agent -> POST /v1/enroll           # identity + setup key
  agent &lt;- mesh IP (100.64.0.0/10)   # token, certificates
  agent -> heartbeat                 # endpoints, E2E key, telemetry, command results
  agent &lt;- peers, relay selection    # ACL sync, ingress assignments

Publish minimal ACL policy

Before opening traffic between workloads, publish the smallest policy that makes the environment usable: which teams see which node groups, which methods each role may call, and what the firewall compiles to. Start deny-by-default and add narrow grants as services prove they need them — the zero-trust policies page walks through the pattern.

Add product services

With nodes enrolled and policy published, attach product services: Webpanel for hosting workloads, S3 for object storage (endpoint: the node's mesh IP, port 9000), Rizoma Git for developer workflows, and Rizoma Router where the environment needs a security gateway. Each service binds to mesh identity — no public listeners are created unless you deliberately publish one through ingress.

Verifying a service inside the mesh

  # from any enrolled host, the S3 endpoint resolves inside the mesh
  curl http://s3-node.rizoma.mesh:9000/healthz

  # Webpanel health endpoints
  curl http://panel-node.rizoma.mesh:8080/healthz
  curl http://panel-node.rizoma.mesh:8080/readyz

Verify, back up, then open traffic

Before production traffic moves: check telemetry and health from agents, coordinator, relay, ingress, and dashboard; confirm Prometheus metrics are flowing; take the first snapshot of coordinator state and test a restore. Only then open the ingress you prepared in step one. Revisit post-quantum key policy before the environment carries anything you would not want to explain to a customer later.

First production check. Run the certification path for operators as a dry run of your own deployment knowledge: the Operator certification covers exactly the sequence above.

Previous System Requirements Next Post-Quantum Key Policy