Self-Host
Run your workers, the control plane, or both on your own infrastructure.
Self-Host vs BYOC
Rivet provides two deployment models.
Self-Host: You manage the complete stack, including your workers, the control plane, and storage. This has higher complexity but enables air-gapped deployments and custom security policies.
BYOC with Rivet Cloud: You only manage your workers while Rivet Cloud runs the control plane and storage. This typically has lower operational overhead and supports serverless workers.
| Self-Host | BYOC with Rivet Cloud | |
|---|---|---|
| You manage | Workers, control plane, and storage | Workers only |
| Complexity | Higher | Lower |
| Cost | Higher operational overhead | Usually lower usage-based cost |
| Serverless workers | Requires the extra control plane infrastructure | Yes |
| Air-gapped deployments | Yes | No |
| Best for | Air-gapped environments, strict compliance, custom security policies | All other production deployments |
| Support | Contact sales or community | Community, Slack, and email, varying by plan |
Rivet runs the control plane for you at dashboard.rivet.dev. Running your own workers against it is BYOC, documented in the Workers section.
Architecture
Rivet has 3 core components:
- Worker: A process running your code with the Rivet SDK. It connects outbound to the control plane, so it never needs a public URL or an inbound firewall rule.
- Control plane: The orchestration service that manages actor lifecycle, routes messages, and serves the API.
- Storage: The persistence layer for actor state and the messaging infrastructure for real-time communication.
Storage backends
- File system: Recommended for single-node deployments
- PostgreSQL: Recommended for multi-node deployments; production-ready for light-to-moderate workloads, not built for enterprise scale
- FoundationDB: Best scalability and performance for production deployments (requires enterprise)
See Storage for configuration.