Warum ich SaaS auf eigenem Server statt in der Cloud betreibe
Viele Entwickler greifen reflexartig zu AWS, Google Cloud oder Azure. Ich nicht. Seit Jahren betreibe ich meine SaaS-Produkte auf eigenen Servern — und spare dabei nicht nur Geld, sondern gewinne auch Kontrolle, Performance und rechtliche Sicherheit.
Die Zahlen sprechen für sich
Mein Hetzner CPX22 kostet €6,19 pro Monat: 3 vCPU, 4 GB RAM, 80 GB SSD, 20 TB Traffic. Für dasselbe Setup zahle ich bei AWS (t3.medium + EBS + Transfer) realistisch €70–100 pro Monat. Das ist ein Faktor 12–16.
Auf diesem einen Server laufen aktuell: Baseloq (SaaS), AllesWurst Dev-Umgebung, diese Website, ein Ferienhaus-Buchungssystem, Freqtrade (Krypto-Bot), eine Stock-Trading-App und mehrere kleinere Projekte. Nginx als Reverse Proxy, PM2 für Node-Prozesse, PostgreSQL, Redis — alles sauber isoliert.
Kontrolle ist kein Luxus
In der Cloud bin ich Mieter. Preise können sich ändern, Dienste werden deprecated, APIs verschwinden. Bei AWS gab es in den letzten Jahren mehrere Preiserhöhungen — ohne Vorwarnung. Auf meinem eigenen Server bin ich Eigentümer. Ich entscheide, was läuft, wie es konfiguriert ist und wann Updates eingespielt werden.
Das bedeutet auch: kein Vendor Lock-in. Wenn Hetzner morgen 50% teurer wird, migriere ich zu Netcup, Contabo oder einem anderen Anbieter — in einer Stunde. Bei AWS, wo alles über proprietary Services verknüpft ist (RDS, Lambda, S3, SQS), ist Migration ein mehrmonatiges Projekt.
DSGVO ohne Kopfschmerzen
Hetzner hat Rechenzentren in Deutschland und Finnland. Die Daten meiner europäischen Kunden verlassen nie die EU. Kein Privacy Shield-Chaos, kein Standardvertragsklausel-Jonglieren, keine Datentransfers in die USA. Baseloq verarbeitet Mitarbeiterdaten — DSGVO-Compliance ist hier kein Nice-to-have, sondern Pflicht.
Bei AWS läuft standardmäßig alles in US-East, wenn man nicht aufpasst. Und selbst EU-Regionen unterliegen dem US CLOUD Act — ein oft unterschätztes rechtliches Risiko für europäische Unternehmen.
Performance: Überraschend gut
Hetzner-Server liegen in Nürnberg und Helsinki — für österreichische und deutsche Nutzer sind das Latenzen von 10–25ms. AWS Frankfurt wäre ähnlich, kostet aber das Vielfache. Und da ich alle meine Projekte selbst konfiguriere, gibt es kein Cold-Start-Problem wie bei Lambda-Functions, keine Auto-Scaling-Latenz, keine Überraschungen beim Traffic-Spike.
Wann macht Cloud trotzdem Sinn?
Ich bin kein Cloud-Fundamentalismus-Gegner. Es gibt legitime Szenarien:
- Globaler Traffic: Wenn du Nutzer auf 5 Kontinenten hast und wirklich niedrige Latenz brauchst, ist ein CDN oder Multi-Region-Deployment sinnvoll.
- Extreme Skalierbarkeit: Wenn dein Traffic in Sekunden von 100 auf 100.000 Requests explodieren kann (virales Produkt, Ticketverkauf), ist Auto-Scaling ein echter Vorteil.
- Spezialdienste: Für Machine Learning (GPU-Instances), Speech-to-Text oder spezialisierte Datenbanken gibt es Cloud-Dienste ohne vernünftige Self-Hosted-Alternative.
- Enterprise-Compliance: Manche Unternehmenskunden bestehen auf zertifizierten Cloud-Infrastrukturen (ISO 27001, SOC 2).
Für 90% der SaaS-Produkte im Frühstadium — die first 1.000 Kunden, erste Skalierungsphase — ist ein dedizierter oder virtueller Server bei Hetzner, Netcup oder Contabo die wirtschaftlichere und oft auch technisch überlegene Wahl.
Mein Setup im Detail
Damit das Ganze nicht abstrakt bleibt, hier mein konkretes Setup: Der Hetzner CPX22 läuft mit Ubuntu als Betriebssystem. Als Webserver und Reverse Proxy dient Nginx, das alle eingehenden Requests auf die verschiedenen Projekte verteilt. Jedes Projekt hat seinen eigenen Nginx-Server-Block mit eigener Domain und eigener Konfiguration.
Für das Node.js-Prozessmanagement nutze ich PM2. Jedes Projekt — Baseloq, AllesWurst, die Buchungsplattform — läuft als eigenständiger PM2-Prozess. Das bedeutet: wenn ein Projekt abstürzt, werden die anderen nicht beeinträchtigt. PM2 startet abgestürzte Prozesse automatisch neu und bietet ein eingebautes Monitoring mit CPU- und RAM-Verbrauch pro Prozess.
Die Datenbanken laufen auf PostgreSQL — jedes Projekt hat seine eigene Datenbank mit eigenem Benutzer und eigenen Berechtigungen. Redis übernimmt Session-Management und Caching, was die Response-Zeiten für wiederkehrende Anfragen drastisch verkürzt.
SSL-Zertifikate kommen von Let's Encrypt via Certbot und werden automatisch erneuert. Und das Beste: All diese Komponenten — Nginx, PM2, PostgreSQL, Redis, Certbot — sind Open Source und kostenlos. Die einzigen laufenden Kosten sind die €6,19 für den Server selbst.
Automatisierte Backups runden das Setup ab. Jede Nacht werden PostgreSQL-Dumps erstellt und auf einen separaten Storage-Server synchronisiert. So ist im Ernstfall kein Datenverlust von mehr als 24 Stunden möglich.
Kostenvergleich: Eigener Server vs. Cloud — die vollständige Rechnung
Im bestehenden Abschnitt habe ich den groben Faktor genannt. Hier die detaillierte Aufschlüsselung, was mein Setup bei AWS kosten würde:
- Hetzner CPX22: €6,19/Monat — alles inklusive (Compute, Storage, 20 TB Traffic)
- AWS EC2 t3.medium (vergleichbar): ~€35/Monat
- AWS EBS 80 GB SSD: ~€8/Monat
- AWS Data Transfer 1 TB/Monat: ~€90/Monat (nach dem Free Tier)
- AWS RDS PostgreSQL (db.t3.micro): ~€30/Monat
- AWS ElastiCache Redis (cache.t3.micro): ~€15/Monat
AWS gesamt: ~€180/Monat — das ist Faktor 29 gegenüber Hetzner. Über drei Jahre gerechnet: Hetzner ~€223 vs. AWS ~€6.480. Eine Ersparnis von über €6.250.
Selbst wenn ich monatlich 2–3 Stunden für Serververwaltung einrechne (was realistisch ist, nachdem das Setup einmal steht), kostet mich das bei einem internen Stundensatz von €80 etwa €200/Monat. Zusammen mit den €6,19 Serverkosten komme ich auf ~€206/Monat — immer noch günstiger als die reine AWS-Infrastruktur ohne jede Administrationszeit.
Sicherheit und Monitoring
Der häufigste Einwand gegen Self-Hosting: "Aber die Sicherheit!" Tatsächlich ist ein gut konfigurierter eigener Server nicht unsicherer als eine Cloud-Instanz — oft sogar sicherer, weil die Angriffsfläche kleiner ist.
Mein Sicherheits-Setup umfasst:
- SSH nur mit Key-Authentifizierung: Passwort-Login ist komplett deaktiviert. Brute-Force-Angriffe auf SSH laufen ins Leere.
- fail2ban: Blockiert automatisch IP-Adressen nach mehreren fehlgeschlagenen Login-Versuchen — nicht nur für SSH, sondern auch für Nginx.
- UFW Firewall: Nur die Ports 22 (SSH), 80 (HTTP) und 443 (HTTPS) sind geöffnet. Alles andere wird blockiert.
- Unattended Upgrades: Sicherheitsupdates werden automatisch installiert, ohne manuelles Eingreifen.
Für Monitoring nutze ich PM2's eingebaute Überwachung: CPU-Auslastung, RAM-Verbrauch und automatischer Neustart bei Abstürzen. Dazu kommt ein einfaches Uptime-Monitoring, das mich per E-Mail benachrichtigt, wenn ein Dienst nicht erreichbar ist. PostgreSQL-Backups laufen jede Nacht automatisch via pg_dump und Cron-Job, die Dumps werden auf externen Storage synchronisiert.
Migration: So einfach ist der Umzug
Ein weiterer Vorteil meines Setups: Die Migration auf einen neuen Server dauert 1–2 Stunden. Alle Konfigurationen sind entweder als Code versioniert oder einfach reproduzierbar. Der Ablauf ist simpel:
- PostgreSQL: pg_dump auf dem alten Server, pg_restore auf dem neuen — Datenbank-Migration in Minuten.
- Dateien: rsync kopiert alle Projektdateien, Konfigurationen und Uploads in einem Rutsch.
- Nginx & PM2: Konfigurationsdateien kopieren, PM2-Prozesse starten — fertig.
- DNS: A-Record auf die neue IP ändern, TTL abwarten — der Umzug ist komplett.
Vergleiche das mit einer AWS-Migration: Lambda-Funktionen, IAM-Rollen und -Policies, VPC-Konfigurationen, Security Groups, S3-Buckets, RDS-Instanzen, ElastiCache-Cluster, CloudWatch-Alarme — alles muss einzeln neu aufgesetzt oder über CloudFormation/Terraform migriert werden. Das ist kein Nachmittagsprojekt, sondern ein mehrwöchiges Unterfangen. Mein Setup? Ein neuer Server, ein paar Befehle, DNS umstellen — fertig.
Fazit
Eigener Server ist kein Retro-Move. Es ist die pragmatische Entscheidung für Kosten, Kontrolle und Compliance. Die Cloud-Anbieter haben hervorragendes Marketing — aber Hetzner CPX22 für €6/Monat schlägt AWS t3.medium für €80/Monat beim Preis-Leistungs-Verhältnis um Welten. Solange mein Setup die Anforderungen erfüllt, bleibe ich dabei.
Fragen oder Feedback? office@markusstoeger.com