SeaweedFS on Hetzner: Self-Hosted S3 Storage | We Manage | We Manage

07139 / 9363342

Email us

de

en

*:first-child]:mt-0">

16. June 2026 · by Andreas Lehr

SeaweedFS on Hetzner: Self-Hosted S3 Storage — From Disk to Customer Migration

Key Takeaways

MinIO has tightened its license and feature scope significantly. We moved our entire backup infrastructure to SeaweedFS — a single Go binary with a full S3 API.

The base is Hetzner hardware servers with lots of large SATA HDDs in software RAID 6 , formatted with XFS . A perfect fit for how SeaweedFS stores data.

Operations run end-to-end through a custom Ansible role : binary, systemd units for master, volume and filer, S3 gateway with per-bucket credentials, and nginx as a reverse proxy.

The MinIO migration ran phased: small customers first, then bigger ones over time. MinIO and SeaweedFS ran in parallel for a while — that was the real-world test. The endpoint switch per customer was an Ansible re-deploy.

For geo-redundancy a deliberately time-offset rclone sync mirrors the dataset to a second site — a clean, intentionally delayed disaster-recovery replica.

The HDDs are monitored via SMART, mdadm and our Telegraf / VictoriaMetrics / Grafana stack. With double-digit disk counts that is mandatory, not nice-to-have.

Email was the topic of the last two posts — today it gets more tangible: metal, disks, and an S3-compatible object storage that we run ourselves. Specifically: how to build a robust, affordable S3 backend on ordinary Hetzner hardware that can hold backups, assets and anything else that speaks the S3 API, without locking yourself into a hyperscaler or its object-storage pricing.<br>We use our own backup infrastructure as a running example. We moved it from MinIO to SeaweedFS earlier this year: more than 100 TB of data, over 40 customer buckets, all driven by restic.<br>Why we moved off MinIO — and off Hetzner Object Storage<br>Two things came together. First, MinIO has been moving its license and feature policy in a direction that became increasingly unattractive for a self-hosted setup like ours: features migrated from the community edition into paid tiers, and the uncertainty about what would be cut next is not a great state for a production backup target.<br>Second, we wanted to run object storage on our own hardware anyway, not buy it as a managed service. The math is straightforward. Hetzner Object Storage starts at €7.72 per TB for the first TB; every additional TB costs €10.35 per month. The first TB of outbound traffic is included, every additional TB is €1.19. What Hetzner does differently from many providers: requests are free, and internal traffic — uploads and anything inside the Hetzner EU infrastructure — is not billed either. Even so, 200 TB of pure storage already lands at roughly €2,100 per month. On top sits a hard cap of 50 million objects per account (details and other limits live in the Hetzner docs) — for backup workloads with lots of small files that ceiling shows up quickly. A dedicated Hetzner Storage Server with the same raw capacity costs a fraction of that, and the backup software (restic, rclone) is open source and free. The second server typically pays for itself against managed object storage within a few months.<br>On top of that comes a second point that ended up almost as important as the cost: Hetzner Object Storage is currently noticeably unstable. The official status page regularly shows object-storage incidents — depending on the location, sometimes multiple times per week. For a production backup target sitting at the end of a recovery chain, that simply is not an option.

That combination — predictable, owned infrastructure instead of usage-based pricing, plus full control over availability — is why SeaweedFS makes sense for us.<br>The hardware: Hetzner storage servers<br>The servers come from the Hetzner catalog, depending on what we need either from the SX storage line or from the auction servers. For pure storage nodes the auction servers are especially attractive: lots of large SATA HDDs, plus one or two NVMe SSDs for the OS, at a fraction of the new-server price.<br>Something Hetzner offers on top that makes a lot of sense for storage nodes: an optional 10G uplink for dedicated servers. By default every Hetzner server runs on 1 Gbit/s — for initial migrations of 100 TB plus, restore tests, or geo-sync between two storage hosts, 10 Gbit/s is the difference between "finishes overnight" and "finishes over the weekend".<br>The disks run in software RAID 6 (mdadm). RAID 6 trades two disks for parity and therefore survives two simultaneous disk failures. On large arrays with long rebuild times that is the right choice. A worked example with a well-stocked server:

14 × 22 TB = 308 TB raw<br>− 2 disks parity (RAID 6)<br>= 12 × 22 TB = 264 TB usable<br>≈ 250 TB after filesystem overhead (XFS)

The filesystem is XFS :

mkfs.xfs -f -L seaweed-data /dev/md0

Why XFS and not ext4? Because SeaweedFS does not write millions of small files, it...