Get early access
Features · Security & Backup · Offsite Backups
Security & Backup · Offsite Backups

Encrypted on your host,
before it leaves.

AES-256-GCM encryption client-side, with a key the platform never sees. Stored on Hetzner S3 (EU). Ransomware-gate refuses to accept high-entropy uploads. Zero-knowledge restore.

offsite · nightly
encryption AES-256-GCM, client-side key never leaves your host destination Hetzner S3 · EU last run 333 MiB in 4m54s ransomware gate passed · 0.0% suspicious
— Why this matters

An offsite copy you cannot read is not a backup.

01

Zero-knowledge, or it does not count.

The key is generated on your agent and never leaves your infrastructure. We hold ciphertext and cannot decrypt it — which also means we cannot leak it.

02

The backup after the ransomware is the dangerous one.

It overwrites your last good copy with encrypted rubbish. The entropy gate refuses to upload a backup that looks encrypted by someone else.

03

Uploads should not route through us.

The agent talks to object storage directly with presigned URLs. Your data never passes through our API, and a 200 GB upload is not our bandwidth problem.

— What's included

What actually happens at 03:00.

AES-256-GCM, client-side
Chunked at 4 MB in an authenticated format, encrypted on the host before a single byte leaves it.
The key stays yours
Generated on the agent, kept in its config, exportable and importable. Lose it and the archive is unreadable — by you and by us.
Entropy gate
Every file is scored before upload. HIGH or CRITICAL suspicion blocks the run instead of shipping it.
Already encrypted?
Flag the path and it uploads as-is rather than being encrypted twice — and stops being read as suspicious.
Direct multipart upload
Presigned S3 to Hetzner in the EU, with per-part retry and exponential backoff.
A restore path in order
Download, verify SHA-256, decrypt on the agent, write to the target. In that sequence, every time.
Storage tiers
50 GB with 30-day retention, 250 GB with 90 days, 1 TB with a year.
Configure it where the host lives
Backup paths from the web UI, the CLI, or the agent's YAML.
— How it works

Zero-knowledge, in four steps.

1

Encrypt on the host

AES-256-GCM client-side. The key is derived on your server and never leaves it, so we hold ciphertext and nothing else.

2

Gate on entropy

A backup whose entropy suddenly looks like encrypted noise is refused — that is the ransomware copy overwriting your good one.

3

Upload directly

Multipart straight to object storage via presigned URLs. The data does not route through us.

4

Restore in order

Download, verify the SHA-256, decrypt on the agent, write to the target path — in that sequence, so a corrupt copy fails before it overwrites anything.

— Honest scope

Limits worth knowing.

— Works with

Connected capabilities

Ransomware Gate
The entropy-based check that protects your off-site bucket.
→
Audit Log
Each backup + restore logged + signed.
→
Capacity Planning
Backup growth forecast as part of capacity outlook.
→
Reports
Backup reliability + size reports for compliance.
→
— FAQ

Questions, answered honestly.

Where exactly does the encryption happen? +
On the agent, before any byte hits the wire. The platform receives ciphertext + IV + auth tag, nothing else.
What is the key derivation? +
HKDF-SHA256 from a master key you provide at enrolment, scoped per path. The master key never leaves your hosts.
How fast is restore? +
Bandwidth-limited mostly. A 50 GB backup restores in under 20 min on a typical hetzner line.

Backups that survive the worst-case.

Off-site Backups from Starter; larger storage tiers on Pro / Enterprise.

Get early access Back to Security & Backup