Canton Network validators can be deployed using Docker Compose or Kubernetes with Helm charts. Your choice depends on the target environment, operational maturity, and scale requirements.Documentation Index
Fetch the complete documentation index at: https://docs.canton.network/llms.txt
Use this file to discover all available pages before exploring further.
Docker Compose
Docker Compose is the simplest path to running a validator. It packages all components into a single-host deployment managed by a shell script. When to use Docker Compose:- LocalNet and DevNet development
- Proof-of-concept and integration testing
- Small-scale deployments without high-availability requirements
- Teams without Kubernetes expertise
- Single
start.sh/stop.shworkflow - Pre-configured compose files in the Splice node bundle
- Local Traefik reverse proxy for UI routing
- Systemd integration for process management
- Runs on a single host — no built-in high availability
- Manual scaling and failover
- Not recommended for production MainNet deployments
- Database runs in-container unless you configure an external PostgreSQL instance
Kubernetes with Helm
Kubernetes is the recommended deployment method for TestNet and MainNet. Helm charts provide parameterized configuration for all validator components. When to use Kubernetes:- TestNet and MainNet production deployments
- Environments requiring high availability and automated failover
- Organizations with existing Kubernetes infrastructure
- Deployments needing managed database services (RDS, Cloud SQL, Azure Database)
- Helm charts for validator, participant, wallet UI, and CNS UI
- Managed rolling upgrades via
helm upgrade - Integration with cloud-native services (managed databases, KMS, monitoring)
- Ingress controller support for TLS termination and routing
- Scalable and reproducible across environments
- Kubernetes 1.27 or newer
- Helm 3.11.1 or newer
- An ingress controller (NGINX, Traefik, or cloud-native)
- External PostgreSQL (managed or self-hosted, not in-container for production)
Cloud provider considerations
All three major cloud providers support validator deployments. The primary differences are in managed service names. AWS:- EKS for Kubernetes, RDS or Aurora for PostgreSQL
- NAT Gateway for static egress IP
- AWS KMS for key management (community edition)
- gp3 EBS volumes for storage
- GKE for Kubernetes, Cloud SQL for PostgreSQL
- Cloud NAT for static egress IP
- Cloud KMS for key management (community edition)
- SSD persistent disks for storage
- AKS for Kubernetes, Azure Database for PostgreSQL
- NAT Gateway for static egress IP
- Premium SSD for storage
Choosing between options
For most teams, the decision comes down to environment and operational capacity:- Starting out or testing on DevNet — Use Docker Compose. It gets you running in minutes with minimal infrastructure.
- Moving to TestNet — Either option works. Docker Compose is acceptable if you do not need high availability. Kubernetes is preferred if you want the same deployment method you will use in production.
- MainNet production — Use Kubernetes. The operational tooling (rolling upgrades, health checks, autoscaling) is necessary for a production validator that must maintain high availability.
You can start with Docker Compose on DevNet and migrate to Kubernetes for TestNet/MainNet. The validator state lives in PostgreSQL, and the onboarding identity persists across deployments as long as you retain the database.
Super Validator deployments
Super Validators must use Kubernetes. The additional components (CometBFT node, sequencer, mediator, SV app, Scan service) require orchestration that Docker Compose does not support at production scale. See the Kubernetes Deployment guide.Next steps
Prerequisites
System requirements for your chosen deployment method.
Docker Compose validator deployment
Step-by-step Docker Compose validator deployment.
Kubernetes validator deployment
Step-by-step Kubernetes validator deployment with Helm charts.