Mein Next.js-Build hat meinen Server lahmgelegt. So habe ich es kostenlos gelöst.

Monatelang ging mein Produktivserver bei jedem Deployment in die Knie. Nicht "langsam". Komplett weg. 400% CPU. Dashboard-Nutzer ausgesperrt. Client-Seiten nicht erreichbar. Alles nur, weil ich eine Next.js-App auf derselben Maschine gebaut habe, die sie auch ausgeliefert hat.

Wenn du mit Coolify auf Hetzner self-hostest und immer noch direkt auf deinem Server baust, dann ist dieser Beitrag für dich. Ich habe genau den gleichen Fehler gemacht, und die Lösung war peinlich einfach.

Das Setup

Ich betreibe meine Projekte auf einem Hetzner VPS mit Coolify als Deployment-Plattform. Als ich alles eingerichtet habe, habe ich Nixpacks als Build Pack verwendet. Coolify's Standard. Du pushst Code, Nixpacks erkennt dein Framework, baut das Image, startet es. Null Konfiguration. Funktioniert einfach.

Und eine Weile hat es das auch.

Wenn "funktioniert einfach" nicht mehr funktioniert

Die App wuchs. Mehr Seiten, mehr Routen, mehr Abhängigkeiten. Nixpacks-Builds dauerten länger. Nicht dramatisch, aber spürbar. Ich wechselte zu einem Dockerfile als Build Pack, was mir mehr Kontrolle über den Build-Prozess gab und etwas Build-Zeit einsparte.

Das half. Eine Weile.

Dann kam das Dashboard dazu. Kunden nutzten es täglich. Leute waren eingeloggt, klickten herum, erledigten ihre Aufgaben. Und jedes Mal, wenn ich ein Deployment gepusht habe, ging der Server in die Knie.

400% CPU-Auslastung. Der Build-Prozess hat alles aufgefressen, was der Server hatte. Das Dashboard reagierte nicht mehr. Client-Seiten liefen in Timeouts. 5 bis 10 Minuten lang ging nichts.

Ich habe meinen eigenen Server im Grunde bei jedem Deployment ge-DDOSt.

Das Problem, von dem ich nicht wusste

Die Sache, die mir niemand gesagt hat, als ich mit Self-Hosting angefangen habe: Bauen und Ausliefern sollten nicht auf derselben Maschine passieren.

Im Nachhinein scheint es offensichtlich. Ein Next.js-Produktionsbuild ist CPU-intensiv. TypeScript kompilieren, Bilder optimieren, statische Seiten generieren, Tree-Shaking, Bundling. Das ist eine Menge Rechenaufwand. Und wenn dein 4-Kern-VPS gleichzeitig Live-Traffic bedient, Datenbankabfragen verarbeitet und ein CMS betreibt... irgendetwas muss nachgeben.

Ich wusste einfach nicht, dass es einen besseren Weg in Coolify gibt. Ich nahm an, "Dockerfile Build Pack" bedeutet "Builds passieren hier." Ich wusste nicht, dass Coolify auch fertig gebaute Docker-Images pullen kann, statt sie auf dem Server zu bauen.

Die Lösung: GitHub bauen lassen

Die Lösung war, den Build-Schritt komplett vom Server wegzuverlagern. GitHub Actions übernimmt den Build, pusht das Image in die GitHub Container Registry (ghcr.io), und Coolify pullt nur noch das fertige Image und startet es.

Kein Build auf dem Server. Kein CPU-Spike. Keine Downtime.

So sieht der Workflow ungefähr aus:

1. Code wird auf main gepusht
2. GitHub Actions startet einen Runner
3. Der Runner baut das Docker-Image (mit deinem Dockerfile)
4. Das Image wird zu ghcr.io gepusht
5. Coolify wird per Webhook benachrichtigt
6. Coolify pullt das neue Image und deployt es

Der Server kommt nicht mal ins Schwitzen. Er tauscht einfach einen laufenden Container gegen einen anderen.

Was es kostet: Nichts

GitHubs Free-Plan beinhaltet 2.000 Actions-Minuten pro Monat für private Repositories. Öffentliche Repos bekommen unbegrenzte Minuten.

Mein Next.js-Build braucht etwa 3 bis 4 Minuten. Selbst wenn ich 10 Mal am Tag deploye (tue ich nicht), sind das 40 Minuten. Von 2.000. Ich nutze an einem vollen Tag ungefähr 2% meines kostenlosen Kontingents.

Zum Vergleich: Ein Hetzner VPS-Upgrade, das Builds ohne Einbruch verkraften würde, würde mich 10 bis 20 Euro mehr pro Monat kosten. GitHub Actions kostet mich null.

Der GitHub Actions Workflow

So sieht ein erfolgreicher Build-and-Deploy-Durchlauf auf GitHub aus:

Die gesamte Pipeline läuft in unter 3 Minuten. Job einrichten, Code auschecken, bei GHCR einloggen, Image bauen und pushen, Coolify-Deploy per Webhook triggern. Fertig.

Die Coolify-Seite

Coolify von "selbst bauen" auf "fertiges Image pullen" umzustellen ist unkompliziert. Du änderst das Build Pack von Dockerfile auf Docker Image, gibst dein ghcr.io-Image an, richtest einen Webhook ein, damit Coolify weiß, wann ein neues Image verfügbar ist, und das war's.

Die wichtigste Erkenntnis: Coolify ist es egal, wie das Image gebaut wurde. Es braucht nur ein valides Docker-Image zum Starten. Ob das Image auf deinem Server, auf GitHub oder auf deinem Laptop gebaut wurde, spielt keine Rolle. Gleiches Ergebnis, völlig anderer Server-Impact.

Alles grün. Alles unter 30 Sekunden. Weil es keinen Build-Schritt mehr gibt, nur noch einen Container-Tausch.

Das Ergebnis

Hier ist der CPU-Graph nach dem Umstieg auf GitHub Actions Builds:

Flach. Ruhig. Langweilig. Genau das, was man von einem Produktivserver will.

Keine Spikes mehr. Kein Dashboard-Freeze mehr. Keine Kunden mehr, die mir schreiben, warum die Seite langsam ist.

Was ich dir raten würde, wenn du gerade anfängst

Wenn deine App klein ist und du der einzige Nutzer bist, ist Nixpacks auf Coolify völlig in Ordnung. Mach es nicht unnötig kompliziert.

Aber in dem Moment, wo du echte Nutzer auf deinem Server hast, oder in dem Moment, wo dein Build länger als ein, zwei Minuten dauert, verlagere deine Builds vom Server weg. Warte nicht, bis deine Kunden nicht mehr auf ihr Dashboard zugreifen können, weil du einen CSS-Fix gepusht hast.

Das Setup dauert etwa 30 Minuten:

• Einen GitHub Actions Workflow schreiben, der dein Docker-Image baut und pusht
• Einen GitHub Personal Access Token für den Container-Registry-Zugang einrichten
• Coolify konfigurieren, von ghcr.io zu pullen statt lokal zu bauen
• Die Webhook-URL hinzufügen, damit Deployments automatisch ausgelöst werden

Das war's. 30 Minuten Setup für Zero-Downtime-Deployments für immer.

Die größere Lektion

Self-Hosting gibt dir Kontrolle. Aber Kontrolle bedeutet, dass du für Entscheidungen verantwortlich bist, die Managed-Plattformen automatisch für dich treffen. Vercel baut deine App nicht auf demselben Server, der sie ausliefert. Netlify auch nicht. Wenn du self-hostest, musst du das selbst herausfinden.

Ich habe ein paar Stunden Uptime verloren, bevor ich das verstanden habe. Das musst du nicht.

Wenn du ähnliche Probleme mit deinem Deployment-Setup hast, oder wenn du über Self-Hosting nachdenkst und diese Fallstricke vermeiden willst, meld dich. Ich habe die schmerzhaften Teile schon durchgemacht, damit du sie überspringen kannst.