The platform I host my side project on has replaced its free tier — how do I work out what it will actually cost before the bill arrives?

Get the number before you make any decision, because the two outcomes here are wildly different and people usually guess wrong about which one they are in.

Getting the honest number.

1. Find the usage view, not the pricing page. Every one of these platforms exposes current consumption per resource — compute time, memory-hours, storage, egress, database size, request counts. That is your actual consumption in the platform's own units, which is the only thing that multiplies cleanly against their rates.
2. Multiply it out by hand, per line. Do not trust a summary estimate. Take each metered dimension, take your last full month of it, multiply by the published rate, and write the lines down. The exercise takes twenty minutes and it almost always produces one surprising line.
3. Set a spending limit or a budget alert immediately, whatever they offer, at a number you would be annoyed but not hurt by. Do this before the analysis, not after. It is the difference between learning you were wrong from a notification and learning it from an invoice.

The line that surprises people is usually one of these three:

• Idle compute. Under an always-free allowance, an app sitting there doing nothing was free. Under usage billing, a container that runs 24/7 bills for 24/7 whether anyone visits or not. For a low-traffic app this is normally the entire bill. If the platform supports scaling to zero and starting on request, turning that on can take the cost of a hobby app to near nothing. The trade is a cold start on the first request after idle, which for a side project is usually completely acceptable.
• The database. Managed databases are often the largest single line and frequently cannot scale to zero, because something has to hold the data. A small always-on database can cost more than everything else combined.
• Egress. Usually trivial for an API. Not trivial if you serve images or files. Check before assuming.

Then the stay-or-move decision, which is mostly about the shape of your app rather than the price.

• A stateless container moves in an afternoon. It is a Dockerfile and some environment variables, and half a dozen platforms will run it. If that is all you have, your switching cost is genuinely low and you can be relaxed about it.
• State is the expensive part. A managed database, a queue, object storage, scheduled jobs, anything with a platform-specific API — that is what makes migration a project rather than an evening. Count those honestly before deciding you can leave whenever you like.

My actual advice, having done this twice: if the number comes out to less than a couple of coffees a month, pay it and get on with your life. The hours you would spend migrating are worth more, and a paid account tends to be a more stable place for something you care about than a free tier that exists at somebody's discretion.

If the number is genuinely uncomfortable, fix the shape first — scale to zero, right-size the database, move static assets to something that serves them cheaply — and re-measure. That usually closes the gap without a migration at all.

And if you do move: do not move to another free tier. You will be doing this again in eighteen months. Either pay a small amount somewhere stable, or self-host deliberately with your eyes open about the maintenance.

Before you calculate anything, delete the dead things.

Every hobby account I have ever audited had at least one abandoned deployment, an old preview environment, a database from a project that ended, or a storage bucket full of build artefacts. Under an always-free tier these cost nothing and so nobody notices them. Under usage billing they are a permanent line item for something nobody has opened in a year.

List everything running under the account and be ruthless. My own bill halved at that step, before I optimised anything real.

One thing to check specifically, because it has caught several people: what happens when the credit runs out.

There is a large difference between a platform that stops your app and one that starts charging your card. Both are defensible; only one of them can produce a surprise. Find out which it is, and if there is no spending cap available, treat that as a fact about the platform when you decide.

Also look at whether the change grandfathered existing projects. Sometimes there is a transition period, or existing apps stay on the old terms until they are redeployed — which matters a great deal for how urgent this is, and is often mentioned once in a blog post and never again.

If you do decide to move, take the opportunity to write down how the thing is deployed while you still remember.

A side project that has run untouched for two years on a platform that handled everything tends to have no deployment documentation at all, because there was nothing to document. The migration is when you discover which environment variables mattered and which cron job you forgot existed.

A short file in the repo describing what runs where, which secrets exist and what the database expects will make the next move — and there will be a next move — dramatically less painful.