Cloud-Kosten sind ein reales Problem für frühe Startups. Nicht weil AWS schlecht wäre — es ist eine solide Plattform — sondern weil die Standardeinstellungen teuer sind und die meisten Teams erst optimieren, wenn die Rechnung bereits wehtut.
Hier sind die echten Zahlen: Was ein vergleichbares Produktions-Setup auf AWS versus Hetzner im Jahr 2026 kostet, was Self-Hosted-Tooling wie Coolify leisten kann — und wann welcher Ansatz sinnvoll ist.
Das AWS-Standard-Setup
Eine einfache Produktionsumgebung auf AWS — eine EC2-Instanz für die App, managed Postgres, ein Load Balancer — sieht ungefähr so aus:
| Komponente | Monatliche Kosten |
|---|---|
| EC2 t3.medium (2 vCPU, 4GB) | ~$33 |
| RDS db.t3.micro (Postgres) | ~$15 |
| Application Load Balancer | ~$16 |
| S3 (10GB + Requests) | ~$3 |
| Datentransfer (10GB ausgehend) | ~$9 |
| Gesamt | ~$76–120 |
Das ist vor der Staging-Umgebung. Vor CloudWatch-Logs. Vor Route 53. Vor dem Moment, wo die Rechnung um $40 steigt, weil irgendwo ein NAT Gateway übersehen wurde.
Für ein finanziertes Startup ist das nicht absurd. Aber für ein Pre-Revenue-Produkt mit 200 Nutzern? Nicht trivial — und das ist die optimistische Version, bei der jemand die Standardeinstellungen tatsächlich bereinigt hat.
Was dasselbe Setup bei Hetzner kostet
Hetzner ist ein deutsches Cloud-Unternehmen mit Rechenzentren in Nürnberg, Falkenstein, Helsinki und Ashburn (US). Für EU-Workloads sind die ersten drei relevant.
| Komponente | Monatliche Kosten |
|---|---|
| CX31 (2 vCPU, 8GB RAM) | €9,01 |
| Hetzner Managed Postgres (Starter) | €15 |
| Object Storage (250GB) | €4,99 |
| Hetzner Load Balancer (optional) | €5,83 |
| Gesamt (mit LB) | ~€35 |
| Gesamt (ohne LB) | ~€29 |
Bei einfachen Setups — ein Server, Coolify als Reverse Proxy — entfällt der Load Balancer komplett. €29 pro Monat für einen produktionstauglichen Stack.
Die Differenz: 60–75 % günstiger für frühe Workloads. Auf 12 Monate gerechnet sind das $700–$1.000 gespart, bevor der erste Euro Umsatz reinkommt.
Was Coolify und Dokploy tatsächlich liefern
Das Schmerzhafteste an Self-Hosting war früher der operative Aufwand. VPS, Repo, SSH-Deploy. Rollbacks waren Glückssache.
Dieses Problem ist heute weitgehend gelöst.
Coolify und Dokploy sind Docker-basierte PaaS-Tools, die auf dem eigenen Server laufen. Das Konzept ist Heroku oder Render — aber auf Hardware, die man selbst kontrolliert.
Was man bekommt:
- Git-Push-Deploys — Repo verbinden, auf main pushen, es baut und deployed
- SSL-Terminierung — Traefik handled HTTPS automatisch über Let's Encrypt
- Reverse Proxy — mehrere Services auf einem Server, jeder auf einer eigenen Subdomain
- Env-Management — Secrets serverseitig gespeichert, zur Laufzeit injiziert
- Rollbacks — ein Klick im UI
- Preview Environments — optional, aber vorhanden
Ein frischer Hetzner-Server mit Coolify ist in unter 30 Minuten aufgesetzt. Danach ist das Deployen eines neuen Services genauso wie ein Push auf Vercel.
Dokploy ist die schlankere Alternative für alle, die weniger UI und mehr Kontrolle wollen. Ich nutze Coolify für die meisten Client-Setups — das UI ist polished genug, dass nicht-technische Co-Founder lesen können, was deployed ist, ohne anzurufen.
Der DSGVO-Aspekt
Für DACH-Startups, die EU-Nutzer bedienen, ist der Standort der Daten eine Compliance-Frage, keine Präferenz.
AWS eu-central-1 (Frankfurt) liegt geografisch in der EU. Aber AWS Inc. ist ein US-Unternehmen, und die rechtliche Situation rund um US-Behördenzugriff auf AWS-Daten — auch Daten, die in Europa gespeichert sind — war seit Schrems II unübersichtlich. Das EU-US Data Privacy Framework (2023) hat die Lage verbessert, aber die grundlegende Spannung bleibt. Im DPA mit AWS stehen Sub-Prozessoren. Diese Sub-Prozessoren haben eigene Sub-Prozessoren.
Bei Hetzner liegen die Daten auf Hardware in Deutschland oder Finnland, betrieben von einer deutschen GmbH. Das DPA ist unkompliziert. Man unterzeichnet keine Vereinbarungen mit 12 Entitäten, die man noch nie gehört hat.
Für Produkte, die personenbezogene Daten verarbeiten — also die meisten SaaS-Anwendungen — entfällt damit eine ganze Compliance-Diskussion. Nutzern kann man sagen: Ihre Daten verlassen die EU nicht. Und das ist durchsetzbar.
Mein Standard-Setup für Self-Hosted Infrastruktur
Das ist der Stack, den ich für die meisten frühen Clients aufsetze, die Self-Hosted-Infrastruktur wollen:
Hetzner CX31 (€9,01/Monat)
└── Coolify
├── App-Container (Next.js oder was der Stack verlangt)
├── PostgreSQL (zunächst auf demselben Server)
└── Uptime Kuma (Monitoring)
Hetzner Object Storage (€4,99/Monat)
└── S3-kompatibel — für File-Uploads und Backups
Plausible Analytics (€9/Monat managed, oder self-hosted)
Gesamt: ~€25–35 pro Monat, je nachdem ob Plausible managed oder self-hosted läuft.
Für Datenbank-Backups: pg_dump per Cron-Job auf Object Storage. Für Uptime-Monitoring: Uptime Kuma schickt eine Telegram-Benachrichtigung, wenn etwas ausfällt. Beides ist in rund einer Stunde eingerichtet.
Wenn die App wächst und der einzelne Server zur Einschränkung wird — Traffic-Spitzen, Postgres braucht mehr IOPS, das Team will Staging-Parität — werden einzelne Services migriert. Postgres zieht auf Hetzner Managed Postgres oder Neon. Die App kommt vielleicht auf Vercel. Jede Migration findet statt, wenn der Schmerz die Mehrkosten rechtfertigt. Nicht am ersten Tag.
Wann Self-Hosted Sinn macht
- Vorhersehbare Workloads. Wer seine Traffic-Muster ungefähr kennt, braucht kein elastisches Scaling. Ein CX31 verarbeitet mehrere hundert gleichzeitige Nutzer problemlos.
- Kostensensible Frühphase. Pre-Revenue zählt jeder €100 pro Monat. €60–80 bei der Infrastruktur zu sparen ist echtes Geld.
- EU-Datensitz-Anforderungen. Regulierte Branchen, gesundheitsnahe Produkte, alles was DSGVO ernsthaft berücksichtigt.
- Grundlegende Linux-Kenntnisse. Man muss kein Sysadmin sein. Man muss wissen, was
df -hmacht, und nicht in Panik verfallen, wenn ein Cron-Job fehlschlägt.
Wann AWS oder GCP trotzdem gewinnt
Self-Hosted ist nicht überall die richtige Antwort.
- Globale CDN-Anforderungen. CloudFront, GCPs CDN oder Cloudflare sind für globale Latenz besser als alles, was man auf einem einzelnen Hetzner-Server aufbaut.
- Managed ML-Services. Wer SageMaker, Vertex AI oder GPU-Instanzen mit Managed-Tooling braucht — AWS und GCP haben einen enormen Vorsprung. Hetzner hat GPU-Server, aber den Managed-Layer gibt es dort noch nicht.
- Null Ops-Kapazität. Wenn das Gründerteam noch nie einen Linux-Server angefasst hat und das auch nicht möchte, schützen Managed-Plattformen vor sich selbst. Vercel + Neon + eine Managed Queue ist ein legitimer Production-Stack.
- Sofortige horizontale Skalierung. Wenn das Produkt tatsächlich von 100 auf 100.000 Nutzer über Nacht wachsen kann — Product-Hunt-Launch, großer Presseartikel — ist elastisches Scaling wichtig. Auto-Scaling-Groups rechtfertigen dann die Komplexität.
Das ehrliche Kleingedruckte
Self-Hosted bedeutet: Man besitzt den Ops-Aufwand. Nicht "man hat jemanden zum Anrufen." Man selbst.
Festplatte voll — man fixt es. Postgres braucht ein Vacuum — man kümmert sich. SSL-Zertifikat-Erneuerung schlägt fehl, weil Let's Encrypt rate-limitet — man debuggt das um 23 Uhr.
Realistisch: 1–2 Stunden pro Monat für Wartung bei einem gut konfigurierten Setup. Wer diese Zeit nicht hat oder nicht will, sollte die Kosten für jemanden einkalkulieren, der das übernimmt — oder bei Managed-Infrastruktur bleiben und den Aufpreis zahlen.
Die Wirtschaftlichkeit funktioniert, weil das Tooling gereift ist. Coolify deckt die operative Fläche ab, die früher echte DevOps-Arbeit erforderte. Aber nicht alles. Man sollte wissen, worauf man sich einlässt, bevor man migriert.
Der Migrationspfad
Self-Hosted zu starten bedeutet nicht, es für immer zu bleiben. Es ist keine dauerhafte Entscheidung.
Eine vernünftige Entwicklung:
- Monat 0–12: Ein Hetzner-Server, Coolify, Postgres auf derselben Maschine. Fokus auf das Produkt.
- Monat 12–24: App-Traffic wächst → Postgres auf Hetzner Managed oder Neon auslagern. Zweiten Server für Staging hinzufügen.
- Nach Bedarf: Einzelne Services ziehen zum jeweils besten Anbieter. App auf Vercel, wenn das Team es bevorzugt. Storage auf Cloudflare R2 für globalen Edge. Postgres bleibt dort, wo es am besten performt.
Das Ziel zu Beginn ist nicht perfekte Infrastruktur. Es ist etwas, das funktioniert, fast nichts kostet und keine Compliance-Probleme erzeugt — damit der Fokus auf dem Produkt liegen kann.