The whole thing, not the first half.
Each guide takes one empty instance and turns it into a service you can point real traffic at. Commands run top to bottom in the order they are printed, placeholders are marked as placeholders, and the last section is always a test. No guide here ends with “and then configure the rest to taste”.
A guide is not a knowledge-base entry
Both formats exist because each is bad at the other’s job. Blend them and you get the sort of documentation that explains what every flag does without ever telling you which flags you need.
The knowledge base answers a question in a minute. A guide costs you an afternoon and leaves a server running at the end of it.
A knowledge-base entry begins with something you already have and something that is wrong with it: a mount that will not come back after reboot, a certificate that renewed but did not reload, a rescue console you cannot get a prompt out of. It is short because the context is already in your head. You arrive with the problem and leave with the answer.
A guide begins with nothing. You have paid an invoice, you have root credentials, and the machine is an unconfigured image in a city you picked for reasons of your own. By the end you have a mail server that passes authentication checks, or a hypervisor running nested guests, or two terabytes sitting in a different country than they were this morning. The context is built as you go, which is why these run to a couple of thousand words rather than two hundred.
Writing them this way is more work and it catches more mistakes. Every guide on this page was run start to finish on a freshly deployed instance before publication, and re-run whenever the upstream project shipped something that broke it. The date at the top of each one is the date it was last run, not the date somebody skimmed it.
One complete thing
Not a survey of six options and a shrug. Each guide picks an approach, says why, and builds that. Where a real alternative exists it gets one sentence and a link, then the guide carries on.
Commands that run in sequence
Copy them in the printed order on a fresh image and they work. If step nine needs a package installed in step two, step two installs it. Nothing depends on state you were never told to create.
A named machine
Each build states which line it was written on and what happens if you use something smaller. Postgres tuning that assumes 64 GB of ECC is useless advice on a 16 GB box, so we say so at the top.
The boring middle
File ownership, systemd unit hardening, firewall rules, log rotation. This is the part most tutorials skip and the part that decides whether the service is still up in March.
A test at the end
Every guide finishes with commands whose output tells you unambiguously whether the build worked. Not “you should now see the login page”. Something with an exit code or a header you can read.
“If the last line of the page is “and then configure your firewall”, it is not a guide, it is a shopping list.”
How to follow one without losing an evening
These are written for people who read the whole page before typing anything. That habit is worth roughly an hour per build.
Assume a fresh Debian 13 image and a root shell unless the guide says otherwise. Everything else is stated in the first two paragraphs.
- 01
Deploy something new
Retro-fitting a guide onto a machine that already runs three services is how you discover which of them was quietly using port 8080. A fresh instance is under a minute away and you can destroy it afterwards.
- 02
Read it through once
Particularly the DNS steps. Half the builds here need a record to have propagated before a later command will succeed, and the cheapest place to learn that is on the first read rather than at step eleven.
- 03
Substitute the placeholders
Anything shaped like example.com, 2001:db8: or <angle brackets> is yours to replace. Documentation ranges are used deliberately so that a copy-paste mistake fails loudly instead of quietly reaching a stranger’s network.
- 04
Snapshot before the irreversible bit
Repartitioning, dist-upgrades, anything involving the word “wipe”. A snapshot pack gives you five slots and a restore that finishes in seconds, which is cheaper than repeating steps one through nine.
- 05
Run the verification
It is the last section of every guide and it exists because “it seemed to start” is not the same as “it works”. Two minutes of checking beats finding out from a user.
Nothing on this page pipes a remote script into a shell. Where an upstream project only ships an installer that way, the guide shows you how to fetch it, read it and run it as a file — you should know what went onto your machine, and so should we.
Which machine each build wants
Most of these run happily on the smallest Ryzen instance. Four of them do not, and picking the wrong line for those four wastes an afternoon before you reach the interesting part.
Where a guide names a plan, that is the plan it was tested on. Going smaller is usually fine and is noted where it is not. Larger changes nothing except the numbers you put in the config files, and the guides that care about that arithmetic show the arithmetic.
| Build | Line | Why that one |
|---|---|---|
| WireGuard, Tor relay, Matrix, monitoring | Ryzen R-4 | Single-threaded, network-bound, tiny working set. More cores change nothing. |
| Mail server, CI runner, Nextcloud | Ryzen R-8 | Build steps and antispam both like fast cores. Image builds are the heaviest thing here. |
| Postgres | EPYC E-8 upward | The tuning in that guide assumes 64 GB of ECC memory and NUMA-aware pinning. |
| Local inference | GPU G-L40S | Forty-eight gigabytes of VRAM, passed straight through. A shared card is somebody else’s queue. |
| Seedbox | Storage S-50 | Fifty terabytes of bulk behind an NVMe write tier, on a port fat enough to drain it. |
| Proxmox with nested guests | Bare metal BM-E | Nested virtualisation needs the physical machine. There is no hypervisor of ours in the way. |
| Moving two terabytes between sites | Any two instances | Written against a storage node and a Ryzen box, but the method is the same at any size. |
Every guide assumes the routed IPv6 /64 that ships with every instance. Two of them ask for the /48 instead, because handing out per-client subnets from a single /64 means proxying neighbour discovery, and proxied IPv6 is a thing you debug for a living rather than run.
Privacy
03Infrastructure
04Development
02Networking
02Questions about the guides, rather than the builds
Mostly, yes. The parts that are ours are the panel steps, the routed prefix and the assumption of dedicated cores. Everything else is stock Debian and upstream software, so the commands port cleanly to anywhere that gives you root and does not oversell the CPU.
Because writing twelve guides five times over is how documentation goes stale. Debian 13 is our default image, the package names are stable for years, and translating a step to AlmaLinux or Alpine is a package-manager substitution rather than a rewrite. Full image list is on the operating systems page.
Tell us. Guides are re-run against a clean image when we hear about a break, and the corrected version ships the same week with the date at the top bumped. A ticket with the command and the error is enough; you do not need to diagnose it for us.
We support the machine, the network and the storage under it. Debugging your Postfix map files at three in the morning is not on that list, and we would be bad at it anyway. Managed hardening exists as an add-on if you want the baseline maintained by somebody else.
For eight of the twelve, yes, and the R-4 is what several were written on. The Postgres, inference, seedbox and Proxmox builds need the line named in the table above; the rest is comfortable on four dedicated cores and 16 GB.
Pick a city, deploy, follow along.
The instance you need for most of these costs less than the coffee you will drink while building it. Pay in coin, wait about forty-seven seconds, and start at step one.