What are we building?

By the end, Restic backs up your important data – app volumes, configurations, database dumps – end-to-end encrypted and deduplicated into a repository, ideally off-site (a second server or storage). You can restore individual files or whole snapshots at any time, automatically thin out old backups by a retention policy, and check integrity. Finally, everything runs automatically via a systemd timer and alerts you if a run fails to happen.

Tested with Restic 0.18 (the version from the Debian 13 package sources); upstream already has 0.19.x – how to update is in step 1. Restic always encrypts – there is no unencrypted repository.

Prerequisites

• A server (Debian 13) with the data you want to back up – e.g. the volumes and Compose files of your Docker apps.
• An off-site target for the backups. Restic speaks, among others:
  • SFTP – a second server or a storage box (easiest to start with),
  • S3-compatible – e.g. an object-storage bucket,
  • rclone – as a bridge to Backblaze B2, Google Drive and dozens more.
• Basic familiarity with the shell.

Step by step

Step 1: Install Restic

Restic is in the package sources and is updated with the system:

sudo apt update
sudo apt install -y restic

Check the version:

restic version

restic 0.18.0 compiled with go1.24.4 on linux/amd64

Step 2: Create the encrypted repository

A Restic repository is the encrypted storage location of your backups. It’s protected with a password – and this password does not belong in a script and not next to the repository. Put it in a file only root may read:

sudo install -d -m 700 /etc/restic
openssl rand -base64 32 | sudo tee /etc/restic/password > /dev/null
sudo chmod 600 /etc/restic/password

The openssl command generates a long random password and stores it under /etc/restic/password (the install command before it creates the directory, the chmod after it protects the file). Tell Restic via environment variables where the repository is and where the password is – here first an off-site target via SFTP:

export RESTIC_REPOSITORY="sftp:BACKUP_USER@YOUR_BACKUP_HOST:/backups/YOUR_SERVER"
export RESTIC_PASSWORD_FILE="/etc/restic/password"

Replace BACKUP_USER, YOUR_BACKUP_HOST and the path with your real target. If you want to practice locally first, use a folder instead: export RESTIC_REPOSITORY="/srv/restic-repo". The commands afterwards are identical – only the repository address differs.

You use other off-site targets via the same variable, only with a different prefix:

• S3-compatible: s3:https://ENDPOINT/BUCKET – plus the credentials as AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY in the environment (or in the environment file from step 7).
• rclone: rclone:REMOTE:path – the bridge to Backblaze B2, Google Drive and many more, once you’ve set up the rclone remote.

No matter which backend: encryption, deduplication and all the following commands stay the same.

Now initialize the repository (the example output shows the local practice repository – with the SFTP target, your sftp: address appears there instead):

restic init

created restic repository d29613209a at /srv/restic-repo

Please note that knowledge of your password is required to access
the repository. Losing your password means that your data is
irrecoverably lost.

Step 3: The first backup

Back up the directory with your data. The --tag helps with filtering later:

restic backup /root/backup-demo --tag demo

no parent snapshot found, will read all files

Files:           3 new,     0 changed,     0 unmodified
Dirs:            2 new,     0 changed,     0 unmodified
Added to the repository: 2.002 MiB (2.001 MiB stored)

processed 3 files, 2.000 MiB in 0:00
snapshot f16c6ffd saved

On the second run, Restic’s strength shows: it only backs up the changes (deduplication). If a file changes and you back up again:

using parent snapshot f16c6ffd
Files:           0 new,     1 changed,     2 unmodified
Added to the repository: 1.820 KiB (1.121 KiB stored)
processed 3 files, 2.000 MiB in 0:00
snapshot 0bb5e679 saved

Instead of 2 MiB again, only 1.1 KiB land in the repository – just the changed part.

What belongs in the backup? For Docker apps that’s three things – recipe, payload, DB:

• Compose files (your “recipe”) and .env: small but indispensable for rebuilding the stack.
• Bind mounts (./data:/…) live directly in the project folder – you back those up right along. Named volumes you’ll find under /var/lib/docker/volumes/<name>/_data; include the path.
• Databases never as a live file – a backup mid-write is potentially unusable. Instead create a consistent dump (pg_dump/mariadb-dump) and back that up (see step 7).

You exclude the unnecessary:

restic backup /opt --tag apps --exclude='*.log' --exclude='**/cache/**'

Step 4: Restore

A backup is only as good as its restore. First list the snapshots:

restic snapshots

ID        Time                 Host                  Tags        Paths              Size
---------------------------------------------------------------------------------------------
f16c6ffd  2026-07-16 20:52:35  v2200000000000000000  demo        /root/backup-demo  2.000 MiB
0bb5e679  2026-07-16 20:52:36  v2200000000000000000  demo        /root/backup-demo  2.000 MiB
---------------------------------------------------------------------------------------------
2 snapshots

Restore a complete snapshot to a target directory (use latest for the newest or a specific ID):

restic restore latest --target /root/restore-test

restoring snapshot 0bb5e679 of [/root/backup-demo] ... to /root/restore-test
Summary: Restored 5 files/dirs (2.000 MiB) in 0:00

If you only need one file, there are two ways – restore that specific path:

restic restore latest --target /tmp/wiederher --include /root/backup-demo/config.yaml

… or stream the file directly to standard output, without any detour:

restic dump latest /root/backup-demo/config.yaml > /tmp/config.yaml

To browse, you can even mount the repository as a filesystem (restic mount /mnt/backup, requires FUSE) and copy out what you need in the file manager – handy when you no longer know which snapshot the version you’re looking for is in.

Step 5: Check integrity

check verifies that the repository’s structure is intact:

restic check

load indexes
check all packs
check snapshots, trees and blobs
[0:00] 100.00%  2 / 2 snapshots
no errors were found

That checks the metadata, but not the actual data. So regularly read part of the real data along with it – e.g. 10% per run, i.e. everything over the course of weeks:

restic check --read-data-subset=10%

Step 6: Prune with a retention policy

Without pruning, the repository grows forever. forget applies a retention policy, --prune frees the storage of the removed snapshots:

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Applying Policy: keep 7 daily, 4 weekly, 6 monthly snapshots
keep 2 snapshots:
2 snapshots

This keeps the last 7 daily, 4 weekly and 6 monthly snapshots – a good default. The tiers interlock: fine resolution for the recent past (one per day), coarser the further back (one per week, then one per month). So, if in doubt, you can get close to the desired state without the repository growing unbounded. Older snapshots drop off automatically. --prune is the expensive part (it repacks data); on large repositories you often run it only once or twice a week, not on every backup.

Step 7: Automate everything (systemd timer)

A backup you have to start by hand is one you forget. Put the credentials in an environment file (so the service knows them):

# /etc/restic/restic.env
RESTIC_REPOSITORY=sftp:BACKUP_USER@YOUR_BACKUP_HOST:/backups/YOUR_SERVER
RESTIC_PASSWORD_FILE=/etc/restic/password

Then a wrapper script /usr/local/bin/restic-backup.sh – it first dumps the database (PostgreSQL example), backs up, prunes and finally reports success to Uptime Kuma (the push monitor as a “dead man’s switch”):

#!/usr/bin/env bash
set -euo pipefail
# 0) Ensure the target directory for the dump (otherwise the first run aborts)
mkdir -p /opt/dumps
# 1) Dump the database consistently (never back up the live DB file)
docker exec YOUR_DB_CONTAINER pg_dumpall -U postgres > /opt/dumps/db.sql
# 2) Backup
restic backup /opt/apps /opt/dumps --tag auto
# 3) Prune (retention)
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
# 4) Report success to Uptime Kuma
curl -fsS "https://status.YOUR_DOMAIN/api/push/YOUR_TOKEN?status=up&msg=restic+OK" > /dev/null

sudo chmod 700 /usr/local/bin/restic-backup.sh

The service loads the environment file and runs the script – /etc/systemd/system/restic-backup.service:

[Service]
Type=oneshot
EnvironmentFile=/etc/restic/restic.env
ExecStart=/usr/local/bin/restic-backup.sh

And the timer /etc/systemd/system/restic-backup.timer starts it nightly:

[Timer]
OnCalendar=*-*-* 02:30:00
Persistent=true

[Install]
WantedBy=timers.target

Persistent=true catches up a missed run (e.g. because the server was off at night) on the next start. Enable it:

sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer

Check with systemctl list-timers restic-backup.timer when the next run is due.

Step 8: Rehearse the worst case once

A backup you’ve never restored is just a hope. So deliberately run through a complete restore once – ideally on a different or freshly set-up server, so you also need the credentials (repository address and password) under real conditions:

export RESTIC_REPOSITORY="sftp:BACKUP_USER@YOUR_BACKUP_HOST:/backups/YOUR_SERVER"
export RESTIC_PASSWORD_FILE="/etc/restic/password"
restic snapshots
restic restore latest --target /tmp/dr-test

Then compare samples with the original (diff, file hashes) and boot the app from the restored data as a test. Only once that works do you know your backup holds up in an emergency – and that you’ll remember the procedure when it really counts.

When things go wrong

Maintenance & backups

• Test restores regularly – that’s the single most important point. A backup you’ve never restored is not a backup but a hope. Schedule a test restore into an empty directory monthly.
• 3-2-1 rule: at least 3 copies, on 2 different media, of which 1 is off-site. Restic covers the off-site piece – but “off-site” really means a different provider/location, not the same data center.
• Monitor backups: without monitoring, you only notice a dead backup in an emergency. The push call from step 7 to Uptime Kuma raises the alarm when a run fails to happen.
• Check integrity: run restic check --read-data-subset regularly so silent bit rot is caught before you need the data.
• Password/key management: keep the repository password separate from the server. For individual clients you can assign additional passwords with restic key add without sharing the main password.

What are we building?

By the end, Fail2ban 1.1 on your Debian 13 monitors the SSH logins and, after too many failed attempts, bans the attacking IP for a defined time – via a firewall rule. Your own IP is on a whitelist so this never hits you. You can view bans, set them manually and lift them again.

Prerequisites

• A hardened server (key login) with an active firewall
• Your own public IP – find it e.g. via wieistmeineip.de or curl -s ifconfig.me from your local machine

Step by step

Before we configure, three terms that explain the whole tool:

• Filter – a pattern that detects a “failed login” in the log (for SSH, Fail2ban brings this ready-made).
• Jail – connects a filter with a log source and the rules “how often in what time frame”. The sshd jail monitors the SSH logins.
• Action – what happens when it’s exceeded: by default a firewall rule that blocks the IP for bantime.

In short: filter detects failed attempts → jail counts them → action bans. Everything you configure below is one of these three knobs.

Step 1: Install Fail2ban

sudo apt update
sudo apt install -y fail2ban

Check the version:

fail2ban-client --version

Fail2Ban v1.1.0

Step 2: Your own configuration in jail.local

Create the file:

sudo nano /etc/fail2ban/jail.local

[DEFAULT]
# How long the ban lasts
bantime = 1h
# Time window in which the failed attempts count
findtime = 10m
# This many failed attempts are allowed, then a ban
maxretry = 5
# Your own IP(s) – will NEVER be banned
ignoreip = 127.0.0.1/8 ::1 YOUR_OWN_IP

[sshd]
enabled = true

Line by line:

• bantime = 1h – ban duration. For stubborn cases, see the escalation in step 5.
• findtime + maxretry – “5 failed attempts within 10 minutes → ban”.
• ignoreip – the most important line: enter your own IP here so you don’t lock yourself out. If you have a changing IP at home, better use access via a fixed point (a VPN later) instead of a broad allowance.
• [sshd] enabled = true – activates the SSH jail.

Step 3: Start and enable the service

sudo systemctl enable --now fail2ban

enable --now starts the service immediately and ensures it runs again automatically after a reboot. Check that it runs cleanly:

sudo systemctl status fail2ban

You should see active (running). After every change to jail.local, reload the configuration with sudo systemctl reload fail2ban.

Step 4: Check the status

This is how you see which jails are active:

sudo fail2ban-client status

Status
|- Number of jail:	1
`- Jail list:	sshd

And the details of the SSH jail:

sudo fail2ban-client status sshd

Status for the jail: sshd
|- Filter
|  |- Currently failed:	0
|  |- Total failed:	0
|  `- Journal matches:	_SYSTEMD_UNIT=ssh.service + _COMM=sshd
`- Actions
   |- Currently banned:	0
   |- Total banned:	0
   `- Banned IP list:

The Journal matches line confirms that Fail2ban reads the systemd journal. Currently banned rises as soon as someone gets it wrong too often.

Step 5: Manage bans – and escalate them

Manually unban an IP (e.g. when a colleague mistyped):

sudo fail2ban-client set sshd unbanip 203.0.113.45

Ban an IP immediately:

sudo fail2ban-client set sshd banip 203.0.113.45

Against especially stubborn attackers, an escalating ban time pays off: whoever comes back is banned for longer. Add to the [DEFAULT] block:

bantime.increment = true
bantime.maxtime = 1w

With that, Fail2ban doubles the ban time each time the same IP reoffends – up to a maximum of one week. After the change, sudo systemctl reload fail2ban.

When things go wrong

Maintenance & backups

• Keep an eye on bans: sudo fail2ban-client status sshd shows at any time how many IPs are currently banned. A look at the journal (journalctl -u fail2ban) shows the history.
• More jails: as soon as services with their own login are added (e.g. a web app), you can activate matching jails – following the same pattern as [sshd].
• Back up jail.local: your configuration is quickly restored but belongs in the backup of your server configuration.
• Outlook CrowdSec: Fail2ban protects your host based on your logs. The modern successor CrowdSec later adds collaborative intrusion prevention (shared block lists) to this – we build it in a dedicated recipe once the reverse proxy is up. To get started, Fail2ban is exactly right.

With that, the security foundation is complete: key login, two firewall layers (UFW + netcup firewall), automatic updates and active brute-force protection. Your server is now not just set up, but solidly secured.

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, 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?

We build a small stack step by step and, along the way, get to know the five building blocks that make up practically every compose.yaml: services (the containers), ports (reachability from outside), volumes (persistent data), networks (containers talking to each other) and environment variables (configuration). By the end you’ll understand why your data survives a down command – and when it doesn’t.

Tested with Docker Compose v5.3 (the docker compose plugin without a hyphen – not the old docker-compose v1 with a hyphen).

Prerequisites

• A hardened server with Docker installed and the Compose plugin
• The user is in the docker group (then you don’t need sudo before docker)

Step by step

Step 1: The first compose.yaml

A compose.yaml describes declaratively which containers should run – you say what you want, not how. Create a project folder; the folder name later becomes the prefix of all containers:

mkdir -p ~/compose-demo/site && cd ~/compose-demo

Create a small HTML page that we’ll serve in a moment:

echo '<h1>Hallo aus der Serverküche</h1>' > site/index.html

And now the central file compose.yaml:

services:
  web:
    image: nginx:1.31
    ports:
      - "8080:80"
    volumes:
      - ./site:/usr/share/nginx/html:ro
    restart: unless-stopped

Line by line:

• services: – the top level. Every entry below it is a container.
• web: – a freely chosen service name. Remember it, it later also becomes the hostname on the internal network (step 3).
• image: nginx:1.31 – the container image with a fixed tag. Never use latest: latest changes under you and makes errors unreproducible.
• ports: - "8080:80" – format HOST:CONTAINER. Port 80 in the container is mapped to 8080 on the server. The server is always on the left.
• volumes: - ./site:...:ro – the local site folder is mounted into the web root, :ro = read-only. More on this in step 2.
• restart: unless-stopped – the container restarts automatically after a reboot or crash, unless you stopped it yourself. The sensible default for server services. The alternatives: no (never automatically – the default), always (restarts even after a manual stop, rarely wanted) and on-failure (only after a crash with an error code). For the vast majority of services, unless-stopped is exactly right.

Start the stack:

docker compose up -d

-d means detached (in the background). The first time, Docker downloads the image; after that you see at the end:

 Network compose-demo_default  Created
 Container compose-demo-web-1  Started

Check the status:

docker compose ps

NAME                 IMAGE        COMMAND                  SERVICE   CREATED          STATUS          PORTS
compose-demo-web-1   nginx:1.31   "/docker-entrypoint.…"   web       10 seconds ago   Up 9 seconds    0.0.0.0:8080->80/tcp, [::]:8080->80/tcp

The container is called compose-demo-web-1 – project folder + service + number. Test:

curl localhost:8080

<h1>Hallo aus der Serverküche</h1>

Works. You see a service’s logs with docker compose logs web (or -f to follow).

Step 2: Volumes – where your data really lives

Containers are ephemeral: if you delete a container, everything written inside the container is gone. So that data survives this, there are two kinds of volumes:

• Bind mount (./site:/usr/share/nginx/html): a folder from your server is mounted into the container. Ideal for config files you edit yourself.
• Named volume (webdata:/var/lib/...): storage managed by Docker. Ideal for database data – performant and cleanly separated from the host.

In step 1 we used a bind mount. For database-like services it looks like this – change compose.yaml as a test:

services:
  web:
    image: nginx:1.31
    volumes:
      - webdata:/usr/share/nginx/html

volumes:
  webdata:

Named volumes must additionally be declared at the top level under volumes:. After docker compose up -d the volume appears:

docker volume ls

DRIVER    VOLUME NAME
local     compose-demo_webdata

Now comes the crucial point:

docker compose down
docker volume ls

 Container compose-demo-web-1  Removed
 Network compose-demo_default  Removed
DRIVER    VOLUME NAME
local     compose-demo_webdata

docker compose down removes the container and network – the volume stays. This is exactly why your database contents survive an update. Remember the counterpart:

Step 3: Networks – containers talking to each other

Compose automatically creates one network per project (seen above: compose-demo_default). All services in it reach each other via their service name as the hostname – no fiddling with IPs. That’s the reason why, in app tutorials, the application simply reaches its database under db.

As proof, a second service that talks to the first:

services:
  web:
    image: nginx:1.31
    volumes:
      - ./site:/usr/share/nginx/html:ro

  ping:
    image: curlimages/curl:8.21.0
    depends_on:
      - web
    command: ["curl", "-s", "http://web"]

• depends_on: - web – Compose starts web before ping. (Careful: this only waits for the start, not for “fully booted” – that’s what healthchecks are for, step 4.)
• command: – overrides the image’s default command. ping calls http://web – web is the service name from the same file.

Run only the ping service once:

docker compose run --rm ping

<h1>Hallo aus der Serverküche</h1>

ping reached web purely by name – without any port mapping. Remember: you only need ports: to make a service reachable from outside (the internet). Containers talk to each other over the internal network – that’s why we later deliberately run databases without ports:.

So far, every network lives inside a Compose project. But sometimes containers from different projects should talk to each other – the classic example is a reverse proxy sitting in front of many independent app stacks. For that there’s the external network: one you create once by hand and that several Compose projects then share:

docker network create proxy

In the compose.yaml you then don’t create it again, but reference the already existing network with external: true:

services:
  web:
    image: nginx:1.31
    networks:
      - proxy

networks:
  proxy:
    external: true

external: true tells Compose: “This network already exists – do not create it and do not delete it on down.” If the network is missing, up aborts with network proxy declared as external, but could not be found – then you forgot the docker network create. This very pattern – a shared proxy network plus external: true – is the basis of the Traefik tutorial, with which every app later gets its domain and its HTTPS.

Step 4: Configuration – environment variables, .env and healthchecks

Almost every application is configured via environment variables. Two ways:

services:
  app:
    image: beispiel/app:1.0
    environment:
      - TZ=Europe/Berlin
      - APP_PORT=3000

Secrets (passwords, tokens) do not belong in the compose.yaml, but in a .env file in the same folder. Compose reads it automatically:

echo "DB_PASSWORD=EIN_LANGES_ZUFALLSPASSWORT" > .env

services:
  db:
    image: postgres:18
    environment:
      - POSTGRES_PASSWORD=${DB_PASSWORD}

This is how you check whether Compose understands your file and inserts the .env values correctly – without starting anything:

docker compose config

config resolves all variables and prints the finished, normalized configuration:

name: compose-demo
services:
  db:
    environment:
      POSTGRES_PASSWORD: EIN_LANGES_ZUFALLSPASSWORT
    image: postgres:18
    networks:
      default: null

If your actual value appears there instead of ${DB_PASSWORD}, the .env is working. If you only need a quick syntax check without the whole output, use docker compose config --quiet – if nothing comes back (exit code 0), the file is valid. That’s also your first move for YAML errors (see below).

A healthcheck tells Docker when a service is really ready – the basis for dependent services only starting then:

services:
  db:
    image: postgres:18
    environment:
      - POSTGRES_PASSWORD=${DB_PASSWORD}
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 10s
      timeout: 5s
      retries: 5

  app:
    image: beispiel/app:1.0
    depends_on:
      db:
        condition: service_healthy

With condition: service_healthy, app only starts once the healthcheck of db is green – the most common “why won’t my app connect to the database?” disappears with it. The four healthcheck fields mean: test is the command that runs in the container (exit code 0 = healthy), interval the spacing between checks, timeout how long a check may take, and retries how many consecutive failures are needed before the container counts as unhealthy. The current state is shown by the STATUS column of docker compose ps as (healthy) or (unhealthy).

Step 5: The operations toolbox

You need these commands daily – always run them in the project folder:

docker compose up -d        # start / apply changes
docker compose ps           # status of the services
docker compose logs -f web  # follow logs live (Ctrl+C only ends the viewing)
docker compose exec web sh  # shell in the running container
docker compose restart web  # restart a single service
docker compose stop         # halt without removing container/network
docker compose pull         # fetch new image versions
docker compose down         # stop and remove the stack (volumes stay)

Almost all commands can be restricted to one service by appending its name (docker compose logs -f web, docker compose restart web) – without a name they apply to the whole stack. The difference between stop and down: stop only halts the containers (start continues), down removes them along with the network (the named volumes stay in both cases).

An update almost always follows the same pattern: bump the tag in the compose.yaml → docker compose pull → docker compose up -d. Compose only replaces the containers whose image has changed.

Step 6: All together – a realistic app stack

This is the pattern you’ll encounter again and again in the app tutorials: an application plus its database. This file bundles everything from steps 1–4 – read it once in full, and you’ll have understood 90% of every later compose.yaml:

services:
  app:
    image: beispiel/app:1.4          # fixed version, no latest
    ports:
      - "8080:3000"                  # only the app is reachable from outside
    environment:
      - TZ=Europe/Berlin
      - DATABASE_URL=postgres://app:${DB_PASSWORD}@db:5432/app
    volumes:
      - appdata:/data                # persistent app data (named volume)
    depends_on:
      db:
        condition: service_healthy   # starts only once db is ready
    restart: unless-stopped

  db:
    image: postgres:18
    environment:
      - POSTGRES_USER=app
      - POSTGRES_PASSWORD=${DB_PASSWORD}
      - POSTGRES_DB=app
    volumes:
      - dbdata:/var/lib/postgresql/data   # the actual database files
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U app"]
      interval: 10s
      timeout: 5s
      retries: 5
    restart: unless-stopped
    # no ports: – the database is reachable ONLY internally via the name "db"

volumes:
  appdata:
  dbdata:

Three design decisions worth remembering:

1. Only app has ports:. The database needs no open host port – the app reaches it internally via the hostname db (the DATABASE_URL points exactly there). A port that isn’t published is a port nobody from the internet can attack.
2. Two separate named volumes. App data and database files live cleanly separated – that makes later backups and restores traceable.
3. Password only as ${DB_PASSWORD}. The actual value is in the .env, not in this file. The same compose.yaml can thus be shared safely.

This very skeleton – app facing outward, database internal only, data in named volumes, secrets in the .env – repeats in Nextcloud, Vaultwarden, Paperless and most other recipes.

When things go wrong

Maintenance & backups

• Maintain image tags: Fixed tags (nginx:1.31) mean you apply updates deliberately by bumping the tag. That’s intended – this way you decide when an update comes, instead of being surprised. Expect a monthly look at your services’ release notes.
• What belongs in the backup? Not the containers – they can be rebuilt from the compose.yaml at any time. What you must back up are the named volumes (or bind-mount folders), the compose.yaml and the .env. We build a well-thought-out off-site backup of this data with encrypted Restic backups.
• Cleanup: docker compose down when tearing down a stack; you remove unused images with docker image prune. Named volumes are never deleted automatically – that’s by design.

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.