What are we building?

By the end, your Debian 13 automatically pulls security updates daily and installs them without your involvement. You decide whether and when the server reboots for necessary kernel updates, and you know how to verify that the automation really kicks in. What gets automated are security updates and the conservative stable point releases; larger upgrades of your other software stay deliberately in your hands.

Prerequisites

• A hardened server with an active firewall

Step by step

Step 1: Install the package

sudo apt update
sudo apt install -y unattended-upgrades apt-listchanges

apt-listchanges shows the changelogs on updates – useful if you later do check manually what changed.

Step 2: Enable the automation

The simplest way to switch on the daily run:

sudo dpkg-reconfigure -plow unattended-upgrades

Choose Yes in the dialog. That creates the file /etc/apt/apt.conf.d/20auto-upgrades with this content:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

The 1 means “daily”: update package lists and run unattended upgrades. It’s triggered via the systemd timers apt-daily.timer (package lists) and apt-daily-upgrade.timer (upgrade run) – no separate cron job needed.

Step 3: Define what gets updated

Take a look at /etc/apt/apt.conf.d/50unattended-upgrades:

sudo nano /etc/apt/apt.conf.d/50unattended-upgrades

On Debian 13, three sources are active in the Origins-Pattern block by default:

Unattended-Upgrade::Origins-Pattern {
  "origin=Debian,codename=${distro_codename},label=Debian";
  "origin=Debian,codename=${distro_codename},label=Debian-Security";
  "origin=Debian,codename=${distro_codename}-security,label=Debian-Security";
};

The two Debian-Security lines ensure timely security updates – the actual purpose. The first line (label=Debian) covers the conservative stable updates that only arrive with Debian point releases; so it’s not a risky rolling update, but well-seasoned. If you really want only security updates, comment out the first line with //.

Two options are worth setting explicitly here. Clean up old kernels/packages automatically, otherwise /boot eventually fills up (Remove-Unused-Kernel-Packages is already the default in code, but only appears commented out in the file – set explicitly, the decision is documented):

Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
Unattended-Upgrade::Remove-Unused-Dependencies "true";

And the most important point – the automatic reboot:

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";

For the automatic reboot to be able to trigger on Debian at all, one building block is still missing: unattended-upgrades only reboots if the marker file /var/run/reboot-required exists – and Debian 13 does not create it on kernel updates by default (the responsible hook comes from an Ubuntu helper package that doesn’t exist in Debian; only individual packages like dbus set the file themselves). A two-liner closes the gap:

sudo tee /etc/kernel/postinst.d/zz-reboot-required > /dev/null <<'EOF'
#!/bin/sh
touch /var/run/reboot-required
EOF
sudo chmod +x /etc/kernel/postinst.d/zz-reboot-required

The hook runs after every kernel installation and sets the marker file. From now on, both Automatic-Reboot and the manual check of /var/run/reboot-required work reliably – without the hook, the automatic reboot would simply never trigger on kernel updates.

Step 4: Do a dry run

Test what unattended-upgrades would do, without a real installation:

sudo unattended-upgrade --dry-run --debug

In the debug output, this line is decisive (on a fresh Debian 13, shortened):

Allowed origins are: origin=Debian,codename=trixie,label=Debian, origin=Debian,codename=trixie,label=Debian-Security, origin=Debian,codename=trixie-security,label=Debian-Security
[...]
No packages found that can be upgraded unattended and no pending auto-removals

The Debian-Security sources must appear there. If something is listed, the configuration applies; if the run finds nothing to do (as above), there’s simply no security update pending right now.

When things go wrong

Maintenance & backups

• Still check anyway: automation doesn’t replace attention. Take a monthly look at the log /var/log/unattended-upgrades/unattended-upgrades.log and occasionally run sudo apt update && sudo apt upgrade for the non-security-critical updates.
• Plan for reboots: if you use automatic reboots, make sure your services survive a reboot cleanly (restart: unless-stopped in Docker Compose if you run containers).
• No dedicated backup needed, but note whether you enabled automatic reboots – it later explains why the server was briefly gone at night.

What are we building?

By the end, your domain (YOUR_DOMAIN) points to your server IP via an A record (IPv4) and – if your server has IPv6 – an AAAA record, including www. You can verify this yourself with dig and understand why a change isn’t always visible immediately. Optionally you also set up reverse DNS (PTR) – important as soon as your server sends emails. This lays the foundation for all publicly reachable services.

Prerequisites

• A set-up server with a known public IP address
• A registered domain (at netcup, another registrar, or included in your hosting package)
• Access to the DNS management of your domain (at netcup: the customer account CCP)

Step by step

Step 1: Find the server IP

Connect via SSH and display the public IP addresses:

ip -4 addr show scope global
ip -6 addr show scope global

The IPv4 address is after inet (e.g. 203.0.113.10), any IPv6 address after inet6 (does not start with fe80::, that would only be link-local). Alternatively you’ll find both in the netcup Server Control Panel (SCP) in the server overview.

Step 2: Create A and AAAA records

Open the DNS management of your domain. There you enter resource records – the mapping of names to addresses. Create:

• @ stands for the domain itself (YOUR_DOMAIN), www for the subdomain www.YOUR_DOMAIN.
• A points to an IPv4 address, AAAA to an IPv6 address. The name “AAAA” comes from an IPv6 address being four times as long as an IPv4 address.
• For individual services you can later create specific subdomains (e.g. cloud, git) – following the same pattern.

Step 3: Understand TTL and propagation

Every record has a TTL (Time To Live) in seconds – e.g. 3600 (one hour). It tells resolvers worldwide how long they may cache the answer before asking again.

From this follows the notorious propagation: if you change a record, some resolvers see the new value immediately, others only after the old TTL expires. “DNS propagating” means nothing more than these caches expiring one by one. In everyday use, reckon with minutes up to an hour, occasionally longer.

Step 4: Verify with dig

Wait a few minutes, then check from your own machine where the domain points. dig is the standard tool for that:

dig +noall +answer YOUR_DOMAIN A

This is what a correct answer looks like (example for this site’s real domain):

serverkueche.de.	600	IN	A	46.38.243.234

The number 600 is the remaining TTL, followed by the target IP. For IPv6, do the same with AAAA. If you only want it very brief:

dig +short YOUR_DOMAIN

46.38.243.234

If your correct server IP appears, the domain is connected. Also check www:

dig +short www.YOUR_DOMAIN

Here too, the same server IP as for the apex should come back as a plain line:

46.38.243.234

Step 5: Set reverse DNS (PTR) – optional but recommended

The A record answers the question “Which IP belongs to this name?”. Reverse DNS – the PTR record – answers the opposite direction: “Which name belongs to this IP?”. For a plain website you don’t need this. But as soon as your server sends emails – even if only notifications from Nextcloud, Gitea & co. – it’s practically mandatory: the receiving mail servers reject mail from IPs without a matching PTR or treat it as spam.

The crucial difference from the previous records: you enter the PTR not at your DNS provider, but where the IP address is managed – i.e. at your VPS provider. At netcup you’ll find it in the Server Control Panel (SCP) in the Netzwerk (Network) tab – there’s a Reverse DNS field per address (IPv4 and IPv6). Enter a hostname there that points to the same server via an A record – either directly YOUR_DOMAIN or your own name like server.YOUR_DOMAIN (shown as an example in the screenshot) – and click Save.

If you have IPv6, set the PTR for both addresses – IPv4 and IPv6. The IPv6 PTR is easily forgotten, and that’s exactly what some mail servers trip over after all.

You can check the result with dig and the -x option (reverse lookup) – for IPv6 do the same with YOUR_SERVER_IPV6:

dig +short -x YOUR_SERVER_IPV4

Your hostname with a trailing dot should come back:

serverkueche.de.

If nothing comes back, or still the provider’s default name (at netcup something like v220….bestsrv.de), the PTR is not (correctly) set yet – or, as with every DNS entry, the change still needs some time.

When things go wrong

Maintenance & backups

• DNS is low-maintenance. Once set correctly, the A/AAAA record rarely changes. Exception: a server migration – then the TTL trick from step 3 applies.
• Document your records. Keep track somewhere of which names (@, www, cloud, …) point to which IP. With several services you otherwise lose the overview.
• No classic backup needed, but a screenshot or export of your DNS zone doesn’t hurt in case you switch providers.
• Carry reverse DNS along on an IP change. If the server gets a new IP (migration, new product), you have to reset the PTR at the VPS provider – it’s tied to the IP, not the domain.

Your domain now points to the server – with that, the last prerequisite is met for serving services publicly with automatic HTTPS via the reverse proxy Traefik.

What are we building?

By the end, UFW runs on your Debian 13 with the base rule “block all incoming”, with only SSH (your access) plus HTTP/HTTPS (ports 80/443, which you’ll need later for Traefik) open. Outgoing connections stay allowed. The key part: we proceed in a way that ensures you don’t lock yourself out.

Prerequisites

• A hardened server with a sudo user
• You know which port your SSH runs on (default: 22)

Step by step

Step 1: Install UFW

sudo apt update
sudo apt install -y ufw

Check the version – UFW is inactive at first, which is intended:

ufw version

Step 2: Define the base rules

First the default direction: deny everything incoming, allow everything outgoing.

sudo ufw default deny incoming
sudo ufw default allow outgoing

Default incoming policy changed to 'deny'
(be sure to update your rules accordingly)
Default outgoing policy changed to 'allow'
(be sure to update your rules accordingly)

These rules don’t take effect yet – UFW is still inactive. So the exceptions come now, before we switch it on.

Step 3: Allow SSH – first, or you’ll lock yourself out

If your SSH runs on the default port 22 (and openssh-server is installed), there’s a ready-made profile for it:

sudo ufw allow OpenSSH

If you changed the SSH port (e.g. to 2222), allow exactly that port instead:

sudo ufw allow 2222/tcp

Step 4: Allow HTTP and HTTPS

For the later reverse proxy with Traefik you need the web ports. Open them right away:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

UFW confirms each rule with Rules updated and Rules updated (v6) (the IPv6 variant).

Step 5: Activate the firewall and check it

Now switch it on:

sudo ufw enable

Command may disrupt existing ssh connections. Proceed with operation (y|n)? y
Firewall is active and enabled on system startup

Check the result:

sudo ufw status verbose

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22/tcp (OpenSSH)           ALLOW IN    Anywhere
80/tcp                     ALLOW IN    Anywhere
443/tcp                    ALLOW IN    Anywhere
22/tcp (OpenSSH (v6))      ALLOW IN    Anywhere (v6)
80/tcp (v6)                ALLOW IN    Anywhere (v6)
443/tcp (v6)               ALLOW IN    Anywhere (v6)

Status: active and your three allowances – done. To be safe, test in a second SSH session that you can still connect before closing the first one.

When things go wrong

Maintenance & backups

• View and delete rules: sudo ufw status numbered numbers all rules; sudo ufw delete 3 removes rule 3. That’s how you tidy up when a service goes away.
• New services: For every additional public port, one targeted rule – never “just open everything”. What doesn’t need to be open stays closed.
• No backup needed, but note down your allowances (or keep them in the same document as your DNS records). The rule set is retyped in seconds.
• Know the limits: UFW protects the host, but not against the Docker gap above. An upstream perimeter firewall like the netcup firewall in the SCP complements UFW into two layers that secure each other – ideal once containers with open ports are running.

What are we building?

By the end, the current Docker Engine with the Compose plugin runs on your Debian 13, installed from the official Docker repository. That has two advantages over the Debian package docker.io: more current versions with timely security updates, and the official docker compose that all Compose recipes here build on.

Prerequisites

• A hardened server with a sudo user

Step by step

Step 1: Set up the repository key

First, install the tools needed to verify the Docker repository:

sudo apt update
sudo apt install -y ca-certificates curl

Then create the keyring directory and download Docker’s GPG key – apt uses it later to check that the packages really come from Docker:

sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc

Step 2: Add the Docker package source

Add the Docker repository to your package sources. The command detects the architecture and Debian version automatically, so you can copy it unchanged:

echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/debian $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

Step 3: Install Docker

Refresh the package lists (now including the Docker repository) and install the Engine together with the Compose plugin:

sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin

Check that the service is running:

sudo systemctl status docker

You should see active (running). A quick smoke test:

sudo docker run --rm hello-world

The output Hello from Docker! confirms that the installation works.

Step 4: Use Docker without sudo

Add your user to the docker group so you don’t have to prefix every command with sudo:

sudo usermod -aG docker $USER

After that, docker ps works without sudo and shows a (still empty) container list.

When things go wrong

Maintenance & backups

• Updates: Docker updates along with the normal sudo apt update && sudo apt upgrade – one reason we use the official repository. When the Engine is updated, running containers restart briefly (or stop until you start them again) – plan for that.
• Cleanup: Unused images and build leftovers pile up quickly. docker system df shows the usage, docker system prune cleans up (careful: it also removes stopped containers).
• Backups: The actual data of your applications will later live in volumes or bind mounts – we build the backup strategy for that with encrypted Restic backups and in the individual application tutorials.

What are we building?

By the end you log in with an SSH key instead of a password, and neither root login nor password login is possible from outside. This makes the automated password-guessing attacks that hit every publicly reachable server around the clock run completely into the void. Tested with OpenSSH on Debian 13.

Prerequisites

• A set-up server with a sudo user
• Access to the VNC console in the netcup SCP as a safety line in case you lock yourself out

Step by step

Step 1: Generate an SSH key pair

If you don’t have a key yet, generate an Ed25519 key pair on your own machine (not on the server!):

ssh-keygen -t ed25519

You can accept the suggested storage location with Enter. Set a passphrase – it protects the key if your machine falls into the wrong hands. Two files are created: ~/.ssh/id_ed25519 (private, stays with you) and ~/.ssh/id_ed25519.pub (public, goes on the server).

Step 2: Transfer the public key

ssh-copy-id appends your public key to the ~/.ssh/authorized_keys file of your server user – with the correct file permissions:

ssh-copy-id koch@YOUR_SERVER_IP

Test right afterwards that key login works:

ssh koch@YOUR_SERVER_IP

You should now be logged in without a server password (only the passphrase of your key may be requested). Only once that works do we continue – in the next step we disable password login.

Step 3: Disable password login and root login

Open the SSH server configuration:

sudo nano /etc/ssh/sshd_config

Set (or uncomment) these two lines:

PermitRootLogin no
PasswordAuthentication no

PermitRootLogin no blocks direct root login completely, PasswordAuthentication no allows only key logins.

Step 4: Test the configuration and restart SSH

Check the configuration for syntax errors before you restart – a typo would otherwise take the SSH service down:

sudo sshd -t

No output means: all good. Then apply it:

sudo systemctl restart ssh

To verify: sudo systemctl status ssh should show active (running), and a login attempt as root must now be rejected with Permission denied (publickey).

When things go wrong

Maintenance & backups

• Back up the private key: Without ~/.ssh/id_ed25519 you can only reach the server via the VNC console. Back up the key encrypted (e.g. in a password manager) or add a second key from another device to authorized_keys.
• Keep an eye on logins: sudo journalctl -u ssh --since today shows you all login attempts. Failed attempts on port 22 are normal and, thanks to the key requirement, harmless – you can automatically ban such bots later with Fail2ban.
• Updates: OpenSSH gets its security updates through the normal apt upgrade – so keep the server up to date, ideally automated.

What are we building?

By the end of this tutorial, your VPS runs a current Debian 13 with all security updates, and you work with your own user with sudo rights instead of permanently as root. That’s the foundation for all the other recipes in the Serverküche – from hardening SSH to your first application.

Prerequisites

• An ordered netcup server with the credentials from your customer account
• A terminal on your machine (Linux/macOS) or an SSH client like PuTTY (Windows)

Not sure which server size you even need? The server calculator estimates the RAM and CPU you’ll need for your planned services and suggests a matching netcup plan.

Step by step

Step 1: Log in via SSH

Log in with your server’s IP address as root. You’ll find the IP and the password in the credentials from your customer account:

ssh root@YOUR_SERVER_IP

On the very first login, SSH asks whether you want to trust the server:

The authenticity of host 'YOUR_SERVER_IP' can't be established.
...
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Answer yes – your machine remembers the server from now on. After that you land on a prompt like root@v12345:~#.

Step 2: Update the system

Freshly delivered images are rarely up to date. So the first thing to do is fetch all updates – security updates in particular should never wait:

apt update && apt upgrade -y

apt update fetches the current package lists, apt upgrade -y installs all available updates without prompting.

Step 3: Create a sudo user

Don’t work as root permanently: a typo with full rights can wreck the entire system, and having your own user is the prerequisite for disabling root login completely later. Create a user – we’ll call it koch (“cook”) here, but you can pick any name:

adduser koch

You’ll be asked for a password and a few optional details (you can skip the details with Enter). After that, give the user sudo rights:

usermod -aG sudo koch

Step 4: Test the new user

Check in a new terminal session (keep the root session open!) that login and sudo work:

ssh koch@YOUR_SERVER_IP
sudo whoami

After entering your password, sudo whoami should return root. From now on you continue working with this user.

When things go wrong

Maintenance & backups

• Updates: You should schedule sudo apt update && sudo apt upgrade at least weekly – or automate security updates with unattended-upgrades.
• Snapshots: Create a snapshot in the netcup Server Control Panel (SCP) before bigger changes. It’s your safety line while you don’t have a proper backup strategy yet – but a snapshot does not replace a backup outside the server.
• Credentials: Keep the root password safe (password manager). Via the VNC console in the SCP you can still reach the server even when SSH is stuck.

You’ll find both in the server overview of the SCP: the VNC console is under the “Bildschirm” (Display) tab, and the remaining snapshot quota is shown in the status block.