Wie ich heute ein neues Webprojekt aufsetze

Die Frage, die niemand ehrlich beantwortet

“Wie hostest du deine Projekte?”

Die offizielle Antwort klingt immer beeindruckend:

“Multi-Region Kubernetes mit GitOps”
“Serverless auf AWS Lambda mit DynamoDB”
“Self-hosted auf eigener Bare-Metal-Infrastruktur”

Die ehrliche Antwort?

Hier ist, wie ich wirklich entscheide – ohne Dogma, ohne Framework, nur nach Kontext.

Der Entscheidungsbaum (Real Edition)

Frage 1: Wer betreibt das?

Die wichtigste Frage zuerst. Alles andere folgt daraus.

Ich alleine (Side-Project, eigenes SaaS)

Mein Bedürfnis: Ich will nicht an Infrastruktur denken.

Meine Wahl: App Platform (Render, Fly.io, Railway)

Warum?

Kein Ops-Overhead
Deployment = git push
Managed Database inklusive
Ich baue Features, nicht Server

Setup-Zeit: 20 Minuten

Kunde betreibt es später

Mein Bedürfnis: Es muss simpel genug sein, dass der Kunde es versteht.

Meine Wahl: Hetzner VPS mit Docker Compose

Warum?

Kunde kann SSH-Zugriff haben (wenn gewünscht)
Kein Vendor-Lock-in (einfach migrierbar)
Vorhersehbare Kosten (€10-30/Monat)
Simple Stack (nginx, Docker, PostgreSQL)

Setup-Zeit: 4-6 Stunden (Initial), dann wartungsarm

Team mit DevOps-Kapazität

Mein Bedürfnis: Team kann und will Infrastruktur managen.

Meine Wahl: DigitalOcean oder AWS (je nach Komplexität)

Warum?

Team hat Zeit für Setup
Custom-Requirements rechtfertigen Komplexität
Budget ist da

Setup-Zeit: 1-2 Wochen (initial), dann kontinuierlich

Frage 2: Was für ein Projekt?

Technologie folgt Anforderung, nicht umgekehrt.

Statische Website / Marketing-Seite

Aspekt	Wahl
Framework	Astro
Hosting	Cloudflare Pages, Netlify, Vercel
CMS	Decap CMS (git-based) oder Contentful
Kosten	€0-9/Monat

Warum? Kostenlos für die meisten Projekte, globales CDN, Auto-Deploy bei Git-Push, Zero Maintenance.

git push origin main
# → Automatisch deployed

SSR-App (Next.js, SvelteKit, Astro SSR)

Aspekt	Wahl
Framework	Astro (SSR) oder Next.js
Hosting	Vercel (Next.js), Render, Fly.io
Database	Supabase, PlanetScale, Turso
Kosten	€9-50/Monat

Warum? Vercel ist unschlagbar für Next.js (Zero-Config), Render/Fly.io für andere Frameworks, Managed DB spart Zeit.

vercel deploy --prod
# oder
fly deploy

Fullstack-App mit Backend-Logic

Aspekt	Wahl
Frontend	React/Astro auf Vercel/Netlify
Backend	Go/Node.js auf Fly.io oder Hetzner
Database	Hetzner Managed Postgres, DigitalOcean
Kosten	€20-60/Monat

Warum? Frontend und Backend getrennt = einfacher zu skalieren, Backend auf VPS = volle Kontrolle, Managed DB = kein Backup-Stress.

# Frontend
vercel deploy --prod

# Backend
fly deploy
# oder
ssh server && docker compose pull && docker compose up -d

E-Commerce

Größe	Lösung	Kosten
Small (< 1.000 Produkte)	Shopify	€27+/Monat
Custom (> 1.000 Produkte)	Medusa.js auf Render + Stripe	€37-92/Monat
Hybrid	Astro Frontend + Shopify Storefront API	variabel

Warum? Shopify für “ich will verkaufen, nicht basteln”, Medusa.js für Custom-Features, Hybrid für Performance + Shopify-Backend.

SaaS mit Multi-Tenancy

Aspekt	Wahl
Frontend	React/Next.js auf Vercel
API	Go/Node.js auf Fly.io (Multi-Region)
Database	PostgreSQL mit RLS (Supabase, Neon)
Auth	Supabase Auth oder Clerk
Payments	Stripe
Kosten	€46-200/Monat (je nach Scale)

Warum? Fly.io für globale Latenz, Managed Auth spart Wochen Entwicklung, Supabase RLS = Built-in Multi-Tenancy.

vercel deploy --prod  # Frontend
fly deploy            # API

Frage 3: Wer sind die Nutzer?

Geografie bestimmt Hosting-Strategie.

Nur EU-Nutzer

Hosting: Hetzner (Deutschland) oder Scaleway (Frankreich)

Warum?

Niedrige Latenz
DSGVO-konform ohne SCCs
Günstiger als US-Alternativen

Global (USA, EU, Asien)

Hosting: Fly.io (Edge-Network) oder Vercel (für Frontend)

Warum?

Automatische Multi-Region-Deployments
Niedrige Latenz weltweit
Du denkst nicht an Regionen

Nur Deutschland / DACH

Hosting: Hetzner (Falkenstein oder Nürnberg)

Warum?

Beste Latenz für DE
Deutsches Unternehmen (Compliance-Vorteil)
Billigster Anbieter mit Top-Qualität

Mein aktueller Standard-Stack (2026)

Wenn ich heute ein neues Projekt starte (und es ist nicht Kunde-spezifisch):

Frontend

Framework: Astro (Static oder SSR)

Warum?

Schnellstes Framework für Content-Sites
Flexibel (Static, SSR, Hybrid)
Island Architecture = weniger JS shipped

Hosting: Cloudflare Pages

Warum?

Kostenlos bis zu extremen Scales
Global CDN
Auto-Deploy via Git
Workers für Edge-Functions (falls nötig)

Backend (wenn nötig)

Language: Go (Performance) oder Bun (TypeScript, aber schneller)

Hosting: Fly.io

Warum?

Simple Deployments (fly deploy)
Multi-Region automatisch
Free Tier (generös)
Container-based (Dockerfile = Portabilität)

Database

Default: PostgreSQL auf Neon oder Supabase

Warum?

Managed (kein Backup-Stress)
Serverless Pricing (zahle nur für Nutzung)
Built-in Connection Pooling
Supabase = Auth + Realtime + Storage inklusive

Alternative (EU-only): Hetzner Managed Postgres

Warum?

Günstiger bei konstanter Last
EU-Hosting
Vorhersehbare Kosten

Auth

Default: Supabase Auth

Warum?

Kostenlos bis 50.000 MAUs
Email, OAuth, Magic Links
Row-Level Security integration
Kein eigenes Auth-System bauen

Alternative (für größere Projekte): Clerk

Warum?

Besseres UX
Multi-Tenancy Support
Mehr Features (Orgs, Teams, etc.)

Storage (Files, Images)

Default: Cloudflare R2

Warum?

S3-kompatibel (einfach zu migrieren)
Kein Egress-Cost (im Gegensatz zu S3)
Billig (€0,014/GB)

Alternative: Supabase Storage

Warum?

Wenn ich schon Supabase für Auth/DB nutze
Built-in Image Transformations

CDN

Default: Cloudflare (kostenlos)

Warum?

Beste Performance
DDoS-Protection inklusive
Free Tier ist genug für 99 % der Projekte

Monitoring

Default: Sentry (Errors) + Plausible (Analytics)

Warum?

Sentry: Open-Source, Self-Hostbar, oder Managed
Plausible: Privacy-first, DSGVO-konform, einfach

Alternative: PostHog (All-in-One)

Warum?

Analytics + Feature Flags + Session Replay
Self-Hostbar oder Managed

Das Setup in der Praxis

Konkrete Beispiele statt theoretischer Konzepte.

Beispiel 1: Neues SaaS-Projekt

Anforderungen:

Multi-Tenancy
Auth + Payments
EU + US Nutzer
Budget: < €92/Monat (initial)

Mein Stack:

Komponente	Lösung	Kosten
Frontend	Astro SSR auf Cloudflare Pages	€0
API	Go auf Fly.io (2x 256MB, EU + US)	€9
Database	Neon Postgres (Serverless)	€18
Auth	Supabase Auth	€0
Storage	Cloudflare R2	$2
Monitoring	Sentry + Plausible	€8

Gesamt: ~€38/Monat
Setup-Zeit: 1 Tag

Deployment:

# Frontend
git push origin main  # → Auto-deploy via Cloudflare

# API
fly deploy            # → Multi-Region deployment

# Database
# → Managed, nichts zu deployen

Beispiel 2: Marketing-Website für Kunden

Anforderungen:

Schnell
SEO-optimiert
CMS für Kunde
EU-Hosting (Nice-to-Have)

Mein Stack:

Komponente	Lösung	Kosten
Framework	Astro (Static)	€0
CMS	Decap CMS oder Storyblok	€0-18
Hosting	Cloudflare Pages oder Netlify	€0
Images	Cloudflare Images oder Cloudinary	€0-9

Gesamt: €0-18/Monat
Setup-Zeit: 4 Stunden

Beispiel 3: Fullstack-App für Startup (mit Team)

Anforderungen:

Custom Backend-Logic
Real-Time Features
Team hat DevOps-Erfahrung
Budget: €184-500/Monat

Mein Stack:

Komponente	Lösung	Kosten
Frontend	Next.js auf Vercel (Pro)	€18
API	Node.js auf Hetzner VPS	€30
Database	Hetzner Managed Postgres	€30
Redis	Upstash (Serverless)	€9
Realtime	Supabase Realtime	€10
Monitoring	Datadog oder Grafana Cloud	€30

Gesamt: ~€100-150/Monat (€110-165)
Setup-Zeit: 1-2 Wochen

Was ich aktiv vermeide

Nicht jede “Best Practice” ist es wert.

Thema	Warum nicht	Stattdessen	Ausnahme
Kubernetes	Overhead massiv, braucht dediziertes Team	Docker Compose (VPS) oder Fly.io	>10 Services + hoher Traffic
Microservices	Komplexität explodiert, Debugging schwerer	Monolith oder Modular-Monolith	Service muss anders skalieren
AWS (klein)	Setup dauert zu lange, Kosten unvorhersehbar	Hetzner, Fly.io, DigitalOcean	Kunde verlangt es, spezielle Services nötig
Self-Hosting alles	Auth = Wochen, DB = Backup-Stress	Managed Services für Non-Core	Application-Code, Custom-Logic

Meine Deployment-Strategie

Unterschiedliche Projekte, unterschiedliche Ansätze.

Für Side-Projects

Ziel: Schnell live gehen, minimaler Aufwand

Strategie:

App Platform (Render, Fly.io, Railway)
Managed Database
git push = Deploy

Upside: Keine Wartung, schnell iterieren
Downside: Etwas teurer als VPS

Für Kundenprojekte

Ziel: Langfristig wartbar, nicht zu komplex

Strategie:

Hetzner VPS mit Docker Compose
Managed Database (Hetzner oder DO)
Simple CI/CD (GitHub Actions + SSH)

Upside: Vorhersehbare Kosten, einfach zu verstehen
Downside: Initiales Setup dauert länger

Für Produktion (eigenes SaaS)

Ziel: Balance zwischen Kosten und Convenience

Strategie:

Hybrid: Static Frontend (Vercel/CF Pages), API auf Fly.io oder Hetzner
Managed Database (Neon, Supabase)
Managed Auth (Supabase, Clerk)

Upside: Optimale Kosten + niedrige Wartung
Downside: Mehrere Plattformen

Tools, die ich tatsächlich nutze

Keine theoretische Liste. Das nutze ich wirklich.

Development

Editor: VSCode (mit Vim-Bindings)
Terminal: Warp oder iTerm2
Package Manager: Bun (schneller als npm/pnpm)
Git UI: LazyGit oder Tower

Deployment

CI/CD: GitHub Actions (free tier reicht meist)
Docker: Für Reproducibility und Deployment
Infrastructure as Code: Nicht für kleine Projekte. Erst ab ~5 Services.

Monitoring

Errors: Sentry
Logs: Mezmo (LogDNA) oder Papertrail
Analytics: Plausible oder PostHog
Uptime: Better Uptime oder UptimeRobot

Productivity

Docs: Notion oder Obsidian
Project Management: Linear oder GitHub Projects
Communication: Discord (Teams) oder Slack

Die 5 Regeln, die ich mir selbst gesetzt habe

Prinzipien, die ich bei jedem Projekt anwende.

1. “Einfachste Lösung, die funktioniert”

Nicht: “Was ist technisch am coolsten?”
Sondern: “Was löst das Problem mit minimalem Overhead?“

2. “Managed Services für alles außer Core”

Managed:

Auth, Database, Storage, Monitoring

Self-Controlled:

Application-Code

3. “Keine Lock-ins, die ich nicht verlassen kann”

Easy Exit: Vercel, Cloudflare Pages (Static Export)
Hard Exit: AWS Lambda mit proprietary Services

4. “Kosten sollten vorhersehbar sein”

Risiko: Serverless mit unbekanntem Traffic
Vorhersehbar: VPS oder App Platform mit fixer Größe

5. “Deploy in Minuten, nicht Stunden”

Wenn Deployment kompliziert ist, iteriere ich langsamer.

Es gibt kein Perfect Setup

Die Leute, die dir sagen, “das ist der richtige Stack”, lügen.

Der richtige Stack hängt ab von:

Wer betreibt es?
Was kostet Zeit vs. Geld?
Wer sind die Nutzer?
Wie lange läuft das Projekt?

Mein Setup für ein Side-Project ≠ Mein Setup für ein Kundenprojekt ≠ Mein Setup für ein SaaS.

Das ist kein Widerspruch. Das ist Pragmatismus.

Warum diese Anbieter – und warum das morgen anders sein kann

Dieser Artikel ist eine Momentaufnahme. Stand 2026.

Aber:

Der Markt für Cloud-Anbieter ist extrem dynamisch. Neue Player kommen, Preismodelle ändern sich, Features werden kopiert, Technologien entwickeln sich weiter.

Was sich ändert (und warum ich flexibel bleibe)

Preismodelle verschieben sich

Heute:

Vercel/Netlify haben großzügige Free Tiers
Fly.io ist günstig für kleine Apps
Hetzner ist unschlagbar für VPS

Morgen?

Free Tiers können schrumpfen (wie bei Heroku passiert)
Neue Anbieter mit besseren Konditionen tauchen auf
Preiskämpfe verschieben das Gleichgewicht

Meine Reaktion: Ich optimiere nicht für “den billigsten Anbieter heute”, sondern für Exit-Fähigkeit.

Neue Technologien entstehen

Beispiele der letzten 5 Jahre:

Edge Computing (Cloudflare Workers, Deno Deploy)
WebAssembly auf Edge (Fastly Compute)
SQLite auf Edge (Turso)

Was das bedeutet: Die “beste Lösung” von heute ist nicht die beste von morgen.

Meine Reaktion: Ich setze auf Standard-Technologien (PostgreSQL, Docker, HTTP APIs), nicht auf Vendor-spezifische Features.

Wenn ein neuer Anbieter besser ist, kann ich wechseln – ohne Rewrite.

Kundenanforderungen ändern sich

Früher: “Hauptsache, es läuft.”

Heute:

DSGVO-Compliance (EU-Hosting)
Sovereignty-Anforderungen (keine US-Cloud)
Nachhaltigkeits-Reporting (CO₂-Footprint)

Morgen?

KI-Integration (Inference on Edge?)
Echtzeit-Features als Standard
Zero-Trust-Architekturen

Meine Reaktion: Ich optimiere für Modularität.

Wenn sich Anforderungen ändern, tausche ich Module aus – nicht den ganzen Stack.

KI verändert das Spiel

Was KI bereits tut:

Code-Generierung (GitHub Copilot, Cursor)
Automatisierte Deployments (KI schlägt Optimierungen vor)
Infrastruktur-Optimierung (KI wählt Regions/Sizes)

Was KI bald tun wird:

Auto-Scaling basierend auf Prediction
Automatische Migrations-Scripts (Provider-Wechsel wird trivial)
Self-Healing Infrastructure

Meine Reaktion: Ich baue so, dass KI mir helfen kann – nicht gegen mich arbeitet.

Simple Setups sind KI-freundlich. Komplexe Custom-Configs sind es nicht.

Warum ich mich trotzdem festlege

Die Frage: “Wenn sich alles ändert, warum dann überhaupt committen?”

Die Antwort: Weil Entscheidungsparalyse teurer ist als Sub-Optimierung.

Beispiel: Database-Wahl

Ich könnte mir monatelang überlegen:

“Was, wenn Neon pleite geht?”
“Was, wenn Supabase die Preise erhöht?”
“Was, wenn eine neue DB-Technologie kommt?”

Oder:

Ich nehme Neon, baue mein Produkt, und wenn sich etwas ändert, migriere ich.

Migrationsaufwand (PostgreSQL): 1-2 Tage

Kosten der Entscheidungsparalyse: Wochen ohne Launch

Die Balance: Commitment mit Exit-Option

Ich lege mich fest – aber so, dass ich wechseln kann.

Konkret:

Technologie	Commitment-Level	Exit-Strategie
PostgreSQL	Hoch (Standard-DB)	Einfach (Dump & Restore)
Docker	Hoch (Portabilität)	Einfach (läuft überall)
Cloudflare Pages	Mittel (Static-Export)	Einfach (Astro kann überall deployen)
Supabase Auth	Mittel (OAuth-Standard)	Mittel (Migration zu Clerk/Auth0 möglich)
AWS Lambda	Niedrig (Vendor-Lock-in)	Schwer (Rewrite nötig)

Meine Regel:

Was ich aktiv beobachte

Ich tracke nicht jeden neuen Anbieter. Aber ich achte auf Signale:

Red Flags (Zeit zu migrieren)

Preise steigen >50 % ohne Feature-Improvement
Support wird schlechter
Free Tier verschwindet
Unternehmen wird von Private Equity gekauft (oft Vorbote für Verschlechterung)

Green Flags (Zeit zu evaluieren)

Neuer Anbieter mit deutlich besserem Preis/Leistung
Neue Technologie löst echtes Problem (nicht Hype)
Compliance-Anforderung macht Wechsel nötig

Wie ich neue Anbieter teste

Nicht auf Produktions-Systemen. Nicht mit Hoffnung. Sondern pragmatisch.

Mein Prozess:

Side-Project als Testfeld Neues Projekt = Gelegenheit, neuen Anbieter zu testen
Kleine Migration Wenn es sich bewährt, migriere ich ein kleines Kundenprojekt
Erst dann: Produktion Wenn beides läuft, wird’s Standard

Beispiel:

Ich habe Fly.io 2 Jahre lang auf Side-Projects getestet, bevor ich es für Kunden eingesetzt habe.

Die einzige universelle Wahrheit

Konkrete Setup-Details aus eigener Praxis

Astro für Marketing-Sites: LCP unter 1,2s typisch, Bundle unter 50 KB.
Cloudflare Workers für Edge-Logik: Global niedrige Latenz.
Hetzner VPS für persistente Workloads: 15–40 EUR/Monat.
Supabase für schnelle MVPs: Auth + DB in einer Stunde.

Realistische Initial-Investition

Domain: 10–20 EUR/Jahr.
Hosting: 5–40 EUR/Monat je nach Stack.
Tooling: 0–50 EUR/Monat.

Wann sich Pragmatismus auszahlt

Bei Solo-Projekten: Schnell starten.
Bei MVPs: Vor Optimierung erst lernen.
Bei kurzen Sprints: Standard-Tools nutzen.

Wann ein Stack-Wechsel sinnvoll ist

Wenn Wartung mehr Zeit kostet als Features.
Wenn Performance-Probleme strukturell sind.
Wenn Team wechselt zu anderen Patterns.