How we test: real servers, real output

A self-hosting tutorial is only as good as its weakest command. If a container won’t start in step 6, the rest of the guide is no use to you. That’s why every recipe here runs through completely once before it goes online, on a server just like the one you can rent.

The test kitchen

We have two servers at netcup that are permanently set aside for testing:

• a VPS 1000 G12 with shared cores, 8 GB of RAM and Debian 13. Every tutorial is checked on it. It’s deliberately the small machine: it matches what most of you order to get started. Whatever runs there runs even better on a bigger server.
• a root server RS 1000 G12 with dedicated cores. We need it as soon as a topic calls for two machines: a server migration, Matrix federation, a backup target that really is somewhere else, or a benchmark comparison.

Both run Docker from the official package source and Traefik as the reverse proxy, exactly as described in our basics tutorials. The test services get real subdomains and real Let’s Encrypt certificates. So we test a setup of an app plus a login service with two hostnames, the same way we recommend it to you.

There’s one quirk we know about: the VPS is hardened with our own Lynis tutorial, including a stricter umask. If an error only shows up there, we cross-check on the unhardened RS to see whether the hardening or the guide is to blame.

What “tested” means here

Every command in the article was run on the test server. The output you see in the code blocks comes from exactly those runs. We don’t tidy it up or write it down from memory, because that’s exactly where mistakes creep in. We replace real IP addresses and hostnames with placeholders; everything else stays as it was.

The versions are listed in the “Tested with” box at the top, and the image tags in the Compose files are pinned. If you follow the guide six months from now, you get the same ingredients we had.

Sometimes testing turns up things no documentation mentions. When we compared reverse proxies, for example, Nginx Proxy Manager discarded the switches for forced HTTPS if you set them right when creating a host. It’s a known bug that has been open for years. In cases like that the tutorial tells you how to work around it, not just how it’s supposed to work.

What we can’t test

Some things can’t be fully checked from our workstation. UDP traffic is one of them: video calls over WebRTC or HTTP/3 need a return path we don’t get from there. So for HTTP/3 we test from the second server. That’s also how we noticed that the netcup firewall doesn’t let UDP replies through on its own, which is now covered in our firewall guide.

Sending mail is the other case. netcup blocks outgoing mail ports by default, so we check mail against a local mail catcher first. Wherever we couldn’t check something end to end, we say so.

How often we retest

Software moves fast, and a tutorial that was right in summer can be out of date by autumn. So our rules are:

• Shortly before publication, at most a week ahead, we check every article against the current versions once more.
• Apps that often make big jumps, like Nextcloud, Immich, Traefik or mailcow, get looked at more often than quiet topics like SSH or firewall basics.
• Once a quarter the whole catalogue gets a pass: versions, links, output, screenshots.

When an article was last revised is shown right below the title and on the cards.

When we get it wrong

It happens. An example from November 2026: the top of an article said “Tested with … VPS 1000 G12”, while the box further down said “In our test this setup ran on VPS 1000 G12.5”. Both couldn’t be true, because we test on the G12 and recommend the current model. A note from outside pointed us to it, and it was fixed on every page the same day.

If you notice something like that, or a command behaves differently for you than described, write to us at feedback@serverkueche.de. We reproduce it on the test server. Corrections go online with the next evening update, and the date below the title shows you that something changed.

Who’s behind Serverküche and how it’s funded is on the About us page.