Control Plane
What you run to self-host Rivet: control plane instances, a bucket, a disk per instance, and your nodes.
Self-hosting Rivet means running four things on your own infrastructure:
| Part | What it is | How many |
|---|---|---|
| Control plane instance | The rivetdev/engine image. Every instance is identical and runs every service. | 1 to try Rivet, 3 or more in production |
| Disk | A persistent local disk for each instance. It holds recent writes and the instance’s identity. | One per instance, never shared |
| Bucket | An object storage bucket (S3, S3-compatible, Google Cloud Storage or Azure Blob Storage). It holds the durable copy of every Rivet Actor’s data. | One per cluster |
| Nodes | Your app, running the Rivet SDK. Nodes connect out to the control plane and host your Rivet Actors. | As many as you need |
There is no database to run and no message bus. Control plane instances find each other through the bucket.
Nodes reach the control plane on port 6420, usually through a load balancer. Instances also talk to each other on port 6421, which stays on your private network. See Ports & TLS.
Each Rivet Actor’s data is replicated across the disks of several instances as soon as it is written, then moved to the bucket in the background. Losing one instance loses no data. See Storage.
The control plane runs in one region. Multi-region self-hosting is coming. See Multi-Region.
Picking a guide
| If you want | Use |
|---|---|
| A single instance to try Rivet | Docker Compose |
| A production cluster | Kubernetes |
| Linux hosts you already own | VM & bare metal |
| Hetzner Cloud | Hetzner |
| A single instance on a managed platform | Railway or Render |
| AWS | AWS ECS |
| Anything else | Custom platform |
| Run your app against the control plane | Nodes |
For the lowest latency, use the VM & bare metal or Hetzner guide on machines with local NVMe disks. Kubernetes pods do not get raw NVMe. See Benchmarking.