PowerCloudHow it works
One cloud, made of machines you don't have to trust
Nodes you trust hold the keys and run your apps: your own hardware, or a confidential VM that has proved it. Everything else, from object storage buckets to plain cloud VMs, only ever stores ciphertext.
Getting started
From nothing to a cluster
- Step 1
Create a cluster
pcctl init makes a random root key, wraps it with your passphrase and a one-time recovery key, and writes the encrypted cluster header to every storage location you name.
- Step 2
Boot nodes
Write the image to a disk or upload it as a cloud image. A node shows a one-time enrollment code on its console, or joins on its own from a join bundle given as cloud user data.
- Step 3
They find each other
Enrolled nodes get a CA-signed membership list, form a WireGuard mesh, and work out how to reach each other through NATs, or through a relay.
- Step 4
Store and run
Put data into the encrypted store, and deploy apps the nodes place among themselves, moving them when a node goes away.
pcctl --repo ./home,./colo,./cloud init # prints a one-time recovery key
pcctl --repo ./home,./colo,./cloud node provision web-1 web-1.join
# start a cloud VM with it as user data
pcctl status # every node at a glance
pcctl cluster app deploy --replicas 2 --image nginx:alpine siteNetwork
WireGuard mesh
WorkingNodes talk over kernel WireGuard, with IPv6 addresses derived from each node's identity. Peers are distributed by a membership list signed by the cluster CA and passed from node to node, with mutual TLS inside the tunnel.
NAT traversal and relays
WorkingTwo nodes behind NAT find each other's public address through a third node and connect directly. When their NATs block that, they relay through a public node, and switch to a direct path once the network allows it.
Storage
Encrypted, deduplicating store
WorkingObjects are split into chunks sealed with XChaCha20-Poly1305 and bound to their IDs, so a provider can't swap or alter them. Names, sizes and chunk lists live in encrypted manifests.
Any mix of locations
WorkingLocal disks, your own nodes, and S3-compatible buckets on AWS S3, Cloudflare R2, Backblaze B2, Wasabi or MinIO, mixed freely, with a write quorum. check, repair and gc keep them in step.
Erasure coding
WorkingSplit each blob into 4 data and 2 parity shards over six providers: any two can disappear, at 1.5× the data instead of 3× for replicas. Lost shards rebuild themselves.
Rollback protection
WorkingA provider that serves an older, authentic version of an object, or drops it, is caught against high-water marks kept in the nodes' consensus.
Nodes
Encrypted state volume
WorkingA node's identity and state live on dm-crypt with an HMAC-SHA256 tag on every sector, so a disk changed while the node was off reads as an error, not as altered data. After a reboot the node stays locked until an admin unlocks it.
Secure Boot and TPM unlock
WorkingSign images with your own key, so the firmware boots only those. With a TPM 2.0, a node unlocks itself at boot, but only on the same machine with the same Secure Boot keys.
Attested unlock on SEV-SNP
WorkingOn an AMD SEV-SNP VM, pcctl checks the chip's attestation, chained to AMD's root and bound to the node's key, before it sends a volume key, and requires it from then on.
Unattended join
WorkingIssue a node's identity ahead of time as a join bundle. A cloud VM given it as user data on AWS, Google Cloud or Azure, or a QEMU, libvirt or Proxmox VM given it as a fw_cfg file, comes up enrolled.
A/B upgrades and signed releases
WorkingA node boots a new image once on trial and keeps it only once pcctl reaches it there. Publish a CA-signed release and nodes roll it out one at a time, stopping at the first node it fails on.
Revocation, renewal and key rotation
WorkingRemove a node and its certificate is revoked on every node, with an optional crypto-erase. Certificates renew, even expired ones. After a leaked passphrase, pcctl rotate replaces the root key and re-encrypts the store.
Cluster
Sandboxed apps
WorkingRun static binaries or container images from public or private registries. Each runs chrooted on the encrypted disk, as its own user, in its own PID namespace and cgroup with limits, under seccomp, with a network reached only through ports it publishes.
Cluster apps with failover
WorkingThe nodes place apps among themselves within each node's memory, start them elsewhere when a node goes away, and catch up from their peers when it comes back.
Consensus
WorkingThe nodes form a Raft group that keeps state they agree on while a majority is up, with logs on their encrypted disks and linearizable reads.
Exclusive apps with fencing
WorkingAn exclusive app runs on at most one node at a time. A node runs it only while its copy of the agreed state was confirmed current in the last 15 seconds, so a node cut off from the majority stops it on its own.
App storage and volumes
WorkingGive an app an S3 endpoint over the cluster's encrypted, replicated storage, or let an exclusive app's data directory follow it from node to node.
Not yet
Planned, and labelled as such
These are on the roadmap and aren't built. The roadmap has the full list.
Peer unlock
Plannedk-of-n Shamir shares of the key held by peer nodes, so a node unlocks itself only while enough of its peers agree, and a node stolen or imaged alone can't.
Intel TDX and Arm CCA
PlannedAttested unlock on the other two kinds of confidential VM. Today only AMD SEV-SNP is supported.
Google Cloud and Azure boots
PlannedThe image formats are built; booting them on those clouds hasn't been tried yet. AWS works today, on x86 and Graviton.
MicroVMs, an S3 gateway and a web console
PlannedApps in microVMs, a cluster-wide S3-compatible gateway, and a console in the browser.
What it protects, and what's next
The security model says what each part defends against and where the limits are; the roadmap says what's built and what's planned. PowerCloud has no builds to download yet.