A small website on a VPS: the NAT catch, Caddy, and what 1 GiB actually servesEine kleine Website auf einem VPS: die NAT-Falle, Caddy und was 1 GiB tatsächlich bedient

What "a small website" actually means hereWas „eine kleine Website“ hier tatsächlich bedeutet

This is for a static site, a blog built by a generator, or a light PHP or Node app — the kind of thing a single process and a few hundred megabytes of RAM handles without strain. It is not a guide to running a cluster or a site built to survive a front-page traffic spike; a 1 GiB VPS is the wrong machine for that regardless of configuration.Das hier ist für eine statische Seite, einen mit einem Generator gebauten Blog oder eine leichte PHP- oder Node-App — die Art von Sache, die ein einzelner Prozess und ein paar hundert Megabyte RAM ohne Anstrengung stemmen. Es ist keine Anleitung zum Betrieb eines Clusters oder einer Seite, die einen Traffic-Spike von einer stark frequentierten Startseite überstehen soll; dafür ist ein 1-GiB-VPS die falsche Maschine, egal wie du sie konfigurierst.

The part easy to miss coming from a managed host: a website is not a bot or a scheduled job. A Discord bot or a cron-triggered scraper only ever makes outbound connections, so it runs happily behind almost any network setup. A website's job is the opposite — a stranger's browser makes an inbound connection to you, on port 80 or 443, at a hostname that resolves to your address.Der Teil, den du leicht übersiehst, wenn du von einem Managed-Host kommst: Eine Website ist kein Bot und kein geplanter Job. Ein Discord-Bot oder ein per Cron ausgelöster Scraper baut ausschließlich ausgehende Verbindungen auf und läuft deshalb problemlos hinter fast jedem Netzwerk-Setup. Bei einer Website ist es genau umgekehrt — der Browser eines Fremden baut eine eingehende Verbindung zu dir auf, auf Port 80 oder 443, unter einem Hostnamen, der zu deiner Adresse auflöst.

Read this before you buy: the NAT IPv4 catchLies das, bevor du kaufst: die NAT-IPv4-Falle

Budget VPS plans commonly hand out NAT IPv4 — one shared public address with a small, fixed list of forwarded ports — rather than an address that is yours alone. For a lot of workloads that is invisible. For a website it is not: a browser typing https://example.com always asks for port 443 on whatever address that hostname resolves to, and there is no way to tell it to use port 41022 instead. Unlike a VPN or a bot's control panel, a website's port is not negotiable.Günstige VPS-Tarife geben dir oft NAT-IPv4 — eine geteilte öffentliche Adresse mit einer kleinen, festen Liste weitergeleiteter Ports — statt einer Adresse, die nur dir gehört. Für viele Workloads ist das unsichtbar. Für eine Website nicht: Ein Browser, der https://example.com eingibt, fragt immer nach Port 443 auf der Adresse, zu der dieser Hostname auflöst, und es gibt keine Möglichkeit, ihm stattdessen Port 41022 zu sagen. Anders als bei einem VPN oder dem Kontrollpanel eines Bots ist der Port einer Website nicht verhandelbar.

Two honest ways through it:Zwei ehrliche Wege hindurch:

• Get a dedicated IPv4. With an address of your own, 80 and 443 belong to you and Caddy's automatic HTTPS works exactly as documented. On our plans that is available on request by e-mail, not as a self-service add-on.Hol dir eine dedizierte IPv4. Mit einer eigenen Adresse gehören dir 80 und 443, und Caddys automatisches HTTPS funktioniert genau wie dokumentiert. Bei unseren Tarifen ist das auf Anfrage per E-Mail verfügbar, nicht als Self-Service-Add-on.
• Use Cloudflare Tunnel. cloudflared runs on your VPS and opens an outbound connection to Cloudflare's network, which routes visitor traffic back down that same connection. No inbound port is involved, so NAT is irrelevant — Cloudflare's edge holds the public IP and the certificate.Nutze Cloudflare Tunnel. cloudflared läuft auf deinem VPS und öffnet eine ausgehende Verbindung zu Cloudflares Netzwerk, das den Besucher-Traffic über genau diese Verbindung zurückschickt. Kein eingehender Port ist beteiligt, NAT spielt also keine Rolle — Cloudflares Edge hält die öffentliche IP und das Zertifikat.

The dedicated IPv4 route is plainer if you already have it; Cloudflare Tunnel is the honest answer if you do not, at no extra cost. Read NAT IPv4 vs a dedicated IP and NAT IPv4, ports and forwarding before you decide which situation you are in.Die dedizierte IPv4 ist der einfachere Weg, wenn du sie schon hast; Cloudflare Tunnel ist die ehrliche Antwort, wenn nicht, und das ohne Mehrkosten. Lies NAT IPv4 vs. dedizierte IP und NAT IPv4, Ports und Weiterleitung, bevor du entscheidest, in welcher Situation du dich befindest.

Step 1: a clean machineSchritt 1: eine saubere Maschine

Deploy an Ubuntu 24.04 LTS VPS and do the ordinary hardening before anything else touches it: a non-root user with your SSH key on it, password authentication turned off, and a firewall that defaults to deny with only SSH, 80 and 443 allowed through. connect to your VPS over SSH walks through the connection itself.Setze einen Ubuntu-24.04-LTS-VPS auf und erledige die übliche Härtung, bevor irgendetwas sonst ihn berührt: einen Non-Root-User mit deinem SSH-Key darauf, Passwort-Authentifizierung deaktiviert und eine Firewall, die standardmäßig blockiert und nur SSH, 80 und 443 durchlässt. Über SSH mit deinem VPS verbinden geht die Verbindung selbst durch.

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

Going the dedicated-IPv4 route, point an A record (and AAAA if you have IPv6) at that address now and let DNS settle before Caddy fetches a certificate. Going the Cloudflare Tunnel route, skip this — DNS gets created for you when you route the tunnel in Step 5.Gehst du den Weg der dedizierten IPv4, richte jetzt einen A-Record (und AAAA, falls du IPv6 hast) auf diese Adresse und lass DNS sich setzen, bevor Caddy ein Zertifikat holt. Gehst du den Weg über Cloudflare Tunnel, überspringe das — DNS wird für dich angelegt, wenn du den Tunnel in Schritt 5 routest.

Step 2: get your files onto the boxSchritt 2: deine Dateien auf die Maschine bringen

Pick a directory outside your home folder so permissions are predictable, and put a dedicated system user on it rather than deploying as root:Wähle ein Verzeichnis außerhalb deines Home-Ordners, damit die Berechtigungen vorhersehbar bleiben, und setze einen dedizierten Systembenutzer darauf, statt als Root zu deployen:

sudo mkdir -p /var/www/example.com
sudo useradd --system --no-create-home --shell /usr/sbin/nologin deploy
sudo chown -R deploy:deploy /var/www/example.com
sudo usermod -aG deploy youruser
sudo chmod -R 2775 /var/www/example.com

chown alone leaves the directory at its default 755, so deploy owns it but youruser can't write there yet — the rsync below would fail. The group-add and 2775 (setgid) fix that; a fresh SSH connection, which rsync always opens, picks it up immediately.chown allein belässt das Verzeichnis bei seinem Standard 755, sodass deploy es zwar besitzt, aber youruser dort noch nicht schreiben kann — das rsync unten würde fehlschlagen. Der Gruppen-Zusatz und 2775 (Setgid) beheben das; eine frische SSH-Verbindung, die rsync immer öffnet, übernimmt das sofort.

For a static site, rsync the built output straight from your machine:Bei einer statischen Seite rsyncst du die gebauten Dateien direkt von deiner Maschine:

rsync -avz --delete ./dist/ youruser@vps-address:/var/www/example.com/

For anything with a build step, git clone the repository onto the VPS and build there, or build locally and rsync only the output — pick one path and stay consistent.Bei allem mit einem Build-Schritt klonst du das Repository mit git clone auf den VPS und baust dort, oder du baust lokal und rsync'st nur die Ausgabe — entscheide dich für einen Weg und bleib dabei konsistent.

Step 3: automatic HTTPS with CaddySchritt 3: automatisches HTTPS mit Caddy

Install Caddy from its own repository rather than an outdated distro package:Installiere Caddy aus seinem eigenen Repository statt aus einem veralteten Distro-Paket:

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' \
  | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' \
  | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo chmod o+r /usr/share/keyrings/caddy-stable-archive-keyring.gpg
sudo chmod o+r /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install -y caddy

For a pure static site, the whole configuration is this, in /etc/caddy/Caddyfile:Für eine reine statische Seite ist das hier die gesamte Konfiguration, in /etc/caddy/Caddyfile:

example.com {
    root * /var/www/example.com
    file_server
    encode gzip
}

Reload it and Caddy takes care of the certificate on its own, with no certbot step and no renewal cron job:Lade neu, und Caddy kümmert sich von selbst um das Zertifikat, ganz ohne certbot-Schritt und ohne Renewal-Cronjob:

sudo systemctl reload caddy

The one condition that has to hold: something on the public internet must be able to complete an HTTP-01 or TLS-ALPN challenge against your address on 80 or 443. A dedicated IPv4 satisfies that outright. Behind NAT IPv4 with no forwarded 80/443, Caddy simply cannot get a certificate this way — which Step 5 covers, as a different, simpler HTTPS story, not a broken one. More in Caddy's automatic HTTPS documentation.Die eine Bedingung, die erfüllt sein muss: Irgendetwas aus dem öffentlichen Internet muss eine HTTP-01- oder TLS-ALPN-Challenge gegen deine Adresse auf 80 oder 443 abschließen können. Eine dedizierte IPv4 erfüllt das ohne Weiteres. Hinter NAT-IPv4 ohne weitergeleitete 80/443 kann Caddy auf diesem Weg schlicht kein Zertifikat bekommen — das behandelt Schritt 5, als eine andere, einfachere HTTPS-Geschichte, nicht als eine kaputte. Mehr dazu in Caddys Dokumentation zu automatischem HTTPS.

Step 4: a systemd-managed app behind CaddySchritt 4: eine von systemd verwaltete App hinter Caddy

A static site needs nothing beyond file_server. A light PHP or Node app needs its own process, kept alive by systemd rather than a terminal session that dies on disconnect.Eine statische Seite braucht nichts über file_server hinaus. Eine leichte PHP- oder Node-App braucht einen eigenen Prozess, am Leben gehalten von systemd statt von einer Terminal-Sitzung, die bei der Trennung stirbt.

For PHP, install php-fpm and point Caddy at its socket:Für PHP installierst du php-fpm und zeigst Caddy auf dessen Socket:

sudo apt install -y php-fpm

example.com {
    root * /var/www/example.com
    php_fastcgi unix//run/php/php8.3-fpm.sock
    file_server
}

Match the socket to your installed PHP version, not this example — check with php -v and adjust php8.3-fpm.sock on a newer release.Passe den Socket an deine installierte PHP-Version an, nicht an dieses Beispiel — prüfe mit php -v und passe php8.3-fpm.sock bei einem neueren Release entsprechend an.

For Node, install an LTS release and run the app under its own unit rather than pm2 or a screen session:Für Node installierst du ein LTS-Release und lässt die App unter einer eigenen Unit laufen, statt unter pm2 oder einer Screen-Sitzung:

curl -fsSL https://deb.nodesource.com/setup_24.x | sudo -E bash -
sudo apt install -y nodejs

[Unit]
Description=example.com app
After=network.target

[Service]
Type=simple
User=deploy
WorkingDirectory=/var/www/example.com
ExecStart=/usr/bin/node server.js
Environment=NODE_ENV=production
Environment=PORT=3000
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now example-app.service

example.com {
    reverse_proxy 127.0.0.1:3000
}

Bind the app to 127.0.0.1 and let Caddy be the only thing the internet talks to directly: one process handles TLS, and the app itself is never exposed to a port scanner. systemctl status example-app and journalctl -u example-app -f are where to look first when the site is up but the app is not answering.Binde die App an 127.0.0.1 und lass Caddy das Einzige sein, mit dem das Internet direkt spricht: Ein Prozess kümmert sich um TLS, und die App selbst ist nie einem Port-Scanner ausgesetzt. systemctl status example-app und journalctl -u example-app -f sind der erste Blick, wenn die Seite läuft, die App aber nicht antwortet.

Step 5: Cloudflare Tunnel, if you have no inbound port at allSchritt 5: Cloudflare Tunnel, wenn du überhaupt keinen eingehenden Port hast

On NAT IPv4 with no forwarded 80/443, cloudflared gets you a real HTTPS site anyway — it never asks your VPS to accept an inbound connection:Bei NAT-IPv4 ohne weitergeleitete 80/443 verschafft dir cloudflared trotzdem eine echte HTTPS-Seite — es verlangt von deinem VPS nie, eine eingehende Verbindung anzunehmen:

curl -fsSL https://pkg.cloudflare.com/cloudflare-main.gpg | sudo tee /usr/share/keyrings/cloudflare-main.gpg >/dev/null
echo "deb [signed-by=/usr/share/keyrings/cloudflare-main.gpg] https://pkg.cloudflare.com/cloudflared $(lsb_release -cs) main" \
  | sudo tee /etc/apt/sources.list.d/cloudflared.list
sudo apt update
sudo apt install -y cloudflared
sudo cloudflared tunnel login
sudo cloudflared tunnel create example-site
sudo cloudflared tunnel route dns example-site example.com

Run all three with sudo — unprivileged, tunnel login and tunnel create write cert.pem and the credentials JSON to your own home directory, not /root/.cloudflared, where the root-run service below expects them. route dns creates the CNAME inside Cloudflare — no DNS panel needed. Save the config as /root/.cloudflared/config.yml, pointing it at whatever is listening locally:Führe alle drei mit sudo aus — unprivilegiert schreiben tunnel login und tunnel create cert.pem und die Credentials-JSON in dein eigenes Home-Verzeichnis, nicht nach /root/.cloudflared, wo der unten als Root laufende Dienst sie erwartet. route dns legt den CNAME innerhalb von Cloudflare an — kein DNS-Panel nötig. Speichere die Konfiguration als /root/.cloudflared/config.yml und zeig damit auf das, was lokal lauscht:

tunnel: <TUNNEL-ID>
credentials-file: /root/.cloudflared/<TUNNEL-ID>.json
ingress:
  - hostname: example.com
    service: http://localhost:80
  - service: http_status:404

sudo cloudflared service install
sudo systemctl enable --now cloudflared

Two things change behind a tunnel. Caddy no longer needs its own certificate — Cloudflare's edge holds it and reaches cloudflared over its own encrypted connection, so a plain :80 block is correct, not a downgrade:Hinter einem Tunnel ändern sich zwei Dinge. Caddy braucht kein eigenes Zertifikat mehr — Cloudflares Edge hält es und erreicht cloudflared über seine eigene verschlüsselte Verbindung, sodass ein einfacher :80-Block korrekt ist, kein Downgrade:

:80 {
    root * /var/www/example.com
    file_server
}

And your firewall needs no inbound 80 or 443 at all — the tunnel is entirely outbound, the honest answer for a small site not paying for a dedicated address. Full mechanics are in Cloudflare's tunnel documentation.Und deine Firewall braucht überhaupt keine eingehenden 80 oder 443 — der Tunnel ist vollständig ausgehend, die ehrliche Antwort für eine kleine Seite, die nicht für eine dedizierte Adresse zahlt. Die vollständige Mechanik steht in Cloudflares Tunnel-Dokumentation.

Step 6: backing up the site directorySchritt 6: das Site-Verzeichnis sichern

The site directory and its running configuration are what need to survive the machine disappearing — not the OS itself, which a clean image replaces from scratch.Das Site-Verzeichnis und seine laufende Konfiguration sind das, was das Verschwinden der Maschine überleben muss — nicht das Betriebssystem selbst, das ein sauberes Image ohnehin von Grund auf neu bereitstellt.

sudo mkdir -p /root/backups
sudo tar czf /root/backups/site-$(date +%F).tar.gz \
  -C / var/www/example.com etc/caddy etc/systemd/system/example-app.service

/root is mode 700, so both commands need sudo — and mkdir runs first because /root/backups doesn't exist yet on a machine that has never been backed up./root hat den Modus 700, also brauchen beide Befehle sudo — und mkdir läuft zuerst, weil /root/backups auf einer Maschine, die noch nie gesichert wurde, noch nicht existiert.

A tarball on the same disk it was made from is not a backup, it is a file that vanishes with the disk. Copy it off with rsync or scp on a cron entry or systemd timer, and treat that copy, not the tarball, as what you rely on. back up your VPS covers what is and is not included by default if you would rather not run this yourself.Ein Tarball auf derselben Festplatte, von der er erstellt wurde, ist kein Backup, sondern eine Datei, die mit der Festplatte verschwindet. Kopiere ihn mit rsync oder scp über einen Cron-Eintrag oder Systemd-Timer herunter, und verlass dich auf diese Kopie, nicht auf den Tarball. Backup deines VPS deckt ab, was standardmäßig enthalten ist und was nicht, falls du das lieber nicht selbst machen willst.

If your app has its own data — uploads, a SQLite file, anything a visitor created — back that up specifically rather than assuming it lives inside the tree you already tar up.Hat deine App eigene Daten — Uploads, eine SQLite-Datei, alles, was ein Besucher erzeugt hat —, sichere das gezielt, statt anzunehmen, dass es innerhalb des Baums liegt, den du schon in den Tarball packst.

What a 1 GiB machine comfortably servesWas eine 1-GiB-Maschine bequem bedient

Static files are close to free: Caddy's own footprint is a few tens of megabytes resident, and serving a page is mostly the kernel handing bytes off disk cache to a socket. A static site on 1 GiB is bounded by your network link long before RAM, at almost any traffic a small site sees.Statische Dateien sind fast umsonst: Caddys eigener Fußabdruck liegt bei ein paar Dutzend Megabyte resident, und das Ausliefern einer Seite ist größtenteils der Kernel, der Bytes aus dem Disk-Cache an einen Socket übergibt. Eine statische Seite auf 1 GiB wird bei fast jedem Traffic, den eine kleine Seite sieht, weit vor dem RAM durch deine Netzwerkanbindung begrenzt.

A light PHP-FPM pool with a handful of workers, or a single Node process with a modest connection pool, typically sits in the tens of megabytes once warmed up — comfortable room on 1 GiB alongside the OS, sshd and Caddy. It stops being comfortable once you add a database on the same box, load large files into memory per request, or run more than one app — any of those is a reason to size up, not tune around.Ein leichter PHP-FPM-Pool mit einer Handvoll Workern oder ein einzelner Node-Prozess mit einem bescheidenen Connection-Pool liegt einmal warmgelaufen typischerweise bei ein paar Dutzend Megabyte — bequemer Platz auf 1 GiB neben dem Betriebssystem, sshd und Caddy. Bequem hört es auf, sobald du eine Datenbank auf derselben Maschine hinzufügst, große Dateien pro Request in den Speicher lädst oder mehr als eine App betreibst — jedes davon ist ein Grund, hochzustufen, nicht herumzutunen.

Two cheap habits worth doing on day one: add a swapfile (a gigabyte is plenty) so a short burst does not get a process killed outright, and watch disk — the Starter tier's 25 GB holds a small site and a couple weeks of backups without effort, but logs and an unpruned upload directory quietly fill it.Zwei günstige Gewohnheiten, die sich schon am ersten Tag lohnen: eine Swapfile anlegen (ein Gigabyte reicht locker), damit ein kurzer Lastausschlag nicht gleich einen Prozess killt, und die Festplatte im Blick behalten — die 25 GB des Starter-Tarifs fassen eine kleine Seite und ein paar Wochen Backups mühelos, aber Logs und ein ungepflegtes Upload-Verzeichnis füllen sie still und leise.

On overnight.hostBei overnight.host

Full disclosure: this is what we sell. A 1 GiB Starter serves a static site or a light PHP/Node app without noticing; move up a tier once you add a database alongside it or the traffic is no longer small.Zur vollen Transparenz: Das ist, was wir verkaufen. Ein 1-GiB-Starter bedient eine statische Seite oder eine leichte PHP/Node-App, ohne es zu merken; steige eine Stufe höher, sobald du eine Datenbank dazu betreibst oder der Traffic nicht mehr klein ist.

Linux KVM VPS — EUR 4.99 to EUR 59.99 a month, on our own single-tenant bare metal in Dallas, TX and Charlotte, NC. Full hardware virtualisation (KVM), your own kernel, full root. Six tiers, vps-starter to vps-ultra. Starter is 1 vCPU, 1 GiB RAM, 25 GB disk.Linux-KVM-VPS — 4,99 bis 59,99 EUR im Monat, auf unserer eigenen Single-Tenant-Bare-Metal-Hardware in Dallas, TX und Charlotte, NC. Vollständige Hardware-Virtualisierung (KVM), eigener Kernel, volles Root. Sechs Tarife, vps-starter bis vps-ultra. Starter hat 1 vCPU, 1 GiB RAM, 25 GB Speicher.

You order in the shop, pay by card (Stripe) or SEPA bank transfer, and your login details are e-mailed to you once the service is set up. Support is e-mail, run by one person, with no guaranteed response time. All prices are final totals under the German small-business rule (§19 UStG); no VAT is added or shown.Du bestellst im Shop, zahlst per Karte (Stripe) oder SEPA-Überweisung, und deine Zugangsdaten werden dir per E-Mail zugeschickt, sobald der Dienst eingerichtet ist. Support läuft per E-Mail, von einer einzelnen Person betrieben, ohne garantierte Reaktionszeit. Alle Preise sind Endpreise. Gemäß § 19 UStG wird keine Umsatzsteuer ausgewiesen.

Order vps-starter → · Linux KVM VPS overviewvps-starter bestellen → · Übersicht Linux-KVM-VPS

Written by the person who runs overnight.host: a small, honest hosting company on dedicated bare metal — Linux VPS, game servers, web hosting. Live status at up.overnight.host.Geschrieben von der Person, die overnight.host betreibt: ein kleines, ehrliches Hosting-Unternehmen auf dedizierter Bare-Metal-Hardware — Linux-VPS, Gameserver, Webhosting. Live-Status unter up.overnight.host.