Choosing your storage custody: agent-local, zero-knowledge, or escrow

Every backup system answers two questions at once: how do I get my data back, and who else can read it on the way? Most hosting platforms answer the first one and quietly skip the second. HostSSH treats that second question as a setting you own — bring your own bucket, then choose exactly how much the control plane can ever see.

Bring your own bucket is the floor, not the feature

The backups, clones, and full-server relocation images HostSSH produces all land in object storage you control — Cloudflare R2, AWS S3, or anything that speaks the S3 API. The credentials are yours. The lifecycle rules are yours. The bill is yours. If you ever walk away from HostSSH, the encrypted images are still sitting in your account, and you still hold the keys to open them.

That is the baseline, and it matters, but it is not the whole story. "Your bucket" tells you where the bytes live. It does not tell you who can decrypt them. A control plane that holds your storage keys and your encryption keys can technically read everything in your bucket whenever it wants — the fact that the bucket has your name on the invoice is cold comfort.

So the real design question is custody of the keys, not custody of the bytes. HostSSH exposes that as an explicit choice with three models: agent-local, zero-knowledge, and escrow. Each one slides you along a single axis — how much recoverability you trade for how little the control plane can see.

The trade-off you are actually making

There is no free lunch here, and any vendor that tells you otherwise is hiding the bill. The core tension:

• The more the control plane can see, the more it can do for you automatically — restore a dead box at 3 a.m., relocate a server while you sleep, verify a backup actually decrypts.
• The less the control plane can see, the more the burden of key custody falls on you — and the more catastrophic it is if you lose the key.

Zero-knowledge and "click to restore" are in direct opposition. Pick where you want to sit on that line per workload, not as one blanket policy. A throwaway staging box and your customer database do not deserve the same answer.

Model 1 — agent-local: keys live on the box

In the agent-local model, the encryption key is generated and held by the HostSSH agent on your server. Backups are encrypted on the box before they ever leave it, then streamed to your bucket. The control plane orchestrates the schedule and tracks the manifest, but the key material stays local to the agent.

This is the pragmatic default for most fleets. The data is encrypted in transit and at rest in your bucket, and the plaintext only ever exists on a machine you already trust with that plaintext anyway — it is the server running the workload.

What you get: smooth automated restores and relocations, because the agent that holds the key is the same component doing the work.

What you give up: if the box is fully destroyed and you have not exported the key elsewhere, the backups in your bucket are encrypted bricks. Agent-local custody means you must treat the key as a first-class artifact to back up separately — ideally somewhere offline. A backup you cannot decrypt is not a backup.

This model fits teams who want strong encryption without becoming full-time key custodians, and who accept that "protect the agent key" is now a line item in their runbook.

Model 2 — zero-knowledge: the control plane never holds the key

Zero-knowledge is the strict end of the spectrum. You hold the encryption key. The control plane never receives it, never stores it, and is architecturally unable to decrypt your images. Data is encrypted with a key derived from a secret only you possess; the control plane sees ciphertext, manifests, and metadata, and nothing more.

This is the model to reach for when the threat you care about includes the platform itself — regulatory data residency, client confidentiality contracts, or simply the principle that your exit should not depend on anyone's good behavior. "Your data, your bucket, your exit" reaches its full meaning here: even a fully compromised or subpoenaed control plane yields nothing readable.

The cost is real and you should respect it

Zero-knowledge moves the entire burden of key custody onto you, with no safety net:

• Lose the key and the data is gone. Permanently. There is no reset link, because a reset link would defeat the entire model.
• Automated restore becomes a key-supply step. The control plane can stage and orchestrate, but the actual decrypt happens with a key you provide at recovery time.
• Some convenience features that require reading content — for example, server-side verification that an image decrypts cleanly — are necessarily limited, because the only party who can decrypt is you.

Zero-knowledge is not "more secure, same convenience." It is a deliberate trade: maximum confidentiality, maximum personal responsibility. Choose it where the data warrants it, and pair it with a serious key-management practice — a hardware token, a password manager you trust, a documented rotation and recovery drill.

Model 3 — escrow: a sealed middle path

Escrow exists for the very common situation where pure zero-knowledge is too brittle for the team but agent-local is too coupled to a single box. The idea: your key is held, but under seal — encrypted to a recovery key, split, or wrapped so that the control plane cannot use it during normal operation, only release it under conditions you define.

Think of it as a sealed envelope rather than an open ledger. Day to day, the control plane operates as if it cannot read your data, because it cannot. But there is a defined, auditable break-glass procedure for the disaster case — the laptop with the only key copy went into a river, the engineer who held it left, the box and the offline backup both died.

Escrow is the answer to the question that kills naive zero-knowledge deployments: what happens when the one person who held the key is unavailable? It buys you organizational resilience without handing the control plane a standing ability to read your fleet.

The trade-off here is trust placement. You are trusting the escrow mechanism — its split-key or wrapping scheme, its release conditions, its audit trail — instead of trusting either a single key-holder or the bare control plane. For teams, that is often the most honest model: it matches how responsibility actually works in an organization, where no single person should be a single point of failure.

How to choose

A rough mapping, not a rule:

• Agent-local — most workloads, solo operators and small teams who want strong defaults without heavy key ceremony. Just remember to export the key off the box.
• Zero-knowledge — your most sensitive data, regulated workloads, anything where "the platform cannot read this, by construction" is a requirement you can put in writing.
• Escrow — teams who need confidentiality and a recovery story that survives a person leaving, a laptop dying, or a bus.

You do not have to pick one forever, and you do not have to pick the same one for everything. The point of making custody an explicit setting is that it stays yours to revisit as the data, the team, and the risk change. Decide deliberately, write down where the keys live, and rehearse getting your data back before you need to — the model you chose only matters on the day you actually restore.