seedbox hosting
Seedboxes and bulk storage
Terabytes that stay cheap and a port that stays open.
What we would deploy
€49.63/mo
€70.90−30% annual
Bulk storage workloads need three things that most virtual servers get wrong: real capacity at a price that does not scale like NVMe, a network port that is not throttled the moment you use it, and a filesystem that can checksum what it holds. VAULT is built on ZFS with an NVMe cache layer in front of enterprise drives, so metadata operations stay fast while the bulk sits on cheap spindles.
Why this configuration
ZFS with hourly snapshots protects you from your own scripts, and unmetered traffic on the larger sizes removes the arithmetic from the equation. Amsterdam and Bucharest have the cheapest transit in our footprint.
What we would deploy
Sizing
Two numbers: library size and how much of it you seed hot. VAULT reaches 32 TB, so start from the library and add 25% — ZFS degrades noticeably above roughly 80% pool fill. RAM is for ARC, and 1 GB per TB remains a fair rule for media, since it is metadata you want cached rather than payload. 16 GB indexes a 16 TB library, and 64 GB leaves ARC room for the hot set. Two cores handle the client; add more only for re-encryption or archive verification.
Pool layout for a seeding library
Seeding is random reads of small pieces across a large set of files. RAIDZ2 maximises usable capacity and gives roughly one disk of random IOPS per vdev. Mirrors halve capacity and multiply IOPS. With NVMe cache in front, RAIDZ2 in two vdevs is usually the right compromise for a library over 10 TB. Set atime=off, compression=lz4, recordsize=1M, and keep sync=standard. A SLOG helps nothing here because torrent writes are asynchronous. Watch fragmentation as the pool ages: heavy churn on a pool held above 80% degrades sequential reads long before capacity runs out.
Unmetered traffic, and where it actually stops
An unmetered gigabit port will move roughly 300 TB in a month if you keep it saturated. Almost nobody does, because the limits arrive earlier and elsewhere. Peer count and connection tracking hit conntrack table limits first — raise nf_conntrack_max and the hash size before you blame the disk. Then per-torrent piece verification burns CPU on hash checks during recheck. Then the pool runs out of random IOPS. Cheap capacity only pays if the layout can serve it, so size the NVMe cache to hold your active seeding set rather than the whole library.
What goes wrong
- Enabling ZFS dedup on a media pool. The dedup table lives in RAM permanently, media files rarely dedup, and removing it later means rewriting the whole dataset. Use compression instead and leave dedup off.
- Leaving recordsize at 128K. Large sequential media files want recordsize=1M — fewer indirect blocks, less metadata, better sequential throughput. Set it on the dataset before you write data, because it applies only to new blocks.
- Treating unmetered as unlimited IOPS. The port is unmetered; the pool is not. A thousand torrents seeding at once is a random-read workload, and RAIDZ gives you one disk's worth of IOPS per vdev.
Tune the machine
- Storage and encryption — ZFS with hourly snapshots · €7
- Addressing and transit — Uplink upgrade to 10 Gbps · €19
- Control panel — No control panel · Included
More
Built for specific jobs
Game server hosting
Tick rate is a single-thread problem. Everything else is noise.
Trading and low-latency VPS
Distance to the matching engine, and nothing between you and the wire.
Private VPN and proxy endpoints
Your own exit, in a jurisdiction you picked on purpose.
Kubernetes worker nodes
Cheap per core, dense, and identical every time.
AI inference and fine-tuning
A whole GPU, passed through, on a commitment that makes the maths work.
Hosting resellers
Your brand on the panel, our hardware underneath.