ADR-0002: Hosting – Supabase selbst gehostet auf Hetzner

Status: Angenommen (Chris, 2026-11-02)
Datum: 2026-11-02

Kontext

Shuffle (ADR-0001: Flutter + Supabase) soll DSGVO-konform in der EU laufen. Nutzer geben u. a. Stadt, Partien und Fotos preis; Mindestalter 16. Entwickelt wird allein mit KI-Agents, Forgejo und Outline laufen bereits selbst gehostet.

Optionen

A: Supabase Cloud Pro (Region Frankfurt)

ca. $25–30 pro Monat, 100.000 MAU, 8 GB DB, 100 GB Storage, tägliche Backups (7 Tage) inklusive; PITR $100 extra.
Kaum Betriebsaufwand. Aber: Supabase Pte. Ltd. (Singapur) bzw. Supabase, Inc. (USA) als Verarbeiter, Übermittlung per Standardvertragsklauseln, Support- und Abrechnungsdaten können die Region verlassen.

B: Selbst gehostet auf Hetzner (Docker)

Kosten Größenordnung €25–35 pro Monat (Server, Backups, Object Storage); keine Gebühr pro User.
Daten bleiben bei einem deutschen Anbieter. Dafür: Updates, Härtung, Backups, Monitoring und Wiederherstellung liegen bei uns; kein Branching, keine verwalteten Backups/PITR, Community-Support.

C: Anderer EU-Anbieter (netcup, IONOS, OVHcloud, Scaleway)

Gleiches Betriebsmodell wie B; netcup/IONOS ähnlich günstig, siehe Vergleich. Kein klarer Vorteil gegenüber Hetzner.

Entscheidung

Option B: Supabase selbst gehostet auf Hetzner, Standort Deutschland. Datenhoheit wiegt für Shuffle mehr als der geringere Betriebsaufwand der Cloud. Medien und Backups liegen in Hetzner Object Storage (S3-kompatibel). Die Server-Größe wird vor der Bestellung anhand der aktuellen Preise und Verfügbarkeit festgelegt; Preise und Lieferbarkeit der günstigen Pläne haben sich 2026 geändert und sind vor Bestellung in der Hetzner Console zu prüfen.

Konsequenzen

Pflichtbausteine vor dem ersten echten Nutzer: automatisierte Backups (DB + Storage) an getrennten Ort, getesteter Restore, TLS und Reverse Proxy, Firewall, nur nötige Ports, Update-Routine, Monitoring und Alarm, Secrets nicht im Repo.
Zwei Umgebungen: lokal (Supabase CLI) für Entwicklung, ein Hetzner-Server für Staging/Produktion; Staging und Produktion getrennt, sobald echte Nutzer da sind.
Nur Funktionen nutzen, die es selbst gehostet gibt (kein Branching, keine Management-API). Schema ausschließlich über Migrationen.
Dateizugriff über eine eigene Schicht, damit der Speicher austauschbar bleibt.
Dashboard-Einstellungen (SMTP, Redirect-URLs, OAuth) schriftlich im Repo festhalten.
Aufgabe für devops: Docker-Compose-Setup, Backup- und Restore-Skripte, Runbook in docs/.
Rückfall: Ein Umzug in die Supabase Cloud ist möglich (Dump, Dateien kopieren, Nutzer melden sich neu an).
Neubewertung, wenn Betriebsaufwand oder Ausfälle die Entwicklung spürbar bremsen.

2.7 KiB Raw Permalink Blame History Unescape Escape