Free for Dev: What the Free Tiers Actually Cover, and Where They Stop

Free for dev is a community-maintained list of services with free developer tiers, and it is genuinely useful, but it is an index rather than a recommendation. The tiers on it fall into three groups: ones that are effectively permanent and fine for real projects, ones that are trials wearing a free-tier costume, and ones that are free until a single specific limit is crossed and then are not free at all.

Anyone can assemble a full stack from free tiers in an afternoon. The interesting question is which of those choices you will still be happy with in six months, and the answer depends far less on the size of the free allowance than on which dimension the allowance is measured in.

How to read a free tier in thirty seconds
The categories that genuinely hold up
The limits that bite first
The stack that survives contact with users
The free tier that costs the most
When to pay, and what to pay for
How this fits the rest of the stack
FAQ

How to read a free tier in thirty seconds

Every free tier is generous along some axis and tight along another. The tight axis is the one that will end the arrangement, so find it first.

Time-limited. Free for a fixed period, then priced. This is a trial. Useful, but do not build on it.
Credit-limited. A monetary allowance per month against normal pricing. Predictable, and it runs out faster than expected because every component draws from the same pot.
Resource-limited. A fixed amount of compute, storage, rows or bandwidth. The most honest shape, and the easiest to plan against.
Feature-limited. Unlimited usage, but the parts you eventually need are on a paid tier. Fine, as long as you check which parts before you build.
Sleep-limited. Free while idle, but the instance is suspended after inactivity and takes seconds to wake. Fine for a demo, fatal for anything with users.

The question to ask is not how much is free. It is which of these five shapes applies, because that determines what happens on the day the project succeeds.

The categories that genuinely hold up

Some free tiers are structurally sustainable, because the marginal cost to the provider is near zero and the tier exists to build habit rather than to convert.

Source hosting and CI for public repositories. Effectively permanent, generous, and the paid upgrade is about privacy and minutes rather than about being cut off.
Static site hosting with a build step. Bandwidth allowances are typically far beyond what a personal site uses, and the failure mode is a bill rather than an outage.
Error tracking and uptime monitoring. Free tiers are limited by event volume, which for a small project is not close to the ceiling.
Transactional email at low volume. Enough for password resets and notifications on a small user base.
DNS and certificate issuance. Genuinely free at the layer that matters, and no serious project should be paying for certificates.

A project built entirely from this list can run indefinitely at zero cost, and that is a real and underrated fact about the modern web.

The limits that bite first

In roughly the order they arrive:

Cold starts. The free compute tier sleeps after fifteen or thirty minutes of inactivity. The first visitor after a quiet period waits several seconds, and that visitor is disproportionately likely to be someone you wanted to impress.
Database row or storage caps. Free database tiers cap total size, and analytics or logging tables reach the cap far sooner than application data does.
Connection limits. A free database tier with a low connection cap plus a serverless runtime that opens connections per invocation is a specific and common failure, and it surfaces under load rather than in testing.
Build minutes. Fine until you add a test suite, then fine until you add a second developer, then suddenly the constraint on how often anyone can merge.
Outbound bandwidth. The one that turns free into a bill without warning, because a single popular link can move more data in a day than the previous six months combined.

Notice that four of the five are invisible in development. They are all load-related or time-related, which is exactly why free tiers feel unlimited right up until they do not.

The stack that survives contact with users

A practical division: use free tiers for everything that is not on the request path, and pay for the things that are.

Free is fine for source hosting, CI, monitoring, error tracking, DNS, certificates, and the static parts of the front end. None of those get slower when a user arrives, and none of them cause an outage when the allowance runs out.

Pay for the application server and the database, and pay early. These are the two components where the free tier’s constraints are exactly the constraints your users experience: cold starts, connection caps and storage limits. The amount of money involved is small and the difference in behaviour is large.

That split also has a migration benefit. The free components are the ones with no data and no state, so changing them later is cheap. The paid components are the ones holding data, and those are the ones you least want to move under pressure.

The free tier that costs the most

The genuine cost of a free-tier stack is rarely money. It is the number of vendors.

A project assembled from seven free tiers has seven dashboards, seven sets of credentials, seven status pages and seven independent ways to break. Debugging a slow request means checking whether it was the edge, the function, the database, the pooler or the storage layer, and each of those answers lives in a different console with a different login.

There is also a quieter cost: nothing shares a private network. Every hop between components goes out over the public internet and back, which adds latency to every request and puts credentials on the wire for connections that could have been internal.

The comparison worth making is not free versus paid. It is seven free services versus two or three paid ones, and once an hour of your time is priced at anything at all, the second option is frequently cheaper in total.

When to pay, and what to pay for

Three signals that the free stage is over:

Someone other than you is relying on it. A cold start is an annoyance for the author and an outage for a user.
There is data in it you would be upset to lose. Free tiers rarely include backups, and restore is not a feature you want to discover the absence of.
You have started working around a limit rather than using the service. Building a keepalive pinger to stop an instance sleeping is a sign you have outgrown the tier and are paying for it in complexity instead of cash.

The first paid step should be small and should target the request path: a running application instance that does not sleep, and a database with backups and a connection limit that matches the traffic. That is usually a very modest monthly figure, and it removes the majority of the operational weirdness in one move.

How this fits the rest of the stack

The useful exercise when leaving the free tier is to price the pieces you would actually keep, rather than assuming the paid version of a free stack is the same stack with a card attached. The RunxBuild hosting calculator lists them separately so the total is visible in advance: the service, the database, the storage and the bandwidth. For context on the size of that first step, the RunxBuild ladder starts at a Free plan with fifteen free days a month and a Dev plan at four dollars, static sites include 120GB of bandwidth, and a managed MySQL or Postgres instance sits on the same private network as the service rather than across the public internet.

Useful related references:

FAQ

Is free-for.dev safe to build a real project on?

The list is accurate and well maintained, but it is an index of offers rather than an endorsement. Individual tiers change without notice. Treat it as a starting point for research and check each provider’s current terms before depending on one.

Which free tier limit causes the most problems?

Instance sleeping, followed by database connection limits. Both are invisible during development and both appear exactly when real users arrive. Sleeping produces multi-second first loads and connection caps produce errors under concurrency.

Can I run a production app entirely on free tiers?

Technically yes, and plenty of small projects do. The constraints are cold starts, no backups, no support and a large number of separate vendors. Whether that is acceptable depends entirely on who is relying on the app and what happens if it is down for a day.

Do free tiers include backups?

Usually not, and this is the single most important thing to check. A free database tier frequently has no automated backup and no point-in-time restore. If the data matters, either pay for a tier that includes backups or run your own scheduled dump to storage you control.

When should I start paying for hosting?

When someone other than you depends on the service, when it holds data you would be upset to lose, or when you find yourself building workarounds for a tier limit. The first paid step should cover the request path: an instance that does not sleep and a database with backups.