BYOK: your backups, your bucket
Bring your own storage and your own keys. Three custody models — agent-local, zero-knowledge, and escrow — let you choose exactly how much HostSSH can ever see.
Backups are only as trustworthy as the place they're stored and the keys that protect them. HostSSH is built around a simple stance: you bring your own bucket, and you choose how much we can ever see.
Bring your own storage
Point HostSSH at the object store you already trust. Every .hsi image lands there, encrypted, in a layout you own:
| Backend | Notes |
|---|---|
| Cloudflare R2 | Zero egress fees — a great default |
| Amazon S3 | The classic |
| S3-compatible | DigitalOcean Spaces, Vultr, Wasabi, MinIO, … |
| Backblaze B2 | Inexpensive cold storage |
| SFTP / local | Air-gapped or on-prem |
Images are encrypted before they leave the host, so bucket-side encryption is redundant — your data is opaque the moment it crosses the wire.
Three custody models
The real choice isn't where the keys live — it's who can use them. Pick per connection:
agent_local— keys never leave your server. Maximum control; recovery is entirely on you.zero_knowledge— encrypted such that HostSSH can never read your images. We hold ciphertext only; we cannot assist recovery because we mathematically cannot.escrow— we hold an encrypted copy of the key so we can help you recover if you lose yours. Convenience, with a clear trust trade-off you opted into.
No connection silently changes shape. The custody model is explicit, enforced, and shown in the dashboard.
Retention you control
House policy is keep-all — HostSSH never deletes an image unless you tell it to. When you want pruning, set it explicitly:
keep_last— the number of recent images to keep before deletion- daily / weekly / monthly tiers (grandfather-father-son)
- a minimum free-space floor so a runaway schedule can't fill the disk
Pinned images and legal holds are never pruned. Your backups, your bucket, your rules — and an exit that's always open.