build a server →

Download servers.
Every download costs the same.

Mirrors, releases, game patches and datasets served straight to the people who asked for them, from a port with no counter. On metered hosting the busiest release day is the biggest bill; here it is an ordinary month.

port
1, 10, 25, 40, 100 Gbps
egress
unmetered
locations
AMS · MEP · IAD · PHX
in plain words

A release day is the whole workload.

A download server holds files and hands a copy to everyone who asks: installers, game patches, ISO images, datasets. Most days are quiet; the day you ship, everyone comes at once.

What you pay for is the port, not the bytes. Size it for that one day, and the rest of the month is spare capacity you have already paid for.

sizing it · four steps

How to choose.

  1. 01 ─ size

    Write down what you serve: how big the files are and how much of the archive people still download.

  2. 02 ─ reach

    Estimate downloads on an ordinary day and on release day. The second number is the one that sizes the machine.

  3. 03 ─ port

    Pick the port for the release-day peak, not the average. A wider port means the day ends sooner, not that the bill grows.

  4. 04 ─ location

    Serve from the site closest to the people downloading. Two continents usually mean two machines.

what it solves
  1. 01 ─

    Release day is the bill

    on a meter or a shared host

    Downloads peak on the day you ship, and on a meter so does the invoice.

    here

    The invoice is the same in the month you ship as in the month you do not.

  2. 02 ─

    Egress priced per gigabyte

    on a meter or a shared host

    Every download becomes a line on the bill, so popularity costs money.

    here

    Nothing counts the bytes: ingress and egress are unmetered.

  3. 03 ─

    Mirrors nobody can afford

    on a meter or a shared host

    A public mirror for a project or a community is a loss on metered traffic.

    here

    It costs the price of the server, whatever the mirror serves.

the right build for it

What to look for in the machine.

portsized to the release-day peak

Downloads arrive all at once on the day you ship; the port decides how fast that day goes.

disksthe archive, plus NVMe for hot files

Old releases need space; the files everyone wants this week need speed.

memoryenough to cache the popular files

Files served from memory never touch the disks, and on release day that is most of them.

cpumodest

Serving files is IO and TLS on many connections, not heavy compute.

Which builds on the price list fit this today is on the pricing page. Plans change; what to look for in the machine does not.

before you order

Questions to settle before ordering.

  1. 01 ─

    Can people upload files for others to download?

    No. That is a file-sharing service, which section 4 of the terms does not allow. Serve your own files, or files you are licensed to distribute.

  2. 02 ─

    Which protocols can I serve?

    Any you run: HTTP, rsync, FTP or your own. It is your machine, and we do not shape traffic by protocol (Terms, section 3).

  3. 03 ─

    Can I run a public mirror for an open-source project?

    Yes: that is software you are licensed to distribute. The project's own requirements for mirrors, such as sync schedules and capacity, are yours to meet.

The rest, for every machine: all questions and the terms.

where we draw the line

Tell us what it serves.

The workload, the working set, where the users are. We come back with a machine sized to it, a price and a date.

send the spec →compare plans →

alsounmetered servers · CDN origins · streaming servers · game servers · storage servers · database & compute · virtualisation hosts · blockchain node servers