Sådan reducerer du hostingomkostningerne for din app

For at reducere hostingomkostningerne skal du finde ud af, hvad der faktisk kører, og hvorfor, og derefter lade alt sove, når ingen bruger det. På hosts, der skalerer til nul, koster en inaktiv app og en sovende database meget lidt, så de største besparelser kommer typisk fra at fjerne det, der holder dem vågne – oftest kode, der tjekker databasen hvert par sekund – og derefter fra at skære i båndbredden og slette apps, ingen bruger.

De fleste små apps har ikke et trafikproblem. De har et "noget kører hele tiden"-problem. Denne guide viser, hvordan du finder og retter det med prompts, du kan give en AI-appbygger.

Hvad du faktisk betaler for

Hostingregninger for små apps kommer fra en håndfuld ting. At vide, hvilken der er størst, fortæller dig, hvor du skal kigge.

Mange moderne hosts, herunder Mythex, skalerer til nul: når ingen bruger appen, stopper serveren og koster intet på compute, og vågner så ved næste besøg. Det ændrer spørgsmålet fra "hvor stor er min server?" til "hvorfor er min server vågen?"

Trin 1: Se, hvor pengene går hen

Før du ændrer noget, skal du åbne din hosts forbrugsside og finde:

• Hvilket projekt der koster mest. Ofte er det én app, der udgør størstedelen af regningen.
• Hvilken kategori – compute, database, båndbredde eller lager.
• Hvornår der bruges penge. En flad linje om natten, når du ikke har brugere, er et tegn på, at noget holder appen vågen.

På Mythex viser forbrugsdetaljer de sidste 30 dage opdelt i Build (AI-agenten) og Run (hosting, båndbredde, database og filopbevaring), med en opdeling pr. projekt.

Trin 2: Lad inaktive apps og databaser sove

Dette er den egentlige løftestang for de fleste små apps. En database, der sover, når den er inaktiv, og vågner ved næste forespørgsel, koster næsten intet i stille timer. En database, der forespørges hvert par sekund, bliver aldrig inaktiv, så du betaler for den hele dagen.

Mythex' hostinggrænser forklarer, hvordan dette virker for publicerede apps: en app i dvale bruger intet på compute, og databasen starter i sin mindste størrelse, vokser, når den er travl, sover efter 5 minutter uden aktivitet, og opkræves for sin størrelse ganget med den tid, den har været vågen. En app, der forespørger sin database selv én gang hvert par minutter, døgnet rundt, bliver altså faktureret, som om den altid var travl – mens den samme app uden baggrundsaktivitet koster meget lidt.

Ting, der holder en app vågen:

• Polling. En side, der spørger serveren "er der noget nyt?" hvert 2.–5. sekund. Lad én fane stå åben på én bærbar, og databasen sover aldrig.
• Auto-opdaterende dashboards, der henter data på et timer, selv når ingen kigger.
• Oppetidsmonitorer, der pinger appen hvert minut.
• Baggrundsløkker i serverkoden – en setInterval, der rydder op eller synkroniserer data for evigt.
• Planlagte "keep-alive"-forespørgsler, som nogen har tilføjet for at undgå et langsomt første besøg – de virker ved at forhindre dvale, og det er netop det, der koster penge.

Bed AI'en finde dem:

Gennemgå koden og find alt, der kører på et timer eller gentagne gange forespørger databasen: polling, setInterval, auto-opdatering, baggrundsløkker. List hver enkelt, hvor ofte den kører, og om den kører, når ingen har siden åben. Ændr ikke noget endnu.

Ret derefter dem én for én:

Dashboardet poller /api/orders hvert 3. sekund. Ændr det, så det kun opdaterer, mens browserfanen er synlig, og hvert 60. sekund i stedet for hvert 3. Tilføj en manuel Opdater-knap.

Hvis din app virkelig har brug for live-opdateringer (en chat, en live-scoreboard), så spørg, om den kan sende opdateringer, kun når noget ændrer sig, i stedet for at spørge hele tiden. For mange apps er "opdater, når brugeren vender tilbage til fanen" nok.

Trin 3: Vælg den rette serverstørrelse

Større maskiner koster mere pr. time. Mange AI-byggede apps starter på en standardstørrelse, der er fin; problemerne opstår, når man beder om "mere kraft" for at rette en langsomhed, der i virkeligheden skyldes en langsom forespørgsel.

• Behold den mindste størrelse, der betjener din trafik uden fejl.
• Hvis du ser hukommelsesnedbrud, så spørg først AI'en, om appen indlæser for meget i hukommelsen (en hel tabel i stedet for én side med resultater).
• Tilføj kun maskiner, hvis du har målt trafik, der kræver det.

På Mythex vælges maskinestørrelsen ved publicering ud fra, hvad appen har brug for, og ekstra maskiner starter kun, når trafikken er høj, og går tilbage i dvale, når den falder. Omkostningen følger størrelsen, så bed i chatten om en mindre størrelse, hvis du mener, den er for stor.

Trin 4: Reducer båndbredden

Båndbredde er det, besøgende henter. Billeder er som regel den største del.

• Komprimér billeder, og brug moderne formater som WebP eller AVIF.
• Skalér billeder til den størrelse, de vises i. Et foto på 4.000 pixels, der vises som en 400-pixel miniature, spilder det meste af det, der hentes.
• Lazy-load billeder under den første skærm.
• Cache statiske filer (scripts, styles, billeder), så besøgende, der kommer igen, ikke henter dem på ny. Se hvad caching er.
• Lad ikke appen udlevere store filer ved hver sidevisning.

Gennemgå hvert billede i appen. Skalér dem til den største størrelse, de vises i, konverter dem til WebP, og lazy-load alt under den første skærm. Fortæl mig den samlede størrelse før og efter.

Lavere båndbredde og hurtigere sider hænger ofte sammen – se sådan gør du din hjemmeside hurtigere.

Trin 5: Ryd op i det, ingen bruger

• Afpublicér gamle apps – testdeployments, afsluttede eksperimenter, sidste års eventside.
• Slet gamle uploads, logs og eksporter, du ikke har brug for.
• Slet delte preview-links, du ikke længere bruger. På Mythex vækker det at åbne et preview-link projektet og bruger dine kreditter, så et glemt link, som nogen bliver ved med at åbne, stadig koster penge.
• Fjern ubrugte tjenester – en API-server eller worker, appen ikke længere kalder.

Trin 6: Overvej et statisk site

Hvis dit site ikke har logins, ingen gemte brugerdata og ingen serverlogik – en markedsføringsside, en portefølje, en menu – kan det være et statisk site: almindelige filer leveret fra et CDN. Der er ingen server eller database, der skal køre. På Mythex bruger statiske sites ikke kreditter, mens de bare ligger der.

Dette site har ingen logins eller gemte data. Kan det bygges om som et statisk site uden server? Hvad ville vi miste?

Trin 7: Hold øje med betalte API-kald

For apps, der kalder AI-modeller, kort eller sms, kan tredjepartsregningerne overgå hostingen markant.

• Kræv login for alt, der koster penge pr. kald.
• Tilføj en grænse pr. bruger (se hvad rate limiting er).
• Cache svar, der ikke ændrer sig, for eksempel geokodning af den samme adresse.
• Sæt forbrugslofter eller advarsler hos hver udbyder.

Almindelige fejl

• At gætte i stedet for at måle. Tjek forbrugsopdelingen først; den dyre del er ofte ikke det, du forventer.
• At købe en større server for at rette langsomhed. Et manglende databaseindeks eller indlæsning af for mange data er som regel den egentlige årsag.
• At polle alt. Hvert timer, der kører hvert par sekund, er en grund til, at databasen forbliver vågen.
• At pinge appen for at holde den "varm". Det fjerner den besparelse, scale-to-zero giver dig. Acceptér en kort opvågning ved første besøg, eller betal bevidst for altid tændt.
• At glemme gamle deployments. Ubrugte apps med databaser og baggrundsjobs lægger sig stille og roligt op.
• Ukomprimerede billeder. Ofte den enkeltstående største båndbreddeomkostning på små sites.

Tjekliste

• Jeg ved, hvilket projekt og hvilken kategori (compute, database, båndbredde, lager) der koster mest.
• Intet poller databasen hvert par sekund, når ingen kigger.
• Dashboards opdaterer med en fornuftig interval eller kun, mens fanen er synlig.
• Ingen oppetidsmonitor eller baggrundsløkke holder appen vågen uden grund.
• Serveren er den mindste størrelse, der virker.
• Billeder er skaleret, komprimeret og lazy-loaded; statiske filer er cachet.
• Gamle apps er afpublicerede, gamle filer slettet, ubrugte preview-links fjernet.
• Sites uden data eller logins er statiske.
• Betalte API'er har login, grænser pr. bruger og forbrugsadvarsler hos udbyderen.

Reducer omkostninger på Mythex

Mythex bruger én kreditsaldo til både at bygge og hoste, så besparelser på hosting giver flere kreditter til at bygge med. Et par Mythex-specifikke punkter:

• Publicerede apps og deres databaser sover, når de er inaktive, og vågner ved næste besøg. Databasen sover efter 5 minutters inaktivitet, så det at fjerne konstant polling er typisk den største gevinst.
• Pro betaler halvdelen af Free-prisen for hosting, databaser, båndbredde, filopbevaring og preview-sandkassen; AI koster det samme på begge planer. Se Kreditter.
• Du får en e-mail, før en lav saldo ville sætte en publiceret app på pause, og apps på pause beholder deres database og filer.

For det større billede af driftsomkostninger, se hvad koster det at bygge en app og hvad webhosting er.

Spørgsmål