Costs and sizing

This page helps you work out how big your nodes need to be, how much storage your data takes once it is replicated or erasure-coded, and what a deployment costs each month. The key idea is that only trusted nodes need expensive machines: storage locations and relays only ever hold ciphertext, so they can be the cheapest option that meets your durability needs. For the designs referred to here, see Deployment designs.

Sizing a node

What the node keeps for itself

A node runs from RAM (its root filesystem is the initramfs built into its image) and keeps its state on an encrypted disk. When the nodes place cluster apps, each node offers its apps what is left after a reserve for itself:

• Memory: the node's RAM less the larger of 256 MiB and one eighth.
• CPU: the node's CPUs less the larger of a quarter of a CPU and one eighth.

The reserve is what placement sets aside, not a measurement of what the node uses. The smallest machines PowerCloud is checked on in automated tests have 1 GiB of memory: AWS t3.micro (x86) and t4g.micro (Graviton), and 1 GiB, 2-CPU virtual machines for the emulated tests. A node with no apps, used only to hold a storage replica or to relay, fits on machines of that size.

What each app takes

An app's memory limit (--mem, default 256 MiB, no swap) and CPU cap (--cpu, default none) are what placement counts, on every node the app runs on. Placement counts limits, not use, and an app without --cpu takes no CPU in placement and shares what is left over. So:

• Add up the --mem of every app a node may run. With failover, a node must also have room for the apps of a peer that goes away, or those apps run nowhere until it returns (pcctl status reports them).
• Exclusive apps are placed first; the others follow in name order.
• Apps deployed by hand with pcctl app deploy are not counted by placement. Leave room for them yourself.

pcctl app deploy --mem 128M --cpu 0.5 home-1 web ./web
pcctl --repo ... cluster app deploy --replicas 2 --mem 512M --cpu 1 --image nginx:alpine --port 80:80 site

See Apps on a node and Cluster apps.

MicroVM apps

An app deployed with --vm runs under a kernel of its own:

• Placement counts it at its memory limit plus 96 MiB.
• The cgroup's limit covers the guest's memory (the app's limit, its files and the guest kernel's 64 MiB) and the monitor's.
• The guest's root is in its memory, so the app's files count against it: images of a few hundred MiB are fine, multi-GiB ones are not (2 GiB at most).
• It gets one vCPU for each CPU of its --cpu limit, rounded up (--cpu 1.5 gives two), or one per node CPU, up to 32, without a limit.

MicroVMs need hardware virtualisation on the node: bare metal, or a VM with nested virtualisation. Most cloud VMs don't offer it (on AWS, .metal instances do), so microVM apps are cheapest on hardware you own.

Disk

• The disk image is 1 GiB by default: a 256 MiB EFI system partition holding the signed kernel, and the state partition. A fresh image is about 15 MiB of data. Give the machine a disk of any size: the state partition, the encrypted volume and its filesystem grow to fill it, and grow again on the next boot after you enlarge a cloud disk.
• Integrity tags take about a tenth of the disk. New state volumes store an HMAC-SHA256 tag for every sector.
• Writes cost about double. The integrity journal writes data twice. That is fine for node state and replicas, but not tuned for heavy write loads.
• A replica keeps 256 MiB free. A node:// write that would leave less is refused, so a full replica never starves the node's own state.
• Apps' data and logs live on the state volume. Logs rotate at 1 MiB.

For a node that holds a node:// replica, budget the replica's share of the data (see below), plus a tenth for tags, plus the apps' data.

Sizing storage

Objects are split into fixed 4 MiB chunks, each encrypted with a few tens of bytes of overhead, plus an encrypted manifest per object. How much you store in total depends on how the locations are combined:

With erasure coding, each location holds one shard of every blob: at 4+2, the shards of a 4 MiB chunk are 1 MiB each, so each of six locations holds a quarter of the data. 1 TiB at ec:4: over six locations is 256 GiB per location and 1.5 TiB in all, against 3 TiB for three replicas.

• Deduplication. A chunk's ID is a keyed MAC of its contents, so identical chunks are stored once: the same file stored twice, or the unchanged 4 MiB pieces of a file overwritten in place. Because chunks are fixed-size, inserting bytes near the start of a file changes the chunks after it. App storage, app volumes and the S3 gateway each have their own keys and namespace, so they don't deduplicate against each other or the cluster's own objects.
• Small objects. Each object is at least one chunk and one manifest, so many small files cost more in requests than their size suggests.
• Deleted data costs until GC. pcctl gc deletes a chunk only after it has been unreferenced for the grace period (default 24 hours) across two runs, and only when every location is reachable. Overwritten versions and deleted objects keep using space until then. Deletes leave small tombstones that are kept for good. App storage and app volumes are reclaimed by nodes serving storage during their sync (hourly by default), also with a 24-hour grace.

See Storage and Use cases with the Unidatum Data Engine.

Network

Traffic to plan for:

• Replication is egress. Every write is sent to each location: with replicas, the whole object to each; with erasure coding, one shard to each, n/k times the data in all. Writes from a cloud VM to buckets on other providers leave that cloud once per provider.
• Reads, restores and checks are egress from the provider. Restoring after losing a site, pcctl repair after adding a location, and pcctl check --verify (which downloads every copy of every chunk) all pull data out of providers.
• Relayed traffic passes through the relay. The relay receives and sends every packet of a relayed pair, so its provider bills that traffic. Pairs try a direct path again every 10 minutes, then more rarely.
• Background traffic is small but constant. Every node checks each peer every 5 seconds over the mesh, and the consensus leader sends heartbeats.

Cloud costs

Confidential VMs for trusted nodes

A trusted node on someone else's hardware needs a confidential VM, because the host can otherwise read the VM's memory and the keys in it. PowerCloud verifies attestation on AMD SEV-SNP. Prices checked on 2026-10-24, on-demand, USD, Linux, compute only, 730 hours a month. Prices change; check them again before you commit to a budget.

• Confidential VMs cost about 10% more than the same plain VM on all three clouds. Some Azure sizes (the v5 DCas and ECas series above) cost the same.
• How the premium is charged differs. AWS adds 10% of the instance's on-demand rate, and Reserved Instances and Savings Plans don't reduce that fee. Google Cloud adds a surcharge per vCPU-hour and per GiB-hour, so memory counts. Azure sells confidential sizes at their own prices.
• Use SEV-SNP, not plain AMD SEV. Plain SEV lacks SNP's memory integrity protection; on Google Cloud it is also the dearest option, about 20% extra.
• Not included: disks, public IPs, taxes, network egress and object storage.

What has been run on each cloud matters as much as the price:

• AWS: images boot on x86 and Graviton. SEV-SNP attested unlock has been run on a c6a.large. AWS offers SEV-SNP on shared tenancy only in US East (Ohio) and Europe (Ireland), and it can't be turned on after launch.
• Google Cloud and Azure: each release carries images for both, with upload scripts, but they have not been booted on either cloud yet.
• Intel TDX sizes (Google Cloud C3, Azure DCesv6 and ECesv6) cost about the same premium, but TDX attestation is not built yet. Treat their prices as planning figures only. See Roadmap.

Object storage

Bucket costs depend on three things, which vary a lot between providers: the price per GB stored each month, the price of each request (PUT, GET, LIST), and the price of data leaving the provider (egress). For PowerCloud:

• Storage is the stored total from the layout table above, split across providers.
• Requests come from every chunk and manifest written, the hourly sync of each node serving storage (which lists every location), app volumes (saved every 30 seconds while files change), and check, repair and gc.
• Egress comes from reads, restores, repair and check --verify. Providers with free or cheap egress make good replication targets.

Check each provider's current price list; no bucket prices are quoted here.

Worked examples

Compute prices are the on-demand figures above, checked on 2026-10-24. Storage is shown as the amount billed, since bucket prices vary by provider.

Home server with two buckets (design 1)

Cloud compute: $0. Egress is small day to day, and a full restore pulls 500 GiB out of one provider.

Home first, one confidential VM off-site (designs 1 and 2)

About $62 to $73 a month in compute for the clouds' 2 vCPU, 8 GiB confidential sizes; the AWS c6a.large (2 vCPU, 4 GiB), the size SEV-SNP unlock has been run on, is $61.43. Two trusted nodes give a second site, but consensus needs a third node to survive losing either.

Three clouds, one SEV-SNP node on each (design 3)

Losing any one provider leaves two trusted nodes and a consensus majority. Only the AWS part has been run today. Committed-use discounts can lower this a lot on Google Cloud and Azure; on AWS they lower the instance but not the SEV-SNP fee. Egress between the three clouds comes on top and, for write-heavy use, can exceed compute.

Storage only (design 6)

No compute. 1 TiB at ec:4: over six buckets is 1.5 TiB billed, 256 GiB with each provider, against 3 TiB for three replicas.

How to spend less

• Keep untrusted roles cheap. Buckets and plain VMs only see ciphertext. Use the cheapest tier that meets your durability needs for storage, and a small plain VM for a relay or a node:// replica. Don't run cluster apps on plain VMs: name the allowed nodes with --nodes.
• Run trusted nodes on hardware you own. A home or office server, or bare metal in a colo, costs no confidential-VM premium and can run microVM apps.
• Use arm64 where it fits. Images boot on arm64 machines and AWS Graviton. Arm cloud VMs are plain VMs to PowerCloud (Arm CCA attestation is not built), so use them for untrusted roles, or as trusted nodes only on your own hardware.
• Prefer erasure coding over many replicas once you spread over four or more providers.
• Pick replication targets with cheap egress, and avoid check --verify more often than you need it.
• Discounts. Google Cloud and Azure committed-use discounts and reservations apply to confidential VMs. On AWS the SEV-SNP fee stays 10% of the on-demand rate whatever you pay for the instance. Spot capacity is cheaper but can be reclaimed at any time, which suits replicas and relays better than trusted nodes.
• Right-size apps. Placement counts --mem limits, not use, so generous limits leave nodes looking full.