Geschützter Projekt-Host

Wie das aussieht

Der Server macht keine Verbindung nach außen auf. cloudflared wählt sich bei Cloudflare ein. Besucher kommen nur über Cloudflare rein – und erst nach dem Login.

• Keine Server-IP im DNS – der Record ist ein CNAME (Canonical Name) auf den Tunnel. Damit ist auch das „IP (Internet Protocol) ändert sich beim Neuaufbau“-Problem weg.
• Kein offener Port 80/443 – nichts zum Scannen, kein Weg am Login vorbei.
• Cloudflare Access ist gratis bis 50 Nutzer. TLS (Transport Layer Security) macht Cloudflare am Rand.
• Voraussetzung: seb4u.com liegt schon als Full-Zone bei Cloudflare (Anleitung Domain zu Cloudflare umziehen).

1 Kleiner Server, Ports zu

Für ein paar Projekt-Demos reicht wenig. Realistisch planst du mit cpx. Ein cx/cax (billiger) nur, wenn gerade frei. Konto, hcloud CLI (Command-Line Interface) und SSH-Key setzt die Server-Basis voraus – hier ist die Firewall besonders: nur SSH, weil alles über den Tunnel läuft.

# Firewall: NUR SSH rein. 80/443 braucht der Tunnel nicht.
hcloud firewall create --name host-fw
hcloud firewall add-rule host-fw --direction in --protocol tcp --port 22 --source-ips 0.0.0.0/0

hcloud server create --name projekthost --type cax11 --image debian-12 `
  --ssh-key laptop --firewall host-fw --user-data-from-file cloud-init.host.yaml

#cloud-config
package_update: true
packages: [ ca-certificates, curl, fail2ban, unattended-upgrades, rsync ]
runcmd:
  - curl -fsSL https://get.docker.com | sh
  - useradd -m -s /bin/bash -G docker deploy
  - install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
  - cp /root/.ssh/authorized_keys /home/deploy/.ssh/ && chown deploy:deploy /home/deploy/.ssh/authorized_keys
  - sed -i 's/^#*PermitRootLogin.*/PermitRootLogin no/;s/^#*PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
  - systemctl restart ssh
  - |
    printf '%s\n' '{ "log-driver":"json-file","log-opts":{"max-size":"10m","max-file":"3"} }' > /etc/docker/daemon.json
  - systemctl restart docker
  - docker network create web
  - install -d -o deploy -g deploy /opt/sites /opt/stacks
write_files:
  - path: /etc/apt/apt.conf.d/20auto-upgrades
    content: |
      APT::Periodic::Update-Package-Lists "1";
      APT::Periodic::Unattended-Upgrade "1";

2 Cloudflare Tunnel

cloudflared läuft als Container und hält eine ausgehende Verbindung zu Cloudflare. Die Hostnamen konfigurierst du bequem im Dashboard.

1. Zero Trust-Dashboard: one.dash.cloudflare.com → beim ersten Mal ein Team-Namen wählen (frei, z. B. dein Nachname).
2. Networks › Tunnels › Create a tunnel › Cloudflared → Name projekthost → Save.
3. Cloudflare zeigt einen Token (langer String). Den brauchst du gleich – nicht die vorgeschlagene Install-Zeile, nur den Token-Wert aus --token XXXX.

TUNNEL_TOKEN=eyJhIjoi…   # der Token aus dem Dashboard

services:
  cloudflared:
    image: cloudflare/cloudflared:2025.8.0
    restart: unless-stopped
    command: tunnel --no-autoupdate run
    environment:
      TUNNEL_TOKEN: ${TUNNEL_TOKEN}
    networks: [ web ]
networks:
  web:
    name: web
    external: true

cd /opt/stacks/cloudflared && docker compose up -d
docker compose logs -f cloudflared      # "Registered tunnel connection" = ok

Zurück im Dashboard, Reiter Public Hostnames des Tunnels – pro Projekt eine Zeile (Beispiel folgt in Schritt 5/6):

Der Service-Name ist der Container-Name im web-Netz. Cloudflare legt den DNS-CNAME automatisch an. TLS: erledigt Cloudflare, der Server spricht intern einfach HTTP (Hypertext Transfer Protocol).

3 Zugriffsschutz: Cloudflare Access

Eine Application pro Hostname (oder ein Wildcard), eine Policy, wer rein darf. Login läuft komplett bei Cloudflare – auf dem Server liegt kein Passwort.

1. Access › Applications › Add an application › Self-hosted
2. Application domain: Subdomain * + Domain seb4u.com – gilt dann für alle Subdomains. (Oder pro Projekt eine eigene App mit fester Subdomain.)
3. Session Duration: z. B. 24 h oder 1 Woche.
4. Policy hinzufügen: Action = Allow, Include = Emails → du@example.com (mehrere möglich, oder Emails ending in @deine-firma.de).
5. Login methods: One-time PIN (Code per E-Mail) ist ohne Einrichtung da. Optional Google/GitHub als Identity Provider ergänzen (Settings › Authentication).
6. Save. Ab jetzt: Aufruf einer geschützten Subdomain → Cloudflare-Login → Code eingeben → durch.

4 Projekt: statische Seite

Angular-/Vite-/Hugo-Build, Doku, Landingpage – ein nginx-Container, der einen Ordner ausliefert.

services:
  web-blog:
    image: nginx:1.27-alpine
    restart: unless-stopped
    volumes:
      - /opt/sites/blog:/usr/share/nginx/html:ro
    networks: [ web ]
networks:
  web: { name: web, external: true }

mkdir -p /opt/sites/blog
cd /opt/stacks/site-blog && docker compose up -d

npm run build         # erzeugt ./dist
rsync -az --delete ./dist/ deploy@projekthost:/opt/sites/blog/

Dashboard → Tunnel → Public Hostnames → Add: blog . seb4u.com → http://web-blog:80. Fertig – https://blog.seb4u.com fragt nach dem Login und zeigt dann die Seite.

5 Projekt: App (Compose)

Ein Dienst mit eigenem Prozess (Node, Spring, Python…) – ganz normales Compose-Stack, nur ans web-Netz gehängt, ohne ports:.

services:
  api:
    build: .                       # oder image: ghcr.io/<user>/api:latest
    restart: unless-stopped
    environment:
      NODE_ENV: production
    networks: [ web, internal ]
  db:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_PASSWORD_FILE: /run/secrets/db
    volumes: [ db:/var/lib/postgresql/data ]
    networks: [ internal ]
    secrets: [ db ]
volumes: { db: {} }
networks:
  web: { name: web, external: true }
  internal: {}
secrets:
  db: { file: ./db_password.txt }

rsync -az --delete --exclude node_modules --exclude .git ./ deploy@projekthost:/opt/stacks/api/
ssh deploy@projekthost "cd /opt/stacks/api && docker compose up -d --build"

Public Hostname: api . seb4u.com → http://api:8080 (Port des Containers). Die DB hängt nur im internal-Netz – von außen unerreichbar, auch über den Tunnel nicht.

6 deploy.ps1

Ein Projekt hochschieben – statischer Ordner oder Compose-Stack, in einem Befehl. Liegt im cloud-host-Ordner.

.\scripts\deploy.ps1 blog                       # ./dist -> /opt/sites/blog  (statisch)
.\scripts\deploy.ps1 blog -Source ./build       # anderer Quellordner
.\scripts\deploy.ps1 api  -Stack                # ./ -> /opt/stacks/api  +  docker compose up -d --build
.\scripts\deploy.ps1 api  -Stack -DryRun        # nur zeigen, was uebertragen wuerde
.\scripts\deploy.ps1 blog -Logs                 # docker compose logs -f

Oben in der Datei: $Server (SSH-Ziel), $SitesDir, $StacksDir. Nutzt rsync wenn vorhanden, sonst tar über SSH (beides ist unter Windows 10 als ssh.exe/tar.exe dabei. rsync gibt es per winget install cwRsync oder Git-Bash).

7 SSH absichern

• Passwort-Login und Root-Login sind per cloud-init schon aus, Key-only.
• Besser noch: Tailscale auf Server und Laptop, dann in der Cloud-Firewall Port 22 ganz zu – SSH nur noch übers Tailnet (ssh deploy@projekthost über die Tailscale-IP/den MagicDNS-Namen).
• Oder SSH auch durch den Tunnel: im Dashboard einen Public Hostname ssh.seb4u.com → ssh://localhost:22, eine Access-Policy dazu, und lokal cloudflared access ssh --hostname ssh.seb4u.com als ProxyCommand. Dann ist auch Port 22 in der Firewall entbehrlich.
• fail2ban läuft aus der cloud-init (falls 22 doch offen bleibt).

8 Hardening, Backup, Kosten

Hardening

• Image-Tags pinnen (nginx:1.27-alpine, nicht latest). unattended-upgrades läuft, Kernel-Reboots planen.
• Access-Logs: Access › Logs – wer sich wann eingeloggt hat.
• Nichts Vertrauliches allein auf Access verlassen: eine App, die echte Nutzerdaten hält, braucht trotzdem eigene Anmeldung.

Backup

# statische Sites: einfach der Ordner. App-DBs: Dump.
tar czf /opt/backups/sites-$(date +%F).tgz -C /opt/sites .
docker exec api-db-1 pg_dump -U postgres app | gzip > /opt/backups/api-$(date +%F).sql.gz
rsync -a /opt/backups/ user@u123.your-storagebox.de:host/

+ APIs ohne Browser-Login

Ein Skript / CI (Continuous Integration) / Webhook kann sich nicht durch den Login klicken. In Access: Access › Service Auth › Service Tokens → Token erzeugen. In der Policy der App eine zweite Regel: Include → Service Token → <dein Token>. Der Aufrufer schickt dann die Header CF-Access-Client-Id und CF-Access-Client-Secret mit – Browser-Nutzer weiter per Login, Automaten per Token.

+ Ohne Cloudflare Access

Wenn du Access nicht willst, aber trotzdem Schutz:

• Tunnel + Basic Auth: statt cloudflared direkt auf die Apps, cloudflared → Traefik, und in Traefik eine basicauth-Middleware auf alle Router. Ein Passwort für alle, im Browser gespeichert.
• Nur Tailnet: kein Tunnel, kein öffentlicher Zugriff – Server + alle Geräte im Tailscale-Netz, Zugriff nur von dort. Am dichtesten, aber nicht „online über die Domain“ für Geräte ohne Tailscale.
• Traefik öffentlich + Firewall auf Cloudflare-IPs + Cloudflare-Proxy: klassisch, aber Port 443 ist offen und die Absicherung hängt an korrekten Firewall-Regeln. Der Tunnel ist der ruhigere Weg.