Render’s free tier gives you 750 instance hours a month for web services, free static sites, and a free Postgres and key-value store - with the important catches that free web services spin down when idle and can be restarted at any time, free Postgres is capped at 1GB and expires after 30 days, and persistent disks are not available. It is a genuinely useful tier for learning and small personal projects, as long as you know which limits will bite.
Free tiers are marketing until you read the limits. Here is what Render’s actually includes, and the framework for judging any free plan the same way.
Table of contents
- The compute allowance
- What the free plan cannot do
- The database expiry nobody reads
- How to judge any free tier
- Where RunxBuild fits
- FAQ
The compute allowance
Free web services get 750 instance hours per month, reset at the start of each month and not rolled over. That is almost exactly enough to run a single service continuously, since a month is about 744 hours - the number is designed to give you one always-on free service, not several.
The catch is spin-down: a free web service that receives no traffic is suspended, and the next request wakes it, which means a cold start of some seconds. For a hobby project or a demo that is fine. For anything a user expects to respond instantly, the first-request delay is the limit you will feel.
What the free plan cannot do
Free compute plans deliberately omit features of the paid tiers. There are no persistent disks, so you cannot store files that survive a restart on a free service. You cannot run one-off jobs. And Render reserves the right to restart a free service at any time.
None of these are bugs - they are how a free tier stays sustainable. They do mean that a free service must be stateless: keep data in a database, not on local disk, and assume the process can be restarted or spun down between requests. Design around that and the free tier behaves predictably.
The database expiry nobody reads
The limit that surprises people most: free Postgres is a single instance, capped at 1GB, and it expires after 30 days. After that window the free database is removed, so it is suitable for a prototype, a tutorial, or a short-lived demo - not for anything you expect to keep.
The free key-value (Redis-compatible) store is in-memory only and single-instance, so it is a cache, not durable storage. The pattern across the free tier is consistent: great for exploring and building, explicitly not built to quietly become production under you.
How to judge any free tier
The useful habit when comparing free plans is to ask three questions. What are the hard resource limits - compute hours, memory, bandwidth, storage? Does anything expire or spin down - do services sleep on idle, do databases disappear after a window? And what is the upgrade cliff - when you outgrow free, what does the next tier cost?
Every free tier has limits; the question is only whether they match your use case. A tier that spins down is fine for a demo and wrong for an API your users hit. A 30-day database is fine for a tutorial and wrong for a side project you want to keep. Match the limit to the need, not the marketing to the hope.
Where RunxBuild fits
RunxBuild’s own free plan runs for 15 free days each month and then falls to a low paid rate, and the managed databases are MySQL and Postgres you keep - the honest difference from a free tier that expires is that the ladder from free to paid is a price, not a cliff where your data is deleted.
Rather than quote a comparison, the straightforward move is to model it: the hosting calculator shows the service, the database, the storage, and the bandwidth as separate line items, so you can see what the first real month costs once the project is past the free-tier phase and decide with a number instead of a guess.
How this fits the rest of the stack
The cost of a project is the sum of its line items, not the headline number, and the RunxBuild hosting calculator is the right place to add them up: the service, the database, the storage, the bandwidth, each a separate figure. Model it before committing, not after the first invoice. The RunxBuild dashboard is where the running project shows its real usage in one place.
Useful related references:
- Deploy from GitHub with Render
- Free SSL certificate
- Database introduction
- Services introduction
- Services storage
FAQ
How many hours is Render’s free tier?
750 instance hours per month for free web services, reset at the start of each month with no rollover. Since a month is roughly 744 hours, that is enough to keep a single web service running continuously, but not several at once.
Do Render free services stay running?
No. A free web service spins down when it receives no traffic and wakes on the next request, producing a cold start of some seconds. Render can also restart a free service at any time, so the free tier is not suited to anything that must respond instantly on the first hit.
Does Render’s free database expire?
Yes. The free Postgres instance is capped at 1GB and expires after 30 days, after which it is removed. It is intended for prototypes, tutorials, and short demos rather than anything you plan to keep running.
Can I store files on Render’s free tier?
Not persistently. Free compute plans do not include persistent disks, so files written to local disk do not survive a restart or spin-down. A free service should be stateless and keep its data in a database or external object storage.
How should I compare free hosting tiers?
Check three things: the hard resource limits (compute, memory, bandwidth, storage), whether anything expires or spins down on idle, and what the first paid tier costs when you outgrow free. Match those against your actual use case rather than the headline that the plan is free.