Guides / Prompting and shipping

How to Reduce Hosting Costs for Your App

Cut your app's hosting bill: find what is running, let idle apps and databases sleep, stop constant polling, shrink bandwidth and remove what nobody uses.

Mythex Team · 2026-09-29 · 7 min read

To reduce hosting costs, find out what is actually running and why, then let everything sleep when nobody is using it. On hosts that scale to zero, an idle app and a sleeping database cost very little, so the biggest savings usually come from removing whatever keeps them awake — most often code that checks the database every few seconds — and then from shrinking bandwidth and deleting apps nobody uses.

Most small apps don't have a traffic problem. They have a "something is always on" problem. This guide shows how to find it and fix it, with prompts you can give an AI app builder.

What you actually pay for

Hosting bills for small apps come from a handful of things. Knowing which one is large tells you where to look.

Many modern hosts, including Mythex, scale to zero: when nobody is using the app, the server stops and costs nothing for compute, then wakes on the next visit. That changes the question from "how big is my server?" to "why is my server awake?"

Step 1: Look at where the money goes

Before changing anything, open your host's usage page and find:

• Which project costs the most. Often one app is most of the bill.
• Which category — compute, database, bandwidth or storage.
• When it spends. A flat line through the night, when you have no users, is the clue that something keeps the app awake.

On Mythex, Usage details shows the last 30 days split into Build (the AI agent) and Run (hosting, bandwidth, database and file storage), with a breakdown by project.

Step 2: Let idle apps and databases sleep

This is the real lever for most small apps. A database that sleeps when idle and wakes on the next request costs almost nothing during quiet hours. A database that is queried every few seconds never goes idle, so you pay for it all day.

Mythex's hosting limits spell out how this works for published apps: a sleeping app spends nothing on compute, and the database starts at its smallest size, grows while busy, sleeps after 5 idle minutes, and is charged for its size multiplied by the time it was awake. So an app that queries its database even once every few minutes, day and night, is billed as if it were always busy — while the same app with no background chatter costs very little.

Common things that keep an app awake:

• Polling. A page that asks the server "anything new?" every 2–5 seconds. Leave that tab open on one laptop and the database never sleeps.
• Auto-refreshing dashboards that reload data on a timer, even when nobody is looking.
• Uptime monitors that ping the app every minute.
• Background loops in the server code — a setInterval that cleans up or syncs data forever.
• Scheduled "keep-alive" requests someone added to avoid a slow first visit — they work by preventing sleep, which is exactly what costs money.

Ask the AI to find them:

Look through the code for anything that runs on a timer or repeatedly queries the database: polling, setInterval, auto-refresh, background loops. List each one, how often it runs, and whether it runs when nobody has the page open. Don't change anything yet.

Then fix them one by one:

The dashboard polls /api/orders every 3 seconds. Change it to refresh only while the browser tab is visible, and every 60 seconds instead of 3. Add a manual Refresh button.

If your app genuinely needs live updates (a chat, a live scoreboard), ask whether it can push updates only when something changes, rather than asking constantly. For many apps, "refresh when the user comes back to the tab" is enough.

Step 3: Right-size the server

Bigger machines cost more per hour. Many AI-built apps start on a default size that's fine; problems come from asking for "more power" to fix a slowness that was really a slow query.

• Keep the smallest size that serves your traffic without errors.
• If you see memory crashes, first ask the AI whether the app loads too much into memory (a whole table instead of one page of results).
• Only add machines if you have measured traffic that needs them.

On Mythex, the machine size is chosen at publish based on what the app needs, and extra machines start only when traffic is heavy and go back to sleep when it drops. Cost follows size, so ask in chat for a smaller size if you think it's oversized.

Step 4: Cut bandwidth

Bandwidth is what visitors download. Images are usually the biggest part.

• Compress images and serve modern formats such as WebP or AVIF.
• Resize images to the size they're shown at. A 4,000-pixel photo displayed as a 400-pixel thumbnail wastes most of what's downloaded.
• Lazy-load images below the fold.
• Cache static files (scripts, styles, images) so returning visitors don't download them again. See what caching is.
• Don't let the app hand out large files on every page view.

Check every image in the app. Resize them to the largest size they're displayed at, convert them to WebP, and lazy-load anything below the first screen. Tell me the total size before and after.

Faster pages and lower bandwidth usually go together — see how to make your website faster.

Step 5: Clean up what nobody uses

• Unpublish old apps — test deployments, finished experiments, last year's event site.
• Delete old uploads, logs and exports you don't need.
• Delete shared preview links you no longer use. On Mythex, opening a preview link wakes the project and runs on your credits, so a forgotten link someone keeps opening still costs.
• Remove unused services — an API server or worker the app no longer calls.

Step 6: Consider a static site

If your site has no logins, no saved user data and no server logic — a marketing site, a portfolio, a menu — it can be a static site: plain files served from a CDN. There is no server or database to keep running. On Mythex, static sites don't use credits while they sit there.

This site has no logins or saved data. Can it be rebuilt as a static site with no server? What would we lose?

Step 7: Watch paid API calls

For apps that call AI models, maps or SMS, third-party bills can dwarf hosting.

• Require login for anything that costs money per call.
• Add a per-user limit (see what rate limiting is).
• Cache answers that don't change, such as geocoding the same address.
• Set spending caps or alerts at each provider.

Common mistakes

• Guessing instead of measuring. Check the usage breakdown first; the expensive part is often not what you'd expect.
• Buying a bigger server to fix slowness. A missing database index or loading too much data is usually the real cause.
• Polling everything. Every few-second timer is a reason for the database to stay awake.
• Pinging the app to keep it "warm". That removes the saving scale-to-zero gives you. Accept a short wake-up on the first visit, or pay for always-on deliberately.
• Forgetting old deployments. Unused apps with databases and background jobs quietly add up.
• Uncompressed images. Often the single largest bandwidth cost on small sites.

Checklist

• I know which project and which category (compute, database, bandwidth, storage) costs most.
• Nothing polls the database every few seconds when nobody is looking.
• Dashboards refresh on a sensible interval or only while the tab is visible.
• No uptime monitor or background loop keeps the app awake without a reason.
• The server is the smallest size that works.
• Images are resized, compressed and lazy-loaded; static files are cached.
• Old apps are unpublished, old files deleted, unused preview links removed.
• Sites with no data or logins are static.
• Paid APIs have login, per-user limits and provider spending alerts.

Reducing costs on Mythex

Mythex uses one credit balance for building and for hosting, so hosting savings leave more credits for building. A few Mythex-specific points:

• Published apps and their databases sleep when idle and wake on the next visit. The database sleeps after 5 idle minutes, so removing constant polling is usually the biggest win.
• Pro pays half the Free rate for hosting, databases, bandwidth, file storage and the preview sandbox; AI costs the same on both plans. See Credits.
• You get an email before a low balance would pause a published app, and paused apps keep their database and files.

For the bigger picture on running costs, see how much it costs to build an app and what web hosting is.