Hosting-Kosten für deine App senken: So geht's

Um die Hosting-Kosten zu senken, findest du heraus, was tatsächlich läuft und warum, und lässt dann alles schlafen, wenn niemand es nutzt. Bei Hosts, die auf null skalieren, kosten eine inaktive App und eine schlafende Datenbank sehr wenig. Die größten Einsparungen kommen deshalb meist davon, das zu entfernen, was sie wach hält, meist Code, der die Datenbank alle paar Sekunden abfragt. Danach folgen weniger Bandbreite und das Löschen von Apps, die niemand nutzt.

Die meisten kleinen Apps haben kein Traffic-Problem. Sie haben ein Problem mit „es läuft immer etwas“. Dieser Leitfaden zeigt, wie du es findest und behebst, mit Prompts, die du einem KI-App-Builder geben kannst.

Wofür du tatsächlich bezahlst

Die Hosting-Rechnungen kleiner Apps setzen sich aus wenigen Posten zusammen. Wenn du weißt, welcher groß ist, weißt du, wo du suchen musst.

Viele moderne Hosts, auch Mythex, skalieren auf null: Wenn niemand die App nutzt, stoppt der Server und kostet bei der Rechenleistung nichts. Beim nächsten Besuch wacht er wieder auf. Damit verschiebt sich die Frage von „wie groß ist mein Server?“ zu „warum ist mein Server wach?“.

Schritt 1: Sieh nach, wohin das Geld fließt

Bevor du etwas änderst, öffne die Nutzungsseite deines Hosts und finde:

• Welches Projekt am meisten kostet. Oft ist eine App der größte Teil der Rechnung.
• Welche Kategorie: Rechenleistung, Datenbank, Bandbreite oder Speicher.
• Wann es Kosten verursacht. Eine gleichbleibende Linie nachts, wenn du keine Nutzer hast, ist der Hinweis, dass etwas die App wach hält.

Bei Mythex zeigen die Nutzungsdetails die letzten 30 Tage, aufgeteilt in Build (der KI-Agent) und Run (Hosting, Bandbreite, Datenbank und Dateispeicher), mit einer Aufschlüsselung nach Projekt.

Schritt 2: Inaktive Apps und Datenbanken schlafen lassen

Das ist für die meisten kleinen Apps der wirksamste Hebel. Eine Datenbank, die im Leerlauf schläft und bei der nächsten Anfrage aufwacht, kostet in ruhigen Stunden fast nichts. Eine Datenbank, die alle paar Sekunden abgefragt wird, wird nie inaktiv, und du zahlst den ganzen Tag dafür.

Die Hosting-Limits von Mythex beschreiben, wie das bei veröffentlichten Apps funktioniert: Eine schlafende App verbraucht keine Rechenleistung. Die Datenbank startet in ihrer kleinsten Größe, wächst, wenn sie beschäftigt ist, schläft nach 5 Minuten Inaktivität und wird nach ihrer Größe multipliziert mit der Zeit berechnet, in der sie wach war. Eine App, die ihre Datenbank auch nur alle paar Minuten abfragt, Tag und Nacht, wird also so abgerechnet, als wäre sie immer beschäftigt. Dieselbe App ohne solche Hintergrundaktivität kostet sehr wenig.

Häufige Dinge, die eine App wach halten:

• Polling. Eine Seite, die den Server alle 2–5 Sekunden fragt: „Gibt es etwas Neues?“ Lässt du diesen Tab auf einem Laptop offen, schläft die Datenbank nie.
• Sich automatisch aktualisierende Dashboards, die Daten per Timer neu laden, auch wenn niemand hinsieht.
• Uptime-Monitore, die die App jede Minute anpingen.
• Hintergrundschleifen im Servercode, ein setInterval, das ewig aufräumt oder Daten synchronisiert.
• Geplante „Keep-alive“-Anfragen, die jemand hinzugefügt hat, um einen langsamen ersten Besuch zu vermeiden. Sie funktionieren, indem sie den Schlaf verhindern, und genau das kostet Geld.

Bitte die KI, sie zu finden:

Durchsuche den Code nach allem, was per Timer läuft oder die Datenbank wiederholt abfragt: Polling, setInterval, automatische Aktualisierung, Hintergrundschleifen. Liste jeden Eintrag auf, wie oft er läuft und ob er auch dann läuft, wenn niemand die Seite geöffnet hat. Ändere noch nichts.

Dann behebe sie einzeln:

Das Dashboard fragt /api/orders alle 3 Sekunden ab. Ändere es so, dass es nur aktualisiert, solange der Browser-Tab sichtbar ist, und alle 60 Sekunden statt alle 3. Füge einen manuellen Aktualisieren-Button hinzu.

Braucht deine App wirklich Live-Updates, etwa einen Chat oder eine Live-Anzeige, frag, ob sie nur dann Updates pushen kann, wenn sich etwas ändert, statt ständig nachzufragen. Für viele Apps reicht „aktualisieren, wenn der Nutzer zum Tab zurückkehrt“.

Schritt 3: Den Server passend dimensionieren

Größere Maschinen kosten pro Stunde mehr. Viele mit KI gebaute Apps starten mit einer Standardgröße, die passt. Probleme entstehen, wenn man nach „mehr Leistung“ ruft, um eine Langsamkeit zu beheben, die eigentlich von einer langsamen Abfrage kommt.

• Behalte die kleinste Größe, die deinen Traffic ohne Fehler bedient.
• Wenn du Speicherabstürze siehst, frag die KI zuerst, ob die App zu viel in den Speicher lädt, etwa eine ganze Tabelle statt einer Seite mit Ergebnissen.
• Füge nur Maschinen hinzu, wenn du gemessenen Traffic hast, der sie braucht.

Bei Mythex wird die Maschinengröße beim Veröffentlichen anhand dessen gewählt, was die App braucht. Zusätzliche Maschinen starten nur bei starkem Traffic und gehen wieder schlafen, wenn er nachlässt. Die Kosten folgen der Größe. Bitte im Chat um eine kleinere Größe, wenn du glaubst, dass sie zu groß ist.

Schritt 4: Bandbreite reduzieren

Bandbreite ist das, was Besucher herunterladen. Bilder sind meist der größte Anteil.

• Komprimiere Bilder und liefere moderne Formate wie WebP oder AVIF aus.
• Skaliere Bilder auf die Größe, in der sie angezeigt werden. Ein 4.000-Pixel-Foto als 400-Pixel-Vorschaubild verschwendet den größten Teil des Heruntergeladenen.
• Lade Bilder unterhalb des sichtbaren Bereichs verzögert (Lazy Loading).
• Cache statische Dateien (Skripte, Stile, Bilder), damit wiederkehrende Besucher sie nicht erneut laden. Siehe was Caching ist.
• Lass die App nicht bei jedem Seitenaufruf große Dateien ausliefern.

Prüfe jedes Bild in der App. Skaliere sie auf die größte Größe, in der sie angezeigt werden, wandle sie in WebP um und lade alles unterhalb des ersten Bildschirms verzögert. Nenne mir die Gesamtgröße vorher und nachher.

Schnellere Seiten und geringere Bandbreite gehen meist Hand in Hand. Siehe wie du deine Website schneller machst.

Schritt 5: Entferne, was niemand nutzt

• Alte Apps unveröffentlichen: Testdeployments, abgeschlossene Experimente, die Event-Seite vom letzten Jahr.
• Alte Uploads, Logs und Exporte löschen, die du nicht brauchst.
• Geteilte Vorschau-Links löschen, die du nicht mehr verwendest. Bei Mythex weckt das Öffnen eines Vorschau-Links das Projekt und läuft über deine Credits. Ein vergessener Link, den jemand immer wieder öffnet, kostet also weiterhin Geld.
• Ungenutzte Dienste entfernen, etwa einen API-Server oder Worker, den die App nicht mehr aufruft.

Schritt 6: Eine statische Seite erwägen

Wenn deine Seite keine Logins, keine gespeicherten Nutzerdaten und keine Serverlogik hat, etwa eine Marketing-Seite, ein Portfolio oder eine Speisekarte, kann sie eine statische Seite sein: einfache Dateien, die über ein CDN ausgeliefert werden. Es gibt keinen Server und keine Datenbank, die laufen müssen. Bei Mythex verbrauchen statische Seiten keine Credits, solange sie einfach dastehen.

Diese Seite hat keine Logins und keine gespeicherten Daten. Kann sie als statische Seite ohne Server neu gebaut werden? Was würden wir verlieren?

Schritt 7: Kostenpflichtige API-Aufrufe im Blick behalten

Bei Apps, die KI-Modelle, Karten oder SMS aufrufen, können die Rechnungen der Drittanbieter das Hosting weit übertreffen.

• Verlange einen Login für alles, was pro Aufruf Geld kostet.
• Setze ein Limit pro Nutzer (siehe was Rate-Limiting ist).
• Cache Antworten, die sich nicht ändern, etwa die Geokodierung derselben Adresse.
• Lege Ausgabenlimits oder Warnungen bei jedem Anbieter fest.

Häufige Fehler

• Raten statt messen. Prüfe zuerst die Nutzungsaufschlüsselung. Der teure Teil ist oft nicht das, was du erwartest.
• Einen größeren Server kaufen, um Langsamkeit zu beheben. Ein fehlender Datenbankindex oder das Laden zu vieler Daten ist meist die eigentliche Ursache.
• Alles pollen. Jeder Timer, der alle paar Sekunden läuft, ist ein Grund, warum die Datenbank wach bleibt.
• Die App anpingen, um sie „warm“ zu halten. Damit verschwindet die Ersparnis, die das Skalieren auf null bringt. Akzeptiere eine kurze Aufwachzeit beim ersten Besuch oder zahle bewusst für Dauerbetrieb.
• Alte Deployments vergessen. Ungenutzte Apps mit Datenbanken und Hintergrundjobs summieren sich leise.
• Unkomprimierte Bilder. Oft der größte Bandbreitenposten bei kleinen Seiten.

Checkliste

• Ich weiß, welches Projekt und welche Kategorie (Rechenleistung, Datenbank, Bandbreite, Speicher) am meisten kostet.
• Nichts fragt die Datenbank alle paar Sekunden ab, wenn niemand hinsieht.
• Dashboards aktualisieren in einem sinnvollen Intervall oder nur, solange der Tab sichtbar ist.
• Kein Uptime-Monitor und keine Hintergrundschleife hält die App ohne Grund wach.
• Der Server ist die kleinste Größe, die funktioniert.
• Bilder sind skaliert, komprimiert und verzögert geladen; statische Dateien sind gecacht.
• Alte Apps sind unveröffentlicht, alte Dateien gelöscht, ungenutzte Vorschau-Links entfernt.
• Seiten ohne Daten oder Logins sind statisch.
• Kostenpflichtige APIs haben Login, Limits pro Nutzer und Ausgabenwarnungen beim Anbieter.

Kosten auf Mythex senken

Mythex nutzt ein gemeinsames Credit-Guthaben für das Bauen und das Hosting. Hosting-Einsparungen lassen also mehr Credits für das Bauen übrig. Einige Mythex-spezifische Punkte:

• Veröffentlichte Apps und ihre Datenbanken schlafen im Leerlauf und wachen beim nächsten Besuch auf. Die Datenbank schläft nach 5 Minuten Inaktivität. Ständiges Polling zu entfernen ist deshalb meist der größte Gewinn.
• Der Pro-Tarif zahlt für Hosting, Datenbanken, Bandbreite, Dateispeicher und die Vorschau-Sandbox die Hälfte des Free-Satzes. KI kostet in beiden Tarifen gleich viel. Siehe Credits.
• Du bekommst eine E-Mail, bevor ein niedriges Guthaben eine veröffentlichte App pausieren würde. Pausierte Apps behalten ihre Datenbank und Dateien.

Für das größere Bild zu laufenden Kosten siehe wie viel es kostet, eine App zu bauen und was Webhosting ist.

Fragen