Render is the most Heroku-shaped of the post-Heroku PaaSes — same five service types, same flat monthly pricing, same "connect a repo, deploy" flow. The trade against Railway is less magic in detection; the trade against Fly is fewer regions. The win is that the bill is the bill.
If you've used Heroku at any point in the last decade, Render's UI is going to feel deeply familiar. Web services, background workers, cron jobs, static sites, managed databases — same five-service mental model, same per-service settings pages, same "this branch builds and deploys automatically" workflow. The fact that this shape feels like home to so many developers is exactly why Render's adoption has been steady: nothing new to learn if you'd shipped on Heroku, with all the things you wished Heroku would fix.
The most concrete improvement over Heroku is pricing. Render's plans are flat per service per month — a web service is $7, a worker is $7, a managed Postgres is $7+, a static site is free. The bill at the end of the month is the same as the bill at the start. This sounds boring, and it is, and that's the point. For projects where you want to know exactly what you're paying before the month begins, Render is the friendliest answer.
The trade-offs are real but bounded. Render has fewer regions than Fly (a handful, all in North America/Europe/Asia, not 30+). Auto-detection of stacks is rougher than Railway — you'll often write a tiny render.yaml or set explicit start commands. Cold starts on the free tier are 30–60 seconds, which is fine for a personal site but terrible for anything user-facing. None of these are dealbreakers; they're the cost of "boring works."
Sign up at render.com with your GitHub account. The OAuth flow asks for repo access — scope it to specific repos rather than "all" for safety. No credit card required until you create a non-free service.
Render also supports GitLab and Bitbucket if you're not on GitHub.
Render's service types:
Plus managed databases: Postgres, Redis, Key Value — separate products at their own per-month prices.
Click New + → Web Service. Pick the repo. Configure:
main.npm install && npm run build).npm start).Click Create Web Service. Render builds and deploys; the URL is live in a few minutes.
From your dashboard, New + → PostgreSQL. Pick name, region (same as your service ideally), plan ($7/mo starter is fine for most apps). Render provisions a managed Postgres in a couple of minutes.
To connect: copy the "Internal Database URL" from the Postgres dashboard, set it as the DATABASE_URL env var on your web service. Internal URLs only work within Render's network — they're private and don't go over the public internet. There's also an "External Database URL" if you need to connect from outside Render (e.g., from your local machine), but use the internal one for the service.
Each service has an Environment tab where you set env vars. Secret variables are masked; non-secret ones aren't. Add API_KEY=..., NODE_ENV=production, etc. as needed. Render auto-redeploys when you save changes — you don't need to manually trigger.
Render also has Environment Groups — sets of variables you can attach to multiple services. Useful when several services share secrets (a worker and a web service both need the database URL).
Service settings → Custom Domains → Add Custom Domain. Render gives you a CNAME target. Add it at your DNS provider:
@ if your DNS provider supports apex CNAMEs).Within minutes Render validates and issues a free TLS cert (Let's Encrypt under the hood). Auto-renews forever; you don't think about it again.
If you don't want the dashboard to be the source of truth for your config, put a render.yaml at the repo root:
services:
- type: web
name: my-api
env: node
buildCommand: npm install && npm run build
startCommand: npm start
plan: starter
databases:
- name: my-postgres
plan: starterCommit it. From now on, the config in git is the truth. Render's "Blueprints" feature reads render.yaml when you create the project; for an existing project you can switch to it via Settings.