Dora NodaEvery self-hosted platform eventually pays a second infrastructure bill that nobody modeled in the launch spreadsheet. Not compute, not bandwidth for serving traffic — backups. Volume snapshots, build artifacts, database dumps: the data you hope to never read and must always be able to read. On a managed PaaS that bill hides inside the platform fee. On machines you own, you pick the bucket, and the bucket sets the price.
Here is the answer up front, worked for a typical small-fleet footprint — 2 TB of retained backups with about 200 GB of restore and verification reads a month:
| Backend | Storage (2 TB) | Egress (200 GB) | Requests | Monthly total |
|---|---|---|---|---|
| Hetzner Object Storage | ~€12.96 | €0 (inside allowance) | €0 (free API calls) | |
| AWS S3 Standard | ~$46 | ~$18 | ~$1–2 | ~$65 |
| Cloudflare R2 | $30 | $0 | ~$1–2 | ~$31–32 |
| Backblaze B2 | $12 | $0–2 (3x allowance) | small | ~$12–14 |
Same bytes, same restore pattern — and the most expensive option costs nearly 5x the cheapest. The rest of this post shows the formula behind that table, runs it at three fleet sizes, and covers the part the price tables don't: what keeping backups inside the provider that already hosts your machines buys you on restore day, and where that placement breaks down.
What Hetzner Object Storage actually is
Hetzner Object Storage is S3-compatible bucket storage sold alongside Hetzner's compute line: standard buckets with an S3 API, access keys, and per-bucket regions, aimed at exactly the workloads in this post's title — snapshots, artifacts, dumps, archives. Three facts define its economics.
First, the price shape. At launch it rented at €4.99 a month for 1 TB; after the April 2026 price adjustment it is €6.49 a month base, including roughly 1 TB of storage and roughly 1 TB of egress, with overage around €0.0087 per TB-hour for storage (about €6.47 per TB per month if held all month) and €1 per TB of egress. Ingress is free and S3 API calls are free — no per-thousand PUT/GET/LIST meter running alongside the byte meter.
Second, the placement. Buckets live in Hetzner's European locations — Falkenstein (fsn1), Nuremberg (nbg1), Helsinki (hel1). There is no US or Singapore object storage to match Hetzner's Ashburn, Hillsboro, and Singapore compute regions. And traffic between Hetzner Cloud servers and Object Storage in the same region does not pay the egress meter, which is the single most important line in this post for anyone whose fleet already runs on Hetzner.
Third, the maturity caveat. It is a younger service than the buckets it competes with, and some locations carried beta labels into 2026 — verify GA status in your target region before committing, and expect a smaller ecosystem of tools tested against its endpoint than against S3. For backup writers that speak generic S3 (Velero's AWS plugin, restic, rclone, CNPG's barman object store), that gap is configuration, not engineering. For anything needing S3's newer or exotic APIs, check compatibility first.
The three backup workloads and one typical footprint
Tenant backups on a self-hosted PaaS are three different write patterns sharing one bucket bill, and they need to be sized separately because only one of them is large:
Volume snapshots are the heavy line. A fleet keeping 30 days of daily volume snapshots for tenant data — databases, uploaded files, persistent scratch — with roughly 5 percent daily change legitimately accumulates into terabyte territory. Call it 1.5 TB retained for a small production fleet: not a stress case, just what a month of daily incrementals plus a weekly full looks like once deduplication and compression have done their best and the data keeps growing anyway.
Build artifacts are the churn line. Every git-push build produces container image layers and build caches worth keeping for fast rollbacks — say 300 GB retained across recent releases. High write volume, high overwrite rate, almost never read except during a rollback. This is the workload that makes free API calls worth real money: thousands of PUTs a month that S3 meters at roughly $0.005 per thousand while Hetzner simply doesn't meter.
Database dumps are the small-but-sacred line. Hourly or daily logical dumps (pg_dump and equivalents) shipped off the database host, ~200 GB retained with rotation. Tiny in bytes, but these are the files you reach for when snapshots can't help — logical corruption, a dropped table, a restore to a different engine version. Their value per byte is the highest on the fleet, and their access pattern (frequent small PUTs, rare full reads) is exactly what request-metered pricing punishes and flat pricing rewards.
Total: 2 TB stored, ~200 GB read back monthly for restore drills and real restores. That is the "typical" column in the tables below — big enough that the bucket choice matters, small enough to describe most fleets that have outgrown a single box but haven't hired a storage team.
The worked comparison at three sizes
Both sides get fully loaded bills: storage plus egress plus the request meter where one exists. Hetzner figures use post-April-2026 list rates excluding VAT, converted at roughly €1 to $1.10 — close enough for gaps that land in multiples.
Small fleet: 500 GB stored, 50 GB read back. Everything fits inside Hetzner's €6.49 base allowance (1 TB storage, 1 TB egress included), so the bill is €6.49 (~$7) flat. S3 charges 500 × $0.023 ≈ $11.50 plus 50 × $0.09 = $4.50 plus requests, landing near $16–17. R2 charges 500 × $0.015 = $7.50 with zero egress. B2 charges 500 × $0.006 = $3 with egress inside the 3x free allowance. At this size B2 wins on raw dollars and Hetzner ties R2 — the bucket decision is about placement, not price, which is the next section's subject.
Typical fleet: 2 TB stored, 200 GB read back. Hetzner: €6.49 base covers the first TB of each, the second TB of storage adds ~€6.47, egress stays inside allowance — €12.96 ($14), requests free. S3: 2,000 × $0.023 = $46 storage plus 200 × $0.09 = $18 egress plus requests lands near $65. R2: 2,000 × $0.015 = $30 flat. B2: 2,000 × $0.006 = $12 plus at most $2 egress, ~$12–14. Hetzner and B2 tie at roughly a fifth of S3; R2 sits in the middle at half of S3.
Large fleet: 10 TB stored, 1 TB read back. Hetzner: €6.49 + 9 × ~€6.47 ≈ €65 ($71). S3: $230 + $90 + requests ≈ ~$322. R2: $150 flat. B2: $60 + egress inside allowance ≈ ~$60–70. The ordering is stable — B2 and Hetzner cheapest, R2 middle, S3 roughly 4–5x the cheapest — with one moving part: as restore egress grows past Hetzner's included terabyte, its €1/TB overage is still two orders of magnitude under S3's $90/TB, while R2's zero egress starts beating everyone once reads get big relative to stored bytes.
| Footprint | Hetzner | S3 | R2 | B2 |
|---|---|---|---|---|
| 500 GB / 50 GB reads | ~$7 | ~$16 | $7.50 | ~$3 |
| 2 TB / 200 GB reads | ~$14 | ~$65 | ~$30 | ~$12–14 |
| 10 TB / 1 TB reads | ~$71 | ~$322 | $150 | ~$60–70 |
Three patterns fall out. First, S3's egress meter dominates everything: at every size, the $0.09/GB read price contributes a third or more of the bill, which means any fleet that actually tests its restores — as it should — pays a drill tax nowhere else charges.
Second, Hetzner's included-terabyte base makes it cheapest-or-tied up to multi-TB footprints specifically for EU fleets, and its free API calls make the build-artifact churn line disappear from the bill entirely. Third, R2 is the answer to a different question — "what if reads are huge or global" — and B2 is the answer when raw dollars per stored byte are the whole question and placement doesn't matter.
What same-provider placement buys on restore day
Price is half the decision; the other half is what happens at 2 AM when a tenant needs yesterday back. Keeping backups in the provider that hosts the machines buys three concrete things.
Restore bandwidth without a meter running. A full-fleet restore — rehydrating terabytes of snapshots onto fresh volumes — is the highest-egress event a backup backend ever sees, and it is precisely the event where S3's $0.09/GB turns a bad night into a $200 line item. Same-region restores from Hetzner Object Storage to Hetzner Cloud don't touch the egress allowance at all, and even cross-region or off-provider restores pay €1/TB — background noise next to the incident. B2's 3x allowance and R2's zero egress offer their own versions of this; S3 is the only option where the restore itself is metered punitively.
One failure domain to reason about, one support contract. Backup restores fail at the seams: credentials, endpoints, region mismatches, IAM-shaped permissions on the bucket side meeting firewall rules on the compute side. Same-provider placement collapses two vendors' failure modes into one network, one access-key system, one status page. The homelab and small-fleet operators documenting Velero-against-S3-compatible-storage setups converge on this independently — the working backup is the one with the fewest moving vendors, and restic-to-a-box-you-control or Velero-to-the-bucket-next-door beats a cleverer topology nobody tested.
Tooling that already speaks S3. The backup writers a Kubernetes-based fleet actually runs — Velero with its AWS provider plugin pointed at a custom endpoint, restic repositories on S3 backends, database operators shipping WAL archives to object stores — need an S3-shaped API, not AWS itself. Point them at the bucket endpoint in fsn1, nbg1, or hel1 and the existing schedules, retention policies, and restore runbooks transfer unchanged. The gap to verify is at the edges: VolumeSnapshot-to-remote-repository flows depend on CSI driver support that neither Hetzner Cloud Volumes nor several popular in-cluster provisioners fully provide, so test the full snapshot-to-bucket-to-restore path rather than assuming generic S3 compatibility covers it.
Now the honest limits, because placement cuts both ways. EU-only buckets are the real constraint: a fleet serving US or APAC tenants from Ashburn, Hillsboro, or Singapore has no same-provider bucket to restore from, and pulling terabytes across the Atlantic on restore day trades the egress savings for latency at the worst possible moment.
Youth of the service is second: beta labels in some locations into 2026 and a thinner bench of battle-tested tooling mean the restore path needs the testing discipline the pricing section assumed — schedule the drill, time it, read the bytes back. And ecosystem depth is third: cross-region replication topologies, object-lock compliance retention, and analytics-adjacent features that S3 ships as checkboxes are DIY or absent. If your backup story needs WORM compliance rather than snapshots and dumps, the cheap bucket is the wrong tool.
The decision, stated as a rule
If your fleet runs on Hetzner in the EU and your backup footprint is rest-heavy — snapshots retained for weeks, dumps rotated daily, restores tested monthly — Hetzner Object Storage is the default: ~$14 a month at 2 TB against ~$65 on S3, with restores that don't move the meter and one provider's failure modes to reason about.
If raw dollars per byte dominate and placement is irrelevant, B2 ties or beats it. If your reads are global or enormous, R2's zero egress wins. S3 is what you pay when you need its ecosystem — replication, compliance locks, tooling breadth — priced explicitly as the premium it is, roughly 4–5x the cheapest correct answer at every size in the table.
Whichever bucket you pick, the discipline is identical and non-negotiable: encrypt before upload, rotate the dumps, and restore on a schedule — a backup that has never been read back is a hypothesis, and no per-gigabyte price, however low, makes an untested hypothesis cheaper.
Self-hosting the fleet behind the backups? Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.
