Hoe je de hostingkosten van je app verlaagt

Om de hostingkosten te verlagen, achterhaal je wat er echt draait en waarom, en laat je daarna alles slapen als niemand het gebruikt. Bij hosts die naar nul schalen, kosten een inactieve app en een slapende database heel weinig. De grootste besparingen komen daardoor meestal van het wegnemen van wat ze wakker houdt — meestal code die elke paar seconden de database controleert — en daarna van het verkleinen van de bandbreedte en het verwijderen van apps die niemand gebruikt.

De meeste kleine apps hebben geen verkeersprobleem. Ze hebben een „er staat altijd iets aan”-probleem. Deze gids laat zien hoe je het vindt en oplost, met prompts die je aan een AI-app-builder kunt geven.

Waar je echt voor betaalt

Hostingrekeningen voor kleine apps komen van een handvol zaken. Als je weet welke de grootste is, weet je waar je moet kijken.

Veel moderne hosts, waaronder Mythex, schalen naar nul: als niemand de app gebruikt, stopt de server en kost hij niets aan rekenkracht, en start hij weer bij het volgende bezoek. Daarmee verschuift de vraag van „hoe groot is mijn server?” naar „waarom is mijn server wakker?”

Stap 1: Kijk waar het geld naartoe gaat

Voordat je iets verandert, open je de gebruikspagina van je host en zoek je:

• Welk project het meest kost. Vaak is één app het grootste deel van de rekening.
• Welke categorie: rekenkracht, database, bandbreedte of opslag.
• Wanneer er kosten zijn. Een vlakke lijn ’s nachts, wanneer je geen gebruikers hebt, is de aanwijzing dat iets de app wakker houdt.

Op Mythex toont Gebruiksdetails de laatste 30 dagen, uitgesplitst in Build (de AI-agent) en Run (hosting, bandbreedte, database en bestandsopslag), met een overzicht per project.

Stap 2: Laat inactieve apps en databases slapen

Dit is de echte hefboom voor de meeste kleine apps. Een database die slaapt als hij inactief is en wakker wordt bij het volgende verzoek, kost bijna niets tijdens rustige uren. Een database waarop elke paar seconden een query wordt uitgevoerd, wordt nooit inactief, dus je betaalt de hele dag.

De hostinglimieten van Mythex leggen uit hoe dit werkt voor gepubliceerde apps: een slapende app kost niets aan rekenkracht, de database start op zijn kleinste formaat, groeit tijdens drukte, slaapt na 5 minuten inactiviteit, en wordt gefactureerd naar grootte vermenigvuldigd met de tijd dat hij wakker was. Een app die zijn database zelfs maar één keer per paar minuten bevraagt, dag en nacht, wordt dus gefactureerd alsof hij altijd druk is — terwijl dezelfde app zonder achtergrondverkeer heel weinig kost.

Veelvoorkomende dingen die een app wakker houden:

• Pollen. Een pagina die de server elke 2–5 seconden vraagt „is er iets nieuws?”. Laat dat tabblad op één laptop open staan en de database slaapt nooit.
• Automatisch vernieuwende dashboards die gegevens op een timer herladen, ook als niemand kijkt.
• Uptimemonitors die de app elke minuut pingen.
• Achtergrondlussen in de servercode — een setInterval die eeuwig opschoont of gegevens synchroniseert.
• Geplande „keep-alive”-verzoeken die iemand heeft toegevoegd om een trage eerste bezoek te voorkomen — die werken door het slapen tegen te houden, en dat is precies wat geld kost.

Vraag de AI om ze te vinden:

Zoek in de code naar alles wat op een timer draait of herhaaldelijk de database bevraagt: pollen, setInterval, automatisch vernieuwen, achtergrondlussen. Noem elk ervan, hoe vaak het draait, en of het draait wanneer niemand de pagina open heeft. Verander nog niets.

Repareer ze daarna één voor één:

Het dashboard pollt /api/orders elke 3 seconden. Verander het zo dat het alleen vernieuwt terwijl het browsertabblad zichtbaar is, en elke 60 seconden in plaats van 3. Voeg een handmatige knop Vernieuwen toe.

Als je app echt live updates nodig heeft (een chat, een live scorebord), vraag dan of hij updates alleen kan pushen wanneer er iets verandert, in plaats van voortdurend te vragen. Voor veel apps is „vernieuwen wanneer de gebruiker terugkomt naar het tabblad” voldoende.

Stap 3: Kies de juiste serverGrootte

Grotere machines kosten per uur meer. Veel door AI gebouwde apps starten op een standaardgrootte die prima is; problemen ontstaan wanneer men om „meer kracht” vraagt om traagheid op te lossen die eigenlijk door een trage query kwam.

• Houd de kleinste grootte aan die je verkeer zonder fouten aankan.
• Zie je geheugencrashes, vraag de AI dan eerst of de app te veel in het geheugen laadt (een hele tabel in plaats van één pagina met resultaten).
• Voeg alleen machines toe als je gemeten verkeer ze nodig heeft.

Op Mythex wordt de machinegrootte bij publiceren gekozen op basis van wat de app nodig heeft, en extra machines starten alleen bij zwaar verkeer en gaan weer slapen als het afneemt. De kosten volgen de grootte, dus vraag in de chat om een kleinere grootte als je denkt dat hij te groot is.

Stap 4: Verlaag de bandbreedte

Bandbreedte is wat bezoekers downloaden. Afbeeldingen vormen meestal het grootste deel.

• Comprimeer afbeeldingen en lever moderne formaten zoals WebP of AVIF.
• Verklein afbeeldingen naar het formaat waarin ze worden getoond. Een foto van 4.000 pixels die als miniatuur van 400 pixels wordt getoond, verspilt het meeste van wat er wordt gedownload.
• Laad afbeeldingen onder de vouw lazy.
• Cache statische bestanden (scripts, stijlen, afbeeldingen), zodat terugkerende bezoekers ze niet opnieuw downloaden. Zie wat caching is.
• Laat de app niet bij elke paginaweergave grote bestanden uitleveren.

Controleer elke afbeelding in de app. Verklein ze naar het grootste formaat waarin ze worden getoond, zet ze om naar WebP, en laad alles onder het eerste scherm lazy. Vertel me de totale grootte voor en na.

Sneller laden en lagere bandbreedte gaan meestal samen — zie hoe je je website sneller maakt.

Stap 5: Ruim op wat niemand gebruikt

• Haal oude apps offline — testdeployments, afgeronde experimenten, de eventsite van vorig jaar.
• Verwijder oude uploads, logs en exports die je niet nodig hebt.
• Verwijder gedeelde previewlinks die je niet meer gebruikt. Op Mythex wekt het openen van een previewlink het project en draait het op je credits, dus een vergeten link die iemand blijft openen, kost nog steeds geld.
• Verwijder ongebruikte services — een API-server of worker die de app niet meer aanroept.

Stap 6: Overweeg een statische site

Als je site geen logins, geen opgeslagen gebruikersgegevens en geen serverlogica heeft — een marketingsite, een portfolio, een menu — kan hij een statische site zijn: gewone bestanden die vanaf een CDN worden geserveerd. Er is geen server of database die moet blijven draaien. Op Mythex gebruiken statische sites geen credits terwijl ze er staan.

Deze site heeft geen logins of opgeslagen gegevens. Kan hij opnieuw worden gebouwd als statische site zonder server? Wat zouden we verliezen?

Stap 7: Let op betaalde API-aanroepen

Voor apps die AI-modellen, kaarten of sms gebruiken, kunnen rekeningen van derden de hosting ruimschoots overtreffen.

• Vereis inloggen voor alles wat per aanroep geld kost.
• Voeg een limiet per gebruiker toe (zie wat rate limiting is).
• Cache antwoorden die niet veranderen, zoals het geocoderen van hetzelfde adres.
• Stel bij elke provider uitgavenlimieten of waarschuwingen in.

Veelgemaakte fouten

• Gokken in plaats van meten. Bekijk eerst de gebruiksuitsplitsing; het dure deel is vaak niet wat je zou verwachten.
• Een grotere server kopen om traagheid op te lossen. Een ontbrekende databaseindex of het laden van te veel data is meestal de echte oorzaak.
• Alles pollen. Elke timer die elke paar seconden afgaat, is een reden voor de database om wakker te blijven.
• De app pingen om hem „warm” te houden. Dat haalt de besparing weg die schalen naar nul je geeft. Accepteer een korte opstart bij het eerste bezoek, of betaal bewust voor altijd aan.
• Oude deployments vergeten. Ongebruikte apps met databases en achtergrondtaken tellen stilletjes op.
• Niet-gecomprimeerde afbeeldingen. Vaak de grootste bandbreedtekost van kleine sites.

Checklist

• Ik weet welk project en welke categorie (rekenkracht, database, bandbreedte, opslag) het meest kost.
• Niets pollt de database elke paar seconden als niemand kijkt.
• Dashboards vernieuwen met een redelijk interval of alleen wanneer het tabblad zichtbaar is.
• Geen uptimemonitor of achtergrondlus houdt de app zonder reden wakker.
• De server is de kleinste grootte die werkt.
• Afbeeldingen zijn verkleind, gecomprimeerd en lazy geladen; statische bestanden zijn gecachet.
• Oude apps zijn offline gehaald, oude bestanden verwijderd, ongebruikte previewlinks verwijderd.
• Sites zonder gegevens of logins zijn statisch.
• Betaalde API’s hebben login, limieten per gebruiker en uitgavenwaarschuwingen bij de provider.

Kosten verlagen op Mythex

Mythex gebruikt één creditsaldo voor bouwen en hosting, dus besparingen op hosting laten meer credits over voor bouwen. Enkele punten specifiek voor Mythex:

• Gepubliceerde apps en hun databases slapen als ze inactief zijn en worden wakker bij het volgende bezoek. De database slaapt na 5 minuten inactiviteit, dus het stoppen van constant pollen is meestal de grootste winst.
• Pro betaalt de helft van het Free-tarief voor hosting, databases, bandbreedte, bestandsopslag en de preview-sandbox; AI kost op beide abonnementen hetzelfde. Zie Credits.
• Je krijgt een e-mail voordat een laag saldo een gepubliceerde app zou pauzeren, en gepauzeerde apps behouden hun database en bestanden.

Voor het bredere plaatje over de looptijdkosten, zie wat het kost om een app te bouwen en wat webhosting is.

Veelgestelde vragen