Self-Hosting mit Coolify, Forgejo & Astro: Mein Setup

In den letzten Wochen und Tagen habe ich ein Projekt vollendet, das mir schon lange am Herzen lag: den konsequenten Umzug meiner digitalen Werkzeuge und Hosting-Infrastruktur auf eigene, souveräne Systeme.

Als Entwickler neigt man schnell dazu, für jedes Problem ein neues US-Cloud-Abo abzuschließen – hier ein Vercel-Pro-Plan, da GitHub-Teams, dort Bitwarden Cloud und ein halbes Dutzend SaaS-Tools. Doch mit jedem Dienst wachsen nicht nur die monatlichen Fixkosten, sondern vor allem die Abhängigkeiten und DSGVO-Fragezeichen.

Hier ist der Erfahrungsbericht, wie mein aktueller Stack aussieht, welche Hürden es gab und warum sich der Schritt für mein Business und meine Kundenprojekte lohnt.

---

1. Das Fundament: Hetzner Cloud & Coolify

Das Herzstück der neuen Infrastruktur ist eine leistungsfähige, deutsche Cloud-Instanz (in ISO-zertifizierten Rechenzentren).

Statt aufwendig jedes Docker-Compose-File manuell per SSH zu pflegen, setze ich als Orchestrierungs-Schicht auf Coolify. Coolify ist die quelloffene, selbstgehostete Antwort auf Vercel, Netlify und Render:

• Eigene PaaS-Oberfläche: Übersicht über alle Container, Datenbanken und Dienste an einem zentralen Ort.
• Automatisches Traefik Reverse-Proxying: Vollautomatische Verwaltung von SSL-Zertifikaten (Let’s Encrypt), HTTP/2 und HTTP/3 ohne manuelle Zertifikats-Skripte.
• Git-gesteuerte Deployments: Sobald ich auf main pushe, triggert ein Webhook den Build und deployt das Projekt mit Zero-Downtime.

---

2. Eigene Git-Infrastruktur: Forgejo statt GitHub

Für meine Codebases und Projekte habe ich alle Repositories auf eine eigene Instanz von Forgejo (dem Community-Fork von Gitea) umgezogen. Forgejo ist jetzt die führende Quelle; GitHub dient bei einzelnen Projekten nur noch als Spiegel.

Warum Forgejo?

1. Unabhängigkeit: Mein Code liegt in Deutschland, nicht auf US-Servern, die jederzeit Nutzungsbedingungen ändern oder ungefragt KI-Trainings auf privaten Codebases aktivieren können.
2. DSGVO-Konformität: Öffentliche Registrierungen sind gesperrt, Gravatar und externe CDN-Abfragen sind vollständig deaktiviert.
3. Leichtgewicht: Die gesamte Git-Forge inkl. Issue-Tracking und Pull Requests benötigt im laufenden Betrieb gerade einmal ~100 MB RAM.
4. Isolierter SSH-Zugang: Ein dedizierter, separater SSH-Zugang für Git-Operationen, strikt getrennt von der administrativen Server-Verwaltung.

---

3. Passwort-Souveränität: Eigener Vaultwarden-Tresor

Zugangsdaten, API-Schlüssel und Lizenz-Keys gehören zu den sensibelsten Vermögenswerten eines Unternehmens. Statt auf Cloud-Tresore zu vertrauen, läuft nun Vaultwarden (die schlanke Rust-Implementierung des Bitwarden-Servers) auf der Instanz:

• Ressourcenbedarf: rund 13 MB RAM.
• Sicherheit: Öffentliche Registrierung deaktiviert, Härtung gegen Brute-Force via IP-Reputationsfilter und tägliche verschlüsselte Backups.
• Kompatibilität: Funktioniert nahtlos mit allen offiziellen Bitwarden-Apps auf Mac, Smartphone und im Browser.

---

4. Web-Performance: Wie Astro-Seiten mit wenigen Megabyte RAM auskommen

Ein wichtiger Teil der Migration ist die Bereitstellung von Kunden- und Portfolio-Websites – seit dem 3. Oktober 2026 läuft auch syfrt.de selbst über Coolify.

Sie alle basieren auf Astro – und das zeigt seinen wahren Vorteil erst im Container-Betrieb:

Im Gegensatz zu servergerenderten Next.js- oder WordPress-Systemen, die im Leerlauf gerne hunderte Megabyte Arbeitsspeicher binden und ständige CPU-Last für dynamische Interpreter erzeugen, nutzt Astro die statische Vorab-Kompilierung:

1. Build: Coolify baut das Astro-Projekt bei jedem Push auf main.
2. Artifact: Das Ergebnis ist reines, statisches HTML und CSS.
3. Runtime: Ausgeliefert wird das Ganze über ein minimales nginx:alpine-Image.

Das Resultat?

• RAM-Verbrauch: zwischen 5 und 9 Megabyte pro Website (gemessen mit docker stats).
• Antwortzeiten: TTFB (Time to First Byte) im zweistelligen Millisekundenbereich.
• Sicherheit: Keine Datenbank-Injections, keine dynamischen PHP-Schwachstellen.

---

5. Geschützte Kundenbereiche ohne Backend-Overhead

Eine spannende architektonische Herausforderung bei Kundenprojekten (wie bei Fotografen-Galerien oder Vorab-Freigaben) sind geschützte Kundenbereiche: Wie schützt man private Medien vor Direktaufrufen, wenn man keinen schweren Anwendungs-Server laufen lassen will?

Ein pragmatischer Ansatz: Cookie-basierte Pfad-Sperre direkt im Webserver:

location ~ ^/media/private/(?<client_scope>[^/]+)/ {
    if ($cookie_client_token != $client_scope) {
        return 403;
    }
    expires 7d;
    add_header Cache-Control "private, no-transform";
    try_files $uri =404;
}

Sobald der Kunde sein Zugangspasswort im Frontend eingibt, setzt JavaScript das Cookie. Ruft jemand die Bild- oder Asset-URL direkt ohne passenden Cookie-Wert auf, antwortet nginx mit HTTP 403 Forbidden.

Wichtig – ehrlich eingeordnet: Das ist ein Sichtschutz gegen Zufallsaufrufe, kein echter Zugriffsschutz. Der erwartete Cookie-Wert steht im Pfad, und das Passwort wird nur im Browser geprüft – wer die URL kennt, kann das Cookie selbst setzen. Für wirklich vertrauliche Inhalte gehört die Prüfung auf den Server: HTTP Basic Auth, ein signiertes Token oder Forward-Auth vor Traefik.

---

6. Zero-Downtime & 24/7 Monitoring

Bei Domain- und Server-Umzügen ist Ausfallzeit inakzeptabel. Durch eine temporäre Reverse-Proxy-Schaltung auf dem Altsystem konnte der gesamte Traffic transparent zum neuen Server geroutet werden, noch bevor die weltweite DNS-Verteilung überhaupt beendet war: Besucher merkten von der Umstellung nichts.

Das gesamte Setup wird rund um die Uhr von einer eigenen Uptime Kuma Instanz überwacht:

• HTTP-Healthchecks im 60-Sekunden-Takt für alle Websites und APIs.
• Kontinuierliche Verfügbarkeits-Prüfung aller Kern-Dienste.
• Sofortiger Telegram-Alarm an mein Smartphone, falls ein Dienst einmal Schluckauf haben sollte.
• Gleichzeitig sendet Forgejo bei jedem Commit eine kompakte Push-Benachrichtigung über die Änderungen auf mein Handy.

---

Fazit & Ausblick

Mein Fazit: Mit Open-Source-Tools wie Coolify, Forgejo, Docker und Astro braucht man für solide Performance, Sicherheit und Verfügbarkeit keine unüberschaubare Cloud-Infrastruktur und keinen Stapel SaaS-Abos.

Auf einer einzigen schlanken Cloud-Instanz laufen heute meine Entwicklungs-Pipelines, Passwörter, Websites und APIs – bei einer CPU-Auslastung von unter 30 % und großzügigen RAM-Reserven für zukünftige Projekte.

Wie das Tracking in diesem Setup läuft, steht im Beitrag Umami Analytics selbst hosten.

Sie planen eine ähnliche Konsolidierung oder suchen ein schlankes Hosting für Ihre Website? Sprechen Sie mich an.