When we set out to build ZCP, we had two constraints: everything must be open-source, and everything must run on hardware we own end to end, no hyperscaler underneath, no reseller layer in the middle. Here is how the stack fits together.
Compute: CloudStack on KVM
Apache CloudStack is the orchestration layer. It manages VM lifecycle, networking, storage attachment, and the API powering the portal and CLI.
We chose CloudStack over OpenStack for three reasons:
- Operational simplicity. CloudStack is a single management server with a MySQL backend. OpenStack requires dozens of services, each with its own database, message queue, and failure modes.
- Proven multi-tenancy. CloudStack was designed for public cloud providers from day one. Account isolation, resource quotas, and usage metering are built in.
- Stable API surface. The CloudStack API has been stable for over a decade. We build automation against it without chasing breaking changes.
Underneath CloudStack, KVM handles virtualization. Every VM gets dedicated vCPU and RAM. No overcommit on production plans.
Storage: Ceph
Ceph is a unified storage platform. One cluster serves block, object, and shared file storage through different access protocols. This means we operate a single storage layer instead of three separate systems.
Storage classes
We run three storage classes to match performance and cost requirements:
| Class | Media | Use case |
|---|---|---|
| Fast | NVMe SSD | VM root disks, databases, latency-sensitive workloads |
| Flow | SATA SSD | General-purpose block volumes, application data |
| Bulk | HDD | Archival, backups, large datasets where throughput matters more than IOPS |
Ceph’s CRUSH rules place data on the correct media class automatically. You choose the tier when you create a volume.
Storage services
- Block storage (RBD): Persistent volumes attached directly to VMs. Available in all three storage classes. Expand online, snapshot on demand.
- Object storage (RGW): S3-compatible API for unstructured data. Works with AWS CLI, boto3, rclone, and any S3-aware tool.
- Shared file storage (CephFS): NFS and SMB file systems mounted to multiple VMs simultaneously. Useful for shared application data, media assets, and workloads needing concurrent access from multiple hosts.
Replication and durability
Triple replication means every block of data exists on three separate physical disks across at least two servers. A single disk failure or server outage does not cause data loss. Ceph self-heals. When a disk fails, the cluster re-replicates the affected data to restore the configured replica count.
Networking: OPNsense and WireGuard
Each tenant gets isolated VPC networking through CloudStack’s virtual routers. VMs within a VPC communicate on their own private segments, and traffic between VPCs is blocked by default.
At the edge of each region we run OPNsense on dedicated bare metal for firewalling, NAT, and routing, with CARP handling failover between two appliances. Cross-region traffic between our YUL-1 and YOW-1 sites rides encrypted WireGuard tunnels between those gateways. Keeping the firewalls off shared storage is deliberate; we wrote up why in Two Lessons From Running OPNsense in Production.
Public cloud customers get routable public IPs assigned directly to their VMs — inbound traffic reaches your VM directly. It is not reverse-proxied or inspected per-VM by our edge firewalls; OPNsense secures the data-center edge (routing, NAT, and failover), not your individual workloads. What reaches a VM is governed entirely by the firewall and port-forwarding rules you set per-VM and per-network in the portal or API, and everything you do not open stays closed. Because traffic terminates on your own VM, treat it like any internet-facing host: keep it patched, lock down SSH, and run tools such as fail2ban to throttle brute-force attempts and bad actors. TCPMSS clamping on the WireGuard interfaces keeps large payloads from fragmenting across the inter-region links.
Monitoring: Prometheus and Grafana
Every host, VM, and service exports metrics to Prometheus. Grafana dashboards give us real-time visibility into CPU, memory, disk I/O, and network throughput across the cluster.
Loki handles log aggregation. Alertmanager pages the on-call engineer when thresholds are breached.
This same observability stack is available to customers on the Observability service tier, running dedicated Prometheus and Grafana instances per tenant.
What this means for you
The stack is boring on purpose. These are mature, well-understood components with large communities and extensive documentation. No proprietary black boxes, no vendor-specific agents.
If you want to migrate away from ZCP, your VMs are standard QCOW2 images. Your object storage speaks S3. Your block volumes are standard disk devices. Nothing locks you in.
Open, auditable, and portable. The ZCP infrastructure philosophy.
This is the stack behind ZSoftly Cloud Platform, our sovereign Canadian cloud running on bare metal we own in Montreal (YUL-1) and Ottawa (YOW-1). If you want to run on it, or want our team to build and operate private cloud infrastructure for you, see our services and the private cloud build-out.