Så minskar du hostingkostnaderna för din app

För att minska hostingkostnaderna tar du reda på vad som faktiskt körs och varför, och låter sedan allt vila när ingen använder det. På värdar som skalar ner till noll kostar en inaktiv app och en vilande databas mycket lite, så de största besparingarna kommer oftast från att ta bort det som håller dem vakna, vilket oftast är kod som kollar databasen var några sekund. Sedan kommer besparingar från minskad bandbredd och från att ta bort appar som ingen använder.

De flesta små appar har inte ett trafikproblem. De har ett problem med att ”något alltid är på”. Den här guiden visar hur du hittar det och åtgärdar det, med prompter du kan ge en AI-appbyggare.

Vad du faktiskt betalar för

Hostingräkningar för små appar kommer från ett fåtal saker. Att veta vilken som är störst visar var du ska titta.

Många moderna värdar, inklusive Mythex, skalar ner till noll: när ingen använder appen stoppas servern och kostar ingenting för beräkning, och den vaknar vid nästa besök. Det ändrar frågan från ”hur stor är min server?” till ”varför är min server vaken?”

Steg 1: Titta på vart pengarna går

Innan du ändrar något öppnar du din värds användningssida och hittar:

• Vilket projekt som kostar mest. Ofta är det en app som står för större delen av räkningen.
• Vilken kategori: beräkning, databas, bandbredd eller lagring.
• När det spenderas. En jämn linje genom natten, när du inte har några användare, är ledtråden till att något håller appen vaken.

På Mythex visar Användningsdetaljer de senaste 30 dagarna uppdelat på Bygg (AI-agenten) och Kör (hosting, bandbredd, databas och fillagring), med en uppdelning per projekt.

Steg 2: Låt inaktiva appar och databaser vila

Det här är den verkliga spaken för de flesta små appar. En databas som vilar när den är inaktiv och vaknar vid nästa förfrågan kostar nästan ingenting under tysta timmar. En databas som frågas var några sekund blir aldrig inaktiv, så du betalar för den hela dagen.

Mythex gränser för hosting beskriver hur det fungerar för publicerade appar: en vilande app kostar ingenting för beräkning, databasen startar i sin minsta storlek, växer när den är upptagen, vilar efter 5 minuter av inaktivitet och debiteras för sin storlek multiplicerat med tiden den var vaken. En app som frågar sin databas även en gång var några minuter, dygnet runt, debiteras därför som om den alltid var upptagen. Samma app utan bakgrundsanrop kostar mycket lite.

Vanliga saker som håller en app vaken:

• Polling. En sida som frågar servern ”något nytt?” var 2–5 sekund. Lämna en flik öppen på en laptop så vilar aldrig databasen.
• Automatiskt uppdaterade instrumentpaneler som laddar om data med en timer, även när ingen tittar.
• Uptime-övervakning som pingar appen varje minut.
• Bakgrundsloopar i serverkoden, till exempel ett setInterval som städar eller synkar data för evigt.
• Schemalagda ”keep-alive”-anrop som någon lagt till för att undvika en långsam första visning. De fungerar genom att förhindra viloläge, vilket är exakt det som kostar pengar.

Fråga AI:n att hitta dem:

Gå igenom koden och leta efter allt som körs på en timer eller upprepat frågar databasen: polling, setInterval, automatisk uppdatering, bakgrundsloopar. Lista varje sådant, hur ofta det körs och om det körs när ingen har sidan öppen. Ändra ingenting än.

Sedan åtgärdar du dem en i taget:

Instrumentpanelen frågar /api/orders var 3:e sekund. Ändra så att den bara uppdaterar medan webbläsarfliken är synlig, och var 60:e sekund i stället för var 3:e. Lägg till en manuell uppdateringsknapp.

Behöver din app verkligen live-uppdateringar (en chatt, en live-resultattavla) fråga då om den kan skicka uppdateringar bara när något ändras, i stället för att fråga hela tiden. För många appar räcker det att uppdatera när användaren kommer tillbaka till fliken.

Steg 3: Dimensionera servern rätt

Större maskiner kostar mer per timme. Många AI-byggda appar startar på en standardstorlek som duger; problemen uppstår när man ber om ”mer kraft” för att åtgärda långsamhet som egentligen berodde på en långsam fråga.

• Behåll den minsta storlek som klarar din trafik utan fel.
• Ser du minneskrascher, fråga först AI:n om appen laddar in för mycket i minnet (en hel tabell i stället för en sida med resultat).
• Lägg bara till maskiner om du har mätt trafik som kräver det.

På Mythex väljs maskinstorleken vid publicering utifrån vad appen behöver. Extra maskiner startar bara när trafiken är hög och går tillbaka till vila när den minskar. Kostnaden följer storleken, så be i chatten om en mindre storlek om du tror att den är för stor.

Steg 4: Minska bandbredden

Bandbredd är vad besökare laddar ner. Bilder är oftast den största delen.

• Komprimera bilder och servera moderna format som WebP eller AVIF.
• Ändra storlek på bilder till den storlek de visas i. En foto på 4 000 pixlar som visas som en miniatyr på 400 pixlar slösar bort det mesta av det som laddas ner.
• Lazy-loada bilder som ligger under den första skärmen.
• Cachea statiska filer (skript, stilar, bilder) så att återkommande besökare inte laddar ner dem igen. Se vad caching är.
• Låt inte appen skicka stora filer vid varje sidvisning.

Kontrollera varje bild i appen. Ändra storleken till den största storlek de visas i, konvertera dem till WebP och lazy-loada allt under första skärmen. Berätta den totala storleken före och efter.

Snabbare sidor och lägre bandbredd hänger oftast ihop. Se så gör du din webbplats snabbare.

Steg 5: Städa bort det ingen använder

• Avpublicera gamla appar: testdeployeringar, avslutade experiment, förra årets eventsajt.
• Ta bort gamla uppladdningar, loggar och exporter du inte behöver.
• Ta bort delade förhandsgranskningslänkar du inte längre använder. På Mythex väcker det att öppna en förhandsgranskningslänk projektet och körs på dina krediter, så en glömd länk som någon fortsätter att öppna kostar.
• Ta bort tjänster som inte används, till exempel en API-server eller worker som appen inte längre anropar.

Steg 6: Överväg en statisk sajt

Om din sajt saknar inloggning, saknar sparad användardata och saknar serverlogik, till exempel en marknadsföringssajt, en portfolio eller en meny, kan den vara en statisk sajt: vanliga filer som serveras från ett CDN. Det finns ingen server eller databas som måste vara igång. På Mythex använder statiska sajter inga krediter medan de bara ligger där.

Den här sajten saknar inloggningar och sparad data. Kan den byggas om som statisk sajt utan server? Vad skulle vi förlora?

Steg 7: Håll koll på betalda API-anrop

För appar som anropar AI-modeller, kartor eller SMS kan räkningarna från tredje part vara större än hostingen.

• Kräv inloggning för allt som kostar pengar per anrop.
• Lägg till en gräns per användare (se vad rate limiting är).
• Cachea svar som inte ändras, till exempel geokodning av samma adress.
• Sätt utgiftstak eller larm hos varje leverantör.

Vanliga misstag

• Gissa i stället för att mäta. Kontrollera användningsfördelningen först. Den dyra delen är ofta inte det du tror.
• Köpa en större server för att åtgärda långsamhet. Ett saknat databasindex eller att man laddar för mycket data är oftast den verkliga orsaken.
• Polla allt. Varje timer på några sekunder är en anledning till att databasen håller sig vaken.
• Pinga appen för att hålla den ”varm”. Det tar bort den besparing som skalning till noll ger. Acceptera en kort uppvakning vid första besöket, eller betala för alltid-på medvetet.
• Glömma gamla deployeringar. Oanvända appar med databaser och bakgrundsjobb lägger tyst på kostnader.
• Okomprimerade bilder. Ofta den enskilt största bandbreddskostnaden för små sajter.

Checklista

• Jag vet vilket projekt och vilken kategori (beräkning, databas, bandbredd, lagring) som kostar mest.
• Ingenting frågar databasen var några sekund när ingen tittar.
• Instrumentpaneler uppdateras med ett rimligt intervall eller bara när fliken är synlig.
• Ingen uptime-övervakning eller bakgrundsloop håller appen vaken utan skäl.
• Servern är den minsta storlek som fungerar.
• Bilder är ändrade i storlek, komprimerade och lazy-loadade; statiska filer är cachade.
• Gamla appar är avpublicerade, gamla filer raderade och oanvända förhandsgranskningslänkar borttagna.
• Sajter utan data eller inloggningar är statiska.
• Betalda API:er har inloggning, gränser per användare och larm om utgifter hos leverantören.

Minska kostnaderna på Mythex

Mythex använder en gemensam kreditsaldo för både byggande och hosting, så besparingar i hostingen ger fler krediter kvar för byggandet. Några Mythex-specifika punkter:

• Publicerade appar och deras databaser vilar när de är inaktiva och vaknar vid nästa besök. Databasen vilar efter 5 minuters inaktivitet, så att ta bort konstant polling är oftast den största vinsten.
• Pro betalar hälften av Free-priset för hosting, databaser, bandbredd, fillagring och förhandsgranskningssandlådan. AI kostar lika mycket på båda planerna. Se Krediter.
• Du får ett mejl innan ett lågt saldo skulle pausa en publicerad app, och pausade appar behåller sin databas och sina filer.

För den större bilden kring driftskostnader, se vad det kostar att bygga en app och vad webbhosting är.

Frågor