Render is a good hosting platform for the workload it was designed around: stateless web apps and APIs deployed straight from Git, backed by managed Postgres, with infrastructure you never log into.
It is a poor hosting platform for almost everything else people casually call hosting: WordPress sites, file-heavy apps, cheap always-on side projects that cannot tolerate a one-minute cold start.
This review goes through Render’s current plans, the free tier’s real limits, the storage traps, and the deploy machinery, then ends with a scorecard and a production-readiness checklist. Every number below comes from Render’s own pricing page and documentation, checked on October 16, 2026.
I arrive at these pages the same way most readers do: a client or a founder asks whether their Next.js storefront or NestJS API can “just go on Render.” If you are still picking the stack itself, our lists of top Next.js development companies and NestJS development companies cover the build side. This piece covers where the finished thing should live.
A note on method before the numbers: this review is built from Render’s own pricing page, the Deploy for Free documentation, the deploy and health-check references, and the platform homepage, all read on October 16, 2026.
Where Render’s docs state a limit, I quote the limit and say what it means for a real project; I do not extrapolate benchmark numbers the vendor never published. That matters for a platform like this, because the difference between a good experience and a bad one is almost never raw speed.
It is whether the limits you did not read turn out to be the limits you needed.
01What Render actually hosts, and what it does not decide for you
Render is a platform-as-a-service in the Heroku lineage: you connect a GitHub or GitLab repository, Render builds and runs the code, and you never patch an operating system.
The service catalog now spans web services, private services, background workers, cron jobs, static sites, managed Postgres, a Redis-compatible Key Value store, preview environments, and newer additions like workflows and sandboxes.
The homepage pitch is “your fastest path to production for apps and agents,” and for that specific promise it holds up: a first deploy genuinely takes minutes.

What Render does not do is equally important. It is not shared hosting: there is no cPanel, no FTP upload workflow, no one-click WordPress installer. If your mental model of hosting is a traditional web host with a control panel, read our FastComet vs SiteGround comparison instead, because that category solves a different problem.
Render also does not make your architecture decisions. It will run whatever you ship, including a badly designed app. Teams building a product from scratch often pair a platform like this with outside help, and our roundup of SaaS application development companies is a reasonable starting point for that search.
And if you are weighing a hosted platform against a fully custom build on raw cloud VMs, the trade-offs echo our Shopify vs custom websites analysis: convenience up front, constraints later.
The service model matters more than the marketing. A web service answers public HTTP traffic; a private service answers only other Render services; a background worker pulls from a queue; a cron job wakes on a schedule. Static sites get the global CDN with no compute at all.
Most real products on Render end up as three or four of these wired together over private networking, and the platform handles that composition well: internal services get stable internal hostnames, and nothing internal needs a public port.
That composition story is why teams pick Render over a single cheap VPS, and it is also where the bill starts: every one of those services is its own line item.
02The real price: workspace plans plus compute
Render’s pricing has two layers, and reading only one of them is how people end up surprised. The first layer is the workspace plan. Hobby is $0 per month and covers individuals: up to 25 services, 5 GB of bandwidth, single-service previews, global CDN, custom domains, firewall and DDoS mitigation, and chat support.
Pro is $25 per month and adds unlimited seats and services, 25 GB of bandwidth, full-stack previews, horizontal autoscaling, isolated environments, OIDC authentication, AWS Private Links, and audit logs. Scale is $499 per month and targets governance: multiple workspaces, 1 TB of bandwidth, HIPAA-compliant workspaces, SAML SSO and SCIM, and advanced RBAC. Enterprise is custom, with contractual uptime SLAs and a dedicated support channel.

The second layer is compute, billed per service on top of any workspace plan, including the free one. A web service starts at $0 for the free 512 MB instance, then $7 per month for a half-CPU starter instance with 512 MB of RAM, $25 per month for 1 CPU and 2 GB, and $85 per month for 2 CPU and 4 GB, scaling all the way to 12 CPU and 96 GB.
SSD storage attached to services costs $0.25 per GB per month.

Notice what the compute ladder implies about headroom. The $7 starter instance is genuinely small. Half a CPU and 512 MB of RAM will run a modest API or a small Next.js server, but it will not run a memory-hungry build or a traffic spike.
The jump from $7 to $25 is where most serious apps should start, and the jump from $25 to $85 is what the first real traffic surge usually costs.
The ladder tops out at 12 CPU and 96 GB of RAM per service, which covers the large majority of web workloads; beyond that you are in territory where Render’s Enterprise tier or a raw cloud provider starts making sense.
The honest way to read this: the cheapest credible production setup on Render is a Hobby workspace running a $7 web service next to a $6 paid Postgres instance, roughly $13 per month before bandwidth overages.
The moment you want autoscaling or full-stack preview environments, you are in Pro territory at $25 per month plus compute. That is fair value for managed infrastructure, but it is not $0, and any article that calls Render “free hosting” without the next four sections is doing you a disservice.
Founders scoping an early product should budget from the paid numbers, not the free ones; our top MVP development companies guide makes the same argument about build budgets.
Two example bills make the layers concrete. A solo founder running one API and one database on Hobby pays $0 for the workspace, $7 for the starter web service, and $6 for the entry Postgres instance: $13 per month, with 5 GB of bandwidth included.
A five-person team on Pro that wants autoscaling pays $25 for the workspace, plus two 1 CPU web services at $25 each, a worker at $7, and a $19 Postgres instance: about $101 per month.
Neither figure is alarming, but both are real invoices, and both are invisible if you only read the word “free” on the homepage. One more line worth knowing before you commit: Render bills compute per second with monthly caps, so a service you delete mid-month costs only the hours it ran.
03The free tier, line by line
Render’s free compute tier is real and useful, but every limit below is a design constraint, not a footnote. Here is what the documentation actually says, and what each line means in practice.

A free web service that gets no inbound traffic for 15 minutes spins down. The next request triggers a spin-up that takes about a minute, with a loading page shown to visitors. Fine for a demo, fatal for a checkout flow.
Any local file changes (uploaded images, a SQLite database, generated PDFs) are lost on every redeploy, restart, or spin-down. Persistent disks exist but are paid-only.
Shared across the whole workspace, consumed only while services run. Exhaust them and Render suspends your free services until the month resets. One always-on service fits; two do not.
Free usage counts against monthly bandwidth and build minutes. Cross the line with a payment method on file and you are billed; without one, services suspend for the rest of the month.
A free service that initiates unusually high traffic (polling external APIs, hammering object storage) can be suspended until you move it to any paid plan.
While a free service is spun down, Render answers /robots.txt with a standard disallow-all response. For anything you want indexed, that alone ends the free-tier-for-production debate.
None of this makes the free tier bad. It makes it a staging environment you do not have to pay for. Treat it as the place where prototypes, class projects, and client demos live, and it is genuinely generous: TLS certificates, custom domains, rollbacks to the two most recent deploys, and log streams are all included at $0.
The pattern to notice across all six cards: none of these limits bite during a demo, and all of them bite during a launch. The 15-minute sleep is invisible while you are actively showing the app to people and brutal the morning a stranger finds your link.
The 750-hour pool is fine for one service and quietly insufficient the week you split your API and frontend into two. The robots.txt behavior matters only if you care about search traffic, which is to say it matters exactly when the project starts working. Plan the upgrade before the limit chooses the timing for you.
04Databases: the 30-day clock nobody reads

The single most dangerous line in Render’s docs is this one: free Render Postgres databases expire 30 days after creation. Not “may be reclaimed,” not “paused”: they expire. An expired database is inaccessible unless you upgrade it to a paid plan.
After expiry you get a 14-day grace period to upgrade, and after that Render deletes the database along with all of its data. Free Postgres is also limited to one database per workspace, 1 GB of storage, no backups of any kind, no managed connection pooling, and maintenance or restarts at any time.
Put plainly: a free Render Postgres is a demo database with a countdown timer. The upgrade path is painless (paid Postgres starts at $6 per month for a 256 MB instance with 100 connections, includes point-in-time recovery and logical backups, and expandable storage at $0.30 per GB), but you have to know the clock is running.
Whatever you choose, design your backup habit around it; our explainer on incremental vs differential backup covers the recovery models worth understanding before you trust any managed database with real data.
Free Key Value (the Redis-compatible store) carries its own free-tier limits: one instance per workspace, in-memory only with no persistence. Plan cache data as disposable from day one.
05Deploys: the good machinery
Render’s deploy pipeline is the strongest part of the platform. Push to your connected branch and Render builds and deploys automatically. Zero-downtime deploys apply to web services, private services, background workers, and cron jobs: the old version keeps serving until the new one is live, and if the build fails, your current version never stops running.
Static sites update through the CDN, so they are effectively zero-downtime too. One gotcha worth memorizing: attaching a persistent disk to a service disables zero-downtime deploys for it, because the disk can only mount on one instance at a time.

One honest caveat about Git-based deployment: a green build is not acceptance. The build pipeline proves your code compiles and starts; it says nothing about whether the app behaves.
That verification layer (smoke tests against the deployed URL, contract tests, a staging pass) is still yours to build, and it is the kind of work the firms in our best DevOps consulting companies list are paid to set up properly.
Preview environments deserve a mention here too. On Pro and above, every pull request can spin up a full-stack copy of your application (web service, database, workers) so reviewers click a URL instead of pulling a branch. On Hobby you get single-service previews only.
For a team shipping daily, that difference alone often justifies the workspace upgrade, because it moves verification from “works on my machine” to a running environment anyone can open.

06Health checks that actually check something
Health checks are the second half of the story. By default Render probes your service’s open TCP port (10000 for most web services) every few seconds, on new instances before they receive traffic and on running instances to restart them if they stop responding.
Web services can upgrade to HTTP health checks: a GET to a path you choose, where any 2xx or 3xx response means healthy and any 4xx or 5xx means unhealthy. Render’s own recommendation is the right one: make the endpoint run a real check, like a trivial database query, rather than returning a hardcoded 200.
A health endpoint that lies to the load balancer defeats the point, a principle that applies to any platform with a traffic router in front; our what is a load balancer primer and the load balancer software comparison go deeper on how those routers use health signals.

07The scorecard
| Criterion | Verdict | Notes |
|---|---|---|
| Git-based deployment | Strong | Push-to-deploy with automatic builds, zero-downtime releases, and rollbacks to the last two deploys even on free. |
| Free tier for prototypes | Strong | TLS, custom domains, 750 monthly hours. Genuinely useful for demos and class projects. |
| Free tier for production | Weak | 15-minute sleep, one-minute cold starts, expiring databases, no backups, disallow-all robots.txt while asleep. |
| File storage story | Weak | Ephemeral filesystem everywhere; persistent disks are paid-only and disable zero-downtime deploys. Plan on external object storage. |
| Pricing clarity | Strong | Public per-instance compute and database tables, no sales call required until Enterprise. |
| Scaling path | Good, gated | Autoscaling and full-stack previews require the $25 Pro workspace; HIPAA requires Scale at $499. |
| WordPress and traditional CMS | Wrong tool | No managed WordPress, and the ephemeral filesystem fights every CMS that writes uploads locally. |
08A production-readiness checklist before you call it done
- Add an HTTP health check endpoint that runs a real database query, and point Render at it.
- Move user uploads to external object storage before launch, not after the first loss.
- Upgrade any Postgres holding real data to a paid plan before day 30 of its life.
- Budget from paid numbers: $13 a month for a Hobby floor, $25 plus compute once you need autoscaling.
- Set up Billing page usage alerts so the 750-hour or bandwidth limits never suspend a service silently.
- Smoke-test the live URL after every deploy; green only proves the code started.
- Write a short decision record covering what runs on Render, what runs elsewhere, and why.
Teams that outgrow one platform usually split deliberately: app services on Render, heavy data or compliance work elsewhere. When that split feels permanent, our guides to cloud-native SaaS builders and top IT outsourcing companies in the USA can help staff it; our Azure Front Door vs AWS CloudFront comparison covers the routing layer between them.
09Verdict
So, is Render a good hosting platform?
For developers shipping stateless apps and APIs from Git: yes, one of the cleanest paths from repository to production in 2026, with honest pricing and strong deploy machinery. For prototypes: the free tier is generous. For production on the free tier, for WordPress, for anything that writes files to disk: no.
Pay the $13 for a starter service and a real database, design around the ephemeral filesystem, and Render will treat you well. Browse our app development resources for adjacent comparisons like FastComet vs SiteGround.
Frequently asked questions
Is Render free forever?
The Hobby workspace plan is a standing free tier, not a trial, and free compute instances cost $0 with no published end date. But “free forever” comes with the limits above: services sleep after 15 idle minutes, you get 750 instance hours per workspace each month, and free Postgres databases expire 30 days after creation.
Can I use Render free hosting for production?
You can, and for low-stakes internal tools it sometimes makes sense. For anything customer-facing, the combination of one-minute cold starts, a disallow-all robots.txt while the service sleeps, an expiring free database, and zero backups makes the free tier a poor production home. A $7 web service plus a $6 database removes most of those problems.
Will my files survive a Render redeploy?
No. Every Render service has an ephemeral filesystem, so uploaded files, local SQLite databases, and anything written to disk disappear on redeploy, restart, or spin-down. Paid services can attach a persistent disk (which disables zero-downtime deploys for that service); the standard pattern is external object storage for user files.
What happens when my free Render Postgres expires?
Thirty days after creation the database becomes inaccessible. You then have a 14-day grace period to upgrade it to a paid plan; after that, Render deletes the database and all of its data. Render emails you as both deadlines approach, but if that mailbox is not watched, the data is gone.
Does paying for a Render instance make my app highly available?
Not by itself. A single paid instance is still one instance: health checks will restart it when it hangs, but a single point of failure remains. Real availability comes from running multiple instances (autoscaling requires the Pro workspace), health checks that verify real readiness, and a database plan with point-in-time recovery.
Why is the first request to my free Render app so slow?
Because the service was asleep. Free web services spin down after 15 minutes without inbound traffic and take about a minute to spin back up when the next request arrives. Visitors see a loading page during the wait. Paid instances never sleep.
Is Render a good host for WordPress?
It is possible through a custom Docker setup, but it is not Render’s strength: there is no managed WordPress offering, and the ephemeral filesystem breaks the way WordPress stores uploads unless you wire up external storage.
A WordPress-specific host or a VPS you manage is usually less work, and our KeystoneJS vs WordPress comparison covers the headless-CMS angle if that is what drew you to Render in the first place.










Leave a Reply