Wie DevQuake gehostet wird

Dieser Beitrag enthält einen Empfehlungslink zu Hostinger. Wenn du dich darüber anmeldest, erhalten wir möglicherweise eine Provision, ohne Mehrkosten für dich. Wir bezahlen unser Hosting selbst, und alles Folgende ist uns wirklich so passiert.

Wer kleine Websites baut, fragt oft, was der Betrieb von so etwas wie DevQuake wirklich braucht. Hier ist unser Aufbau, einschließlich dessen, was schiefging.

Was wo läuft

DevQuake ist eine Next.js-Anwendung mit unabhängigen Apps, jede auf ihrer eigenen Subdomain: darts.devquake.com, utilities.devquake.com und so weiter. Sie läuft auf einem verwalteten Node.js-Tarif bei Hostinger, mit MySQL-Datenbanken im selben Tarif.

Die Website und jede App-Subdomain betreiben ihre eigene Kopie der Anwendung. Diese eine Tatsache prägt fast alle weiteren Entscheidungen, wie du gleich siehst.

Das Deployment ist einfach: Ein Merge in den Hauptzweig startet einen Build, der ein lauffertiges Paket veröffentlicht, und der Host spielt es neu ein. Auf dem Server wird nichts gebaut.

Worauf du beim Preis achten solltest

Die Anzeigen und Empfehlungen im Blog helfen, das Hosting zu bezahlen, damit die Apps selbst werbefrei bleiben.

Hosting ist nicht die einzige Rechnung. Die Domain und der Sprachdienst hinter den natürlichen Stimmen des Workout-Trainers kommen dazu. Prüfe vor der Entscheidung den aktuellen Preis, denn Tarife sind in der ersten Laufzeit oft deutlich günstiger als bei der Verlängerung.

Der Tag, an dem die Ressourcen ausgingen

Am 22. Oktober 2026 gingen unserem Tarif die Ressourcen aus. Seiten antworteten mit der 503-Fehlerseite des Hosters oder hingen einfach.

Die Ursache waren Threads. Ein Tarif wie unserer begrenzt die erlaubten Prozesse und Threads, bei uns auf 120. Jede Kopie der Anwendung brauchte etwa sieben Threads, und mit mehr als einem Dutzend Kopien lagen wir schon nah am Limit, bevor der erste Besucher kam.

Was wir geändert haben

• Untätige Kopien beenden sich. Eine App-Subdomain, die niemand nutzt, fährt herunter und startet beim nächsten Besuch neu. Eine selten genutzte App kostet fast nichts, dafür ist die erste Seite langsamer.
• Weniger Threads je Kopie. Node.js läuft auch mit kleineren Thread-Pools als standardmäßig, und unsere sind jetzt begrenzt.
• Keine dauerhaft laufenden Jobs. Geplante Arbeit läuft in einem gemeinsamen geplanten Durchlauf, nicht in Timern in jedem Prozess.
• Schwere Arbeit im Browser. Ein Zählerfoto lesen oder ein Bild verkleinern geschieht auf dem Gerät der Besucher, nicht auf unserem Server.
• Dateien in der Datenbank. Ein Deployment ersetzt den Anwendungsordner, alles auf der Festplatte wäre also verloren.
• Jede neue Funktion wird auf Kosten geprüft: Threads, Speicher, Jobs und Platz.

Für wen das passt

Es passt, wenn du eine Website oder wenige kleine Apps betreibst, mäßigen Verkehr hast, ein Panel für Domains, SSL, Datenbanken und E-Mail möchtest und dich nicht um einen Server kümmern willst.

Es passt nicht, wenn du lang laufende Hintergrund-Worker, native Module mit eigenen Threads oder viele dauerhaft laufende Prozesse brauchst. Dann stößt du ans Prozesslimit und bist mit einem VPS besser bedient.

Was wir uns selbst raten würden

1. Finde das Prozesslimit, bevor du die zehnte App hinzufügst. Schau auf die Ressourcenseite im Panel, nicht nur auf den Speicherplatz.
2. Zähle Threads, nicht nur Arbeitsspeicher.
3. Bau das Beenden im Leerlauf von Anfang an ein.
4. Hol dir das SSL-Zertifikat einer neuen Subdomain, bevor du sie öffnest, besonders wenn deine Website HSTS mit Subdomains sendet: Browser lehnen sie sonst ab.

Wenn du es ausprobieren möchtest

Passt dieser Aufbau zu deinem Vorhaben, kannst du dich über unseren Empfehlungslink anmelden: die Tarife von Hostinger ansehen. Das kostet dich nichts extra und hilft, DevQuake zu finanzieren. Passt es nicht, ist ein kleiner VPS die ehrliche Alternative.

So funktioniert DevQuake