Render is a fantastic Heroku replacement but per-service pricing will cost you more. This is what the break-even calculation looks like when switching to a self-hosted solution.
What Render does right
Render lives up to its hype as a sensible Heroku alternative. There is a clean dashboard, reliable deploys, preview environments, and plenty of free static site hosting. If somebody came asking for a managed platform recommendation without any other context, then Render would be a valid choice.
This is not an evaluation of how good Render is. This is an evaluation of whether you should pay for the managed premium for your specific use case, and that premium is more substantial than one might realize beyond the first service.
Render pricing
Per-service render bills, and services grow exponentially faster than teams anticipate:
Web service (basic, 512 MB): $7/month; each additional web service costs another $7
Background workers: another separate service, costing $7+/month
Cron jobs: inexpensive per execution, but still another service to set up
Postgres: free for 90 days, but the paid version starts at $7 (256 MB RAM) and rapidly increases from there
Redis: starting at $10/month if you want persistence
Team seats: free with the individual plan, but organizational features will force you towards a paid team plan
Break even earlier than youβd expect
With just one VPS that offers 4 GB, everything works β web, worker, Postgres, and Redis, with room leftover to have a copy of that stack for staging. It takes two Render services for break even against Render. As soon as you have a staging instance (meaning two Render services) or another application, running your own stack costs 1/4 what it does with Render.
Thereβs also a resource envelope consideration. With Render, the $7 plan includes 512 MB per service with shared CPU. This is a hard boundary. Running your own VPS, all services are on the full machine and can share resources depending on demand β for example, your web app could be using 2 GB while your worker sits idle.
Where Render still excels at
Autoscaling: Render can spin up new instances under load; one instance of a VPS scales by resizing, which requires rebooting. If you have frequent 10x spikes in your traffic per minute, managed autoscaling becomes valuable.
Managed database failover: Higher tiers of databases provided by Render come with replication and failover. A self-hosted Postgres depends on backups and restoration procedures only, which provide great recovery but not instant failover.
Zero infrastructure knowledge: on Render, no one in the team ever needs to know what a Docker network is. Peon is a great example of a small operational surface, but not invisible.
What self-hosting can do better
Fixed pricing, which is not dependent on how many services are being hosted: staging environments and side projects become free instead of doubling the bill
All machine resources, no tiered RAM machines
Any Docker image, any database version, background jobs without any platform timeouts
Data locality: the application and database running on the same machine resulting in sub-millisecond queries
One-click templates for the sidekick services (monitoring, analytics, queues) that would otherwise have been another paid service on Render
Unlimited members with per-project roles on Peon
A Pragmatic recommendation
When you have one production server but not any staging server, stick with Render; the extra cost is minimal and the ease of use is genuine. Once your monthly bill with Render passes the $25 mark, figure out how much the equivalent setup will cost in a VPS. You'll likely find that the self-hosted one costs a fourth of the price and is just as good as the other one.
Top comments (0)