100 days of netcup: what nobody tells you beforehand

Every recipe on this site is created on this VPS. It has been running since 16 July, and in that time we have set up, tested and torn down around twenty applications on it. This article is the review: what actually happened, and the quirks we stumbled over.

No advertising copy. The most uncomfortable number comes right away in Step 2.

What are we building?

Nothing – we are reporting. By the end you will know what to expect from netcup in continuous operation, which four quirks would otherwise cost you an evening each, what the September price round means for you – depending on whether you are an existing customer or ordering new – and how netcup responded to a critical kernel vulnerability.

The machine is a VPS 1000 G12 with 4 vCores, 8 GB RAM and a 251 GB disk, on Debian 13. The only things running on it permanently are a reverse proxy and changing test setups.

Prerequisites

None – this is a report, not a recipe. If you want to read along and check your own system, all you need is SSH access to your own server. The commands in Step 2 run on any Linux host with Docker.

If you don’t have a server at all yet: the plans are listed in the netcup overview, and the server calculator estimates what your project really needs.

Step by step

Step 1: What happened in 79 days

The most boring part first, and that is meant as a compliment:

The server just kept running. No outages, no crashed services, no support cases. In all that time the automatic security updates had something to do exactly twice – both times Docker, on 21 July. That is not a shortcoming, it is Debian stable: things rarely happen, and when they do, they are targeted.

The 39 apt runs say more about us than about the server: they are almost exclusively our own installations for tutorials, not automatic maintenance. A server simply doesn’t keep itself clean. What happens without any help are exactly those two security updates – everything else depends on someone keeping an eye on it.

Two caveats, so the number doesn’t sound better than it is. First, “79 days of uptime” says nothing about availability – we didn’t measure from outside, we only established that the machine wasn’t rebooted. Second, it applies to the host, not to everything on it:

docker ps --format "{{.Names}}\t{{.Status}}"

traefik-traefik-1   Up 2 weeks

The reverse proxy did not run for 79 days, but for two weeks. A Docker update restarted it at some point. That is harmless and exactly what restart: unless-stopped is supposed to do – but “the server has been up for eleven weeks” and “your service ran for eleven weeks” are two different statements.

One number in the table deserves a closer look: 31 Let’s Encrypt certificates in 79 days. Every test setup got its own subdomain, and Traefik fetches a separate certificate for each. That is unremarkable until you know that Let’s Encrypt issues 50 certificates in 7 days per registered domain – globally, regardless of which account is asking. After that the quota only refills slowly, with one certificate every three hours or so.

Spread over 79 days that is completely harmless. But if you try out twenty subdomains in one afternoon and start over a few times along the way, you suddenly face a proxy that no longer gets certificates – and look for the mistake on your end. For test series there is therefore Let’s Encrypt’s staging environment, which runs through the same mechanics without a quota.

Step 2: The disk fills up – and it isn’t your data

Here is the uncomfortable number. A look at the disk:

df -h /

/dev/vda4       251G   73G  169G  31% /

73 GB used. On a server running exactly one container. The explanation:

docker system df

TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          107       1         74.58GB   68.43GB (91%)
Containers      1         1         8.192kB   0B (0%)
Build Cache     33        0         209.5MB   4.096kB

107 images, 74.58 GB, 91 % of it disposable. It isn’t the data filling up the server, it’s the leftovers. Every docker compose down removes containers and volumes – the downloaded images stay behind. The biggest chunks in our case:

3.69GB  mcr.microsoft.com/playwright:v1.56.0-noble
3.50GB  ghcr.io/paperless-ngx/paperless-ngx:3.1.3
3.45GB  mcr.microsoft.com/playwright:v1.61.1-noble
3.38GB  stirlingtools/stirling-pdf:2.14.3
3.12GB  ghcr.io/immich-app/immich-server:v3.1.0
3.11GB  ghcr.io/immich-app/immich-server:v3.0.3

Playwright twice, Immich twice – every update puts a new image next to the old one, and the old one stays. After a few months you have an image dump you don’t notice until the disk gets tight.

This is the point where the plan generation suddenly matters. Our VPS 1000 is a G12 with 251 GB. The current G12.5 comes with 128 GB. The same dump would already take up more than half of the disk there – and that is before any actual data comes in.

Cleaning up is one line:

docker image prune -a

This removes all images that no container is currently using. Run it when you know what is running; otherwise the next start pulls the images again. For everyday use the milder docker image prune is enough – it only throws away unnamed intermediate layers.

Step 3: Mail doesn’t go out, and it isn’t your fault

The first quirk that costs time. You set up a mail server, everything looks fine, and outgoing mail runs into a timeout on port 25.

The culprit is netcup’s default policy “netcup Mail block”: it blocks ports 25, 465 and 587 outbound. That is exactly what we measured – these three run into a timeout, while 993, 22 and 443 are open.

The important part: this is not a support case. You take the policy off the server yourself in the Server Control Panel under Firewall → Policies, no ticket, no waiting. Many people instead spend hours looking for the fault in Postfix. How to do it is described in netcup firewall setup; making sure your mail actually arrives afterwards is a separate topic covered in email deliverability.

Step 4: The firewall is stateless for UDP

The quirk that confuses people most, because it feels like a broken server.

With TCP, the netcup firewall remembers that you opened a connection and lets the reply through. With UDP it doesn’t. Your server asks a DNS server on port 53, the reply comes back from port 53 – and gets dropped because no rule expects it.

The result: name resolution and time synchronisation don’t work, even though everything outbound seems to be allowed. For DNS and NTP you need your own inbound rules on source ports 53 and 123. The ready-made, reusable policy for this is also in netcup firewall setup.

If you don’t use the SCP firewall at all, you won’t notice any of this – in that case only the firewall on the server itself protects you.

Step 5: Almost everything is closed inbound

The third quirk is the most harmless, but it will just as surely cost you an afternoon if you don’t know about it. Open inbound on our server are 22, 80 and 443. Nothing else.

Measured: a service on 8443 ran into a timeout from outside, while it responded perfectly on the server itself. Exactly this pattern – works locally, not from outside – is the telltale sign.

Every additional port is a separate policy in the SCP. We had to do that once for Jitsi, which needs UDP 10000 for the media streams. Plan for this before you pick a service that needs exotic ports.

Step 6: The price round – and what nobody tells existing customers

On 22 September netcup raised the prices for new orders and explained the reasons openly in its own forum: purchase prices for RAM and flash storage are five times what they were a year ago, and the market has been bought empty, right down to refurbished hardware.

What stands out is less the increase than the reasoning. netcup lays out the four options it had to choose from: sell everything off and switch to “sold out”, massively overbook the servers, keep the prices and cut the specifications instead – or adjust the products to the market level. They chose the fourth route. You don’t have to like the prices, but the alternative “same price, quietly less performance” would have been the more unpleasant one for you as an operator, because you only notice it when things get tight.

What changes:

On storage, netcup writes that it continues to provision flash-based with RAID 6, but “can’t guarantee NVMe only”. That is something different from “no more NVMe” – you don’t know in advance what you’ll get.

And now the part that is easy to overlook, even though it is worth real money:

• Existing contracts are not increased. If you have a server, you keep paying your price.
• Upgrades run at the old price. netcup has specifically kept capacity free on the existing hardware for this. So an RS 1000 G12 can be moved up to an RS 2000 G12 on the old terms – that also applies on renewal.
• The contract exchange (Tauschbörse) keeps the old prices. If you take over a contract there, you keep the G12 terms, as long as offers are available.

In practice this means: if you want to grow anyway, upgrading your existing contract is considerably cheaper than a new order. And if you are just getting started, it pays to look at the contract exchange before you order.

Step 7: Day 94 – netcup restarts every server

Just before this article went out, a restart came after all – and not from us. On 15 October PwnEscape was published (CVE-2026-99999, CVSS 9.3): a bug in the Linux kernel’s IPv4 networking stack. Using crafted packets, a guest can read memory of the host; in the discoverer’s lab it went as far as code execution on the host. It was found by pwn.ai during a security challenge run by Vercel. The fix has been in the kernel since 14 October – but it only takes effect once the KVM host boots the patched kernel. And when the host goes down, every VM on it goes with it.

For a provider whose hosts run different customers side by side, that is the worst case: one VM could read its neighbours’ memory. On 16 October netcup announced on netcup-status.de that all VPS and root servers would be restarted in blocks from the 17th, with 20 to 30 minutes of downtime per server. The notice at first only mentioned software updates. In an update on 19 October netcup names the reason explicitly: PwnEscape, which became known only a few hours before the restarts began. Normally, netcup writes there, such maintenance is announced several days ahead – this time that wasn’t possible.

Our turn came on 18 October. The journal shows how the restart arrived:

journalctl -b -1 -u systemd-logind --no-hostname | grep hypervisor

Oct 18 10:19:30 systemd-logind[774]: System is powering down (hypervisor initiated shutdown).

hypervisor initiated shutdown means netcup shut the server down cleanly via the QEMU guest agent, like pressing the power button. Services were stopped properly and file systems synced. At 10:34 it was running again – 14½ minutes of downtime, less than announced. Thanks to restart: unless-stopped, Traefik came back up on its own; there was nothing to do.

The timing is what stands out. There was no public exploit at that point; the discoverer expects one within a few weeks. netcup didn’t wait for one but started the restarts two days after publication. A quarter of an hour of downtime on a Sunday morning is a fair price for that – the alternative would be a host on which a stranger’s VM can look into your memory.

What to take away:

• Services have to start without you. Make sure everything runs with restart: unless-stopped or as an enabled systemd unit. A container you once started by hand is simply gone after a restart like this.
• Announced doesn’t mean scheduled. The status notice gave a window of days, not a time per server. According to netcup, the notification email now arrives about an hour before the individual server restarts – sent to the address in your customer account, so make sure it’s one you actually read. If you want to know when your service was really down, you need monitoring from the outside, for example Uptime Kuma.
• netcup patches the host, you patch the guest. PwnEscape lives in the KVM host’s kernel, not in your VM – there’s nothing to do there, and a kernel update in the guest wouldn’t have helped. For your own kernel, what’s under “Maintenance & backups” still applies.

last shows whether it has already hit you:

last -x reboot shutdown | head -3

reboot   system boot  6.12.111+deb13-a Sun Oct 18 10:34 - still running
reboot   system boot  6.12.111+deb13-a Thu Oct  8 11:29 - 10:19 (9+22:49)
shutdown system down  6.12.111+deb13-a Sun Oct 18 10:19 - 10:34  (00:14)

A shutdown from 17 October onwards that you didn’t trigger yourself was this restart. Note the kernel column: the same version before and after, 6.12.111. What rebooted was the host underneath, not our system. The entry from 8 October is our own, by the way: the reboot after a kernel update that ended the uptime from step 1 after 84 days.

Three days later, on 21 October, the next emergency arrived – this time in PHP (CVE-2026-109618 and -109619). netcup took web hosting and managed servers offline for a while and rolled out patched PHP builds itself. On a VPS that doesn’t happen: there, PHP lives inside your container images, and nobody updates those but you. How to find out which of your services are affected is covered in Keeping your whole Docker stack safely up to date.

When things go wrong

Your problem is not listed? Search all error messages →

Maintenance & backups

After a hundred days, the list of things you really have to do regularly is short – but it isn’t empty.

Clean up monthly. docker image prune -a belongs in your calendar, otherwise Step 2 will repeat itself on your server. Two minutes, and on small disks the difference between “running” and “Disk full” on a Sunday evening.

Reboot when a new kernel is available. netcup updates the host’s kernel – as with PwnEscape, restarting your server if necessary. The kernel inside your VM is your job. Automatic security updates install it but don’t activate it. Check with ls /var/run/reboot-required and schedule the reboot yourself instead of putting it off for years. Eleven weeks of uptime are no badge of quality if an unpatched kernel is running underneath.

Snapshots are not a backup. They sit with the same provider on the same infrastructure and help you against a botched upgrade attempt, not against a lost account. How to create them in the SCP is covered in netcup Server Control Panel – the real backup belongs encrypted and away from the server, for example with restic.

Look at your invoice once a quarter. After the price round, existing contracts and new orders cost different amounts. If you want to grow, check the upgrade of your existing contract first – not the shopping cart.