Paano Bawasan ang Hosting Costs ng Iyong App

Para bawasan ang hosting costs, alamin kung ano talaga ang tumatakbo at kung bakit, saka hayaang matulog ang lahat kapag walang gumagamit. Sa mga host na nag-i-scale to zero, mura lang ang idle na app at natutulog na database, kaya kadalasang nagmumula ang pinakamalaking pagtitipid sa pag-alis ng mga bagay na nagpapanatiling gising sa kanila — kadalasan ang code na tumitingin sa database kada ilang segundo — at pagkatapos ay sa pagpapaliit ng bandwidth at pagbura ng mga app na walang gumagamit.

Karamihan sa maliliit na app ay hindi problema sa trapiko. Problema nila ang "laging nakabukas". Ipinapakita ng gabay na ito kung paano ito hanapin at ayusin, kasama ang mga prompt na maibibigay mo sa AI app builder.

Ano ang aktuwal mong binabayaran

Nagmumula ang bayarin ng maliliit na app sa iilang bagay. Ang pag-alam kung alin ang malaki ang nagsasabi kung saan titingin.

Maraming modernong host, kasama ang Mythex, ang nag-i-scale to zero: kapag walang gumagamit ng app, humihinto ang server at walang gastos sa compute, at gumigising ito sa susunod na bisita. Binabago nito ang tanong mula "gaano kalaki ang server ko?" tungo sa "bakit gising ang server ko?"

Hakbang 1: Tingnan kung saan napupunta ang pera

Bago magbago ng anuman, buksan ang usage page ng host mo at hanapin:

• Aling project ang pinakamahal. Kadalasan, isang app lang ang bumubuo ng malaking bahagi ng bill.
• Aling kategorya — compute, database, bandwidth o storage.
• Kailan ito gumagastos. Ang patag na linya sa gabi, kapag walang user, ay palatandaan na may bagay na nagpapanatiling gising sa app.

Sa Mythex, ipinapakita ng Usage details ang huling 30 araw na hinati sa Build (ang AI agent) at Run (hosting, bandwidth, database at file storage), na may breakdown ayon sa project.

Hakbang 2: Hayaang matulog ang idle na app at database

Ito ang tunay na lever para sa karamihan ng maliliit na app. Ang database na natutulog kapag idle at gumigising sa susunod na request ay halos walang gastos sa tahimik na oras. Ang database na kinokonsulta kada ilang segundo ay hindi kailanman nagiging idle, kaya nagbabayad ka buong araw.

Ipinapaliwanag ng hosting limits ng Mythex kung paano ito gumagana para sa published apps: walang nagagastos sa compute ang natutulog na app, nagsisimula sa pinakamaliit na laki ang database, lumalaki kapag abala, natutulog pagkatapos ng 5 minutong idle, at sinisingil batay sa laki nito na pinarami ng oras na gising ito. Kaya ang app na tumitingin sa database kahit minsan kada ilang minuto, araw at gabi, ay sinisingil na parang laging abala — habang ang parehong app na walang background na aktibidad ay halos walang gastos.

Mga karaniwang bagay na nagpapanatiling gising sa app:

• Polling. Pahina na nagtatanong sa server ng "may bago ba?" kada 2–5 segundo. Kapag may isang laptop na nakabukas ang tab na iyon, hindi kailanman makakatulog ang database.
• Mga auto-refresh na dashboard na nagre-reload ng data sa timer, kahit walang tumitingin.
• Uptime monitors na nagpi-ping sa app kada minuto.
• Background loops sa server code — isang setInterval na naglilinis o nagsi-sync ng data nang walang katapusan.
• Scheduled na "keep-alive" requests na idinagdag ng isang tao para maiwasan ang mabagal na unang bisita — gumagana ang mga ito sa pagpigil sa pagtulog, at iyon mismo ang nagkakaltas ng pera.

Hilingin sa AI na hanapin ang mga ito:

Hanapin sa code ang anumang tumatakbo sa timer o paulit-ulit na tumitingin sa database: polling, setInterval, auto-refresh, background loops. Ilista ang bawat isa, kung gaano kadalas ito tumatakbo, at kung tumatakbo ito kapag walang nakabukas na pahina. Huwag munang baguhin ang anuman.

Pagkatapos, ayusin ang isa-isa:

Kumukuha ng data ang dashboard mula sa /api/orders kada 3 segundo. Baguhin ito para mag-refresh lamang habang nakikita ang browser tab, at kada 60 segundo sa halip na 3. Magdagdag ng manual na Refresh button.

Kung talagang kailangan ng app mo ang live updates (chat, live scoreboard), itanong kung puwede itong mag-push ng updates lamang kapag may nagbago, sa halip na magtanong nang tuloy-tuloy. Para sa maraming app, sapat na ang "mag-refresh kapag bumalik ang user sa tab".

Hakbang 3: Itugma ang laki ng server

Mas mahal kada oras ang mas malalaking makina. Maraming app na binuo ng AI ang nagsisimula sa default na laking sapat na; ang problema ay kapag humihingi ng "mas maraming lakas" para ayusin ang kabagalang sa totoo ay mabagal na query.

• Panatilihin ang pinakamaliit na laki na nagseserbisyo sa trapiko mo nang walang error.
• Kung nakakakita ka ng memory crashes, tanungin muna ang AI kung masyadong maraming data ang nilo-load ng app sa memorya (buong table sa halip na isang pahina ng resulta).
• Magdagdag lamang ng makina kung may nasukat kang trapikong nangangailangan nito.

Sa Mythex, pinipili ang laki ng makina kapag na-publish batay sa kailangan ng app, at nagsisimula lang ang dagdag na makina kapag mabigat ang trapiko at natutulog ulit kapag bumaba ito. Sumusunod ang gastos sa laki, kaya humiling sa chat ng mas maliit na laki kung sa tingin mo ay sobra ito.

Hakbang 4: Paliitin ang bandwidth

Ang bandwidth ay ang dina-download ng bisita. Kadalasang pinakamalaking bahagi ang mga larawan.

• I-compress ang mga larawan at gumamit ng modernong format gaya ng WebP o AVIF.
• I-resize ang mga larawan sa laki kung saan ipinapakita ang mga ito. Ang 4,000-pixel na larawan na ipinapakita bilang 400-pixel na thumbnail ay sinasayang ang halos lahat ng dina-download.
• I-lazy-load ang mga larawang nasa ibaba ng unang screen.
• I-cache ang static files (scripts, styles, larawan) para hindi na muling i-download ng bumabalik na bisita. Tingnan ang ano ang caching.
• Huwag hayaang mag-abot ang app ng malalaking file sa bawat page view.

Suriin ang bawat larawan sa app. I-resize ang mga ito sa pinakamalaking laki kung saan ipinapakita ang mga ito, i-convert sa WebP, at i-lazy-load ang anumang nasa ibaba ng unang screen. Sabihin mo sa akin ang kabuuang laki bago at pagkatapos.

Kadalasang magkasabay ang mas mabilis na pahina at mas mababang bandwidth — tingnan ang paano gawing mas mabilis ang website mo.

Hakbang 5: Linisin ang hindi ginagamit

• I-unpublish ang mga lumang app — mga test deployment, tapos nang eksperimento, event site noong nakaraang taon.
• Burahin ang lumang uploads, logs at exports na hindi mo na kailangan.
• Burahin ang mga shared preview link na hindi mo na ginagamit. Sa Mythex, ang pagbukas ng preview link ay gumigising sa project at tumatakbo sa credits mo, kaya ang nakalimutang link na patuloy na binubuksan ng isang tao ay may gastos pa rin.
• Alisin ang hindi nagagamit na services — API server o worker na hindi na tinatawagan ng app.

Hakbang 6: Isaalang-alang ang static site

Kung walang login, walang naka-save na user data at walang server logic ang site mo — marketing site, portfolio, menu — puwede itong maging static site: mga simpleng file na inihahatid mula sa CDN. Walang server o database na kailangang patakbuhin. Sa Mythex, hindi gumagamit ng credits ang static sites habang nakaupo lang ang mga ito.

Walang login o naka-save na data ang site na ito. Puwede bang gawing muli bilang static site na walang server? Ano ang mawawala sa atin?

Hakbang 7: Bantayan ang bayad na API calls

Para sa mga app na tumatawag sa AI model, maps o SMS, maaaring lampasan ng third-party bill ang hosting.

• Mangailangan ng login para sa anumang may bayad kada tawag.
• Maglagay ng per-user na limitasyon (tingnan ang ano ang rate limiting).
• I-cache ang mga sagot na hindi nagbabago, gaya ng geocoding ng parehong address.
• Magtakda ng spending cap o alerto sa bawat provider.

Mga karaniwang pagkakamali

• Paghula sa halip na pagsukat. Tingnan muna ang usage breakdown; madalas na hindi ang inaasahan mo ang mahal.
• Pagbili ng mas malaking server para ayusin ang kabagalan. Ang kulang na database index o sobrang dami ng data na nilo-load ang kadalasang totoong sanhi.
• Pag-poll sa lahat. Ang bawat timer na kada ilang segundo ay dahilan para manatiling gising ang database.
• Pag-ping sa app para manatiling "mainit". Inaalis nito ang pagtitipid na ibinibigay ng scale-to-zero. Tanggapin ang maikling paggising sa unang bisita, o magbayad nang sinasadya para sa always-on.
• Nakakalimutang lumang deployment. Ang mga hindi nagagamit na app na may database at background jobs ay tahimik na nagdadagdag ng gastos.
• Hindi naka-compress na larawan. Kadalasan ang pinakamalaking gastos sa bandwidth ng maliliit na site.

Checklist

• Alam ko kung aling project at aling kategorya (compute, database, bandwidth, storage) ang pinakamahal.
• Walang nagpo-poll sa database kada ilang segundo kapag walang tumitingin.
• Nagre-refresh ang mga dashboard sa makatwirang agwat o habang nakikita lang ang tab.
• Walang uptime monitor o background loop na nagpapanatiling gising ang app nang walang dahilan.
• Pinakamaliit na laki ng server na gumagana ang gamit.
• Na-resize, na-compress at na-lazy-load ang mga larawan; naka-cache ang static files.
• Na-unpublish ang mga lumang app, nabura ang lumang file, at naalis ang hindi nagagamit na preview links.
• Ang mga site na walang data o login ay static.
• May login, per-user na limitasyon, at spending alerts sa provider ang mga bayad na API.

Pagbabawas ng gastos sa Mythex

Iisang credit balance ang ginagamit ng Mythex para sa paggawa at hosting, kaya ang pagtitipid sa hosting ay nag-iiwan ng mas maraming credits para sa paggawa. Ilang punto na tiyak sa Mythex:

• Natutulog ang published apps at ang kanilang database kapag idle at gumigising sa susunod na bisita. Natutulog ang database pagkatapos ng 5 minutong idle, kaya ang pag-alis ng constant polling ang kadalasang pinakamalaking panalo.
• Nagbabayad ang Pro ng kalahati ng Free rate para sa hosting, databases, bandwidth, file storage at preview sandbox; pareho ang gastos ng AI sa dalawang plan. Tingnan ang Credits.
• Makakatanggap ka ng email bago pa mapause ang published app dahil sa mababang balanse, at pinapanatili ng mga naka-pause na app ang kanilang database at mga file.

Para sa mas malawak na larawan ng gastos sa pagpapatakbo, tingnan ang magkano ang gastos sa paggawa ng app at ano ang web hosting.

Mga tanong