Deploying Render: the modern Heroku, without the ceiling.: what should I watch out for? (#1)

Starter web services sleep after 15 minutes of inactivity — fine for staging, not for prod. Use Standard or above for anything user-facing.

Deploying Render: the modern Heroku, without the ceiling.: what should I watch out for? (#2)

Cold builds are slower than Fly or Heroku because Render rebuilds the Docker layers cache-cold on first deploy of a new service. Use a persistent build cache or an external registry once you feel it.

Deploying Render: the modern Heroku, without the ceiling.: what should I watch out for? (#3)

Render's default Postgres connection limit tracks the plan — pool with PgBouncer (or the built-in pooler on Standard+) before you scale web dynos horizontally.

Deploying Render: the modern Heroku, without the ceiling.: what should I watch out for? (#4)

Blueprints are the source of truth: if you change env vars in the dashboard and forget to update render.yaml, the next PR preview environment won't have them.

// cloud · render

Render: the modern Heroku, without the ceiling.

Git-push PaaS with real containers, managed Postgres/Redis, cron, and preview environments — priced to grow with you, not to punish you.

Render gives you the zero-config git-push experience Heroku pioneered, but on modern container infrastructure with sensible pricing at scale. Point it at your GitHub repo, pick "Web Service", and Render builds your Dockerfile (or Ruby buildpack), runs it behind a managed load balancer with TLS, and wires up Postgres, Redis and cron in a few clicks.

Oregon · Ohio · Frankfurt · Singapore

regions

Starter · 512 MB

smallest sane web plan

per-PR, automatic

preview envs

01 / 04

render.yaml is the whole app

Everything — web service, worker, cron, Postgres, Redis, env groups — lives in a single `render.yaml` (Render Blueprints). Commit it and every PR gets a full preview environment with its own DB. It's the closest thing to a Heroku app.json done right.

yml
# render.yaml
databases:
  - name: rails-pg
    plan: standard
    postgresMajorVersion: "16"

services:
  - type: web
    name: rails-web
    runtime: docker
    plan: starter
    healthCheckPath: /up
    envVars:
      - key: DATABASE_URL
        fromDatabase: { name: rails-pg, property: connectionString }
      - key: RAILS_MASTER_KEY
        sync: false

  - type: worker
    name: rails-sidekiq
    runtime: docker
    dockerCommand: bundle exec sidekiq

  - type: cron
    name: nightly-report
    schedule: "0 3 * * *"
    dockerCommand: bin/rails runner Reports::Nightly.run

02 / 04

Managed Postgres that actually scales

Render's Postgres offers point-in-time recovery, read replicas, and connection pooling on the Standard tier and up. Migrations run as pre-deploy commands so the code and schema move together — no more 'migrate before deploy' rituals.

03 / 04

Preview environments per PR

Toggle preview envs in the Blueprint and every pull request gets its own stack: web + worker + a fresh Postgres seeded from a snapshot. Reviewers click a link, poke the feature, and it's torn down when the PR closes.

04 / 04

Cron and background workers

First-class `cron` and `worker` service types — no dyno-fits-all pretending. Sidekiq/Solid Queue as a worker, scheduled jobs as cron, and the same image serves both. Rolling deploys and health checks come standard.

Gotchas we learned the hard way

!Starter web services sleep after 15 minutes of inactivity — fine for staging, not for prod. Use Standard or above for anything user-facing.
!Cold builds are slower than Fly or Heroku because Render rebuilds the Docker layers cache-cold on first deploy of a new service. Use a persistent build cache or an external registry once you feel it.
!Render's default Postgres connection limit tracks the plan — pool with PgBouncer (or the built-in pooler on Standard+) before you scale web dynos horizontally.
!Blueprints are the source of truth: if you change env vars in the dashboard and forget to update render.yaml, the next PR preview environment won't have them.

Related guides

→ guide

Framework · Rails

The majestic monolith is back, and it deploys better than ever. Kamal 2, Solid stack, Propshaft — no Node, no Redis, no Nginx if you don't want them.

→ guide

Framework · Sinatra

The 40-line Dockerfile framework. Perfect for internal APIs, webhooks, and 'we just need one endpoint' services.

→ guide

Framework · Hanami

Slice-based architecture, dry-rb composition, ROM persistence — Hanami 2 is what a lot of Ruby people quietly wish Rails had become.

→ guide

Cloud · Heroku

Where Rails grew up. Still the fastest zero-to-production experience for a solo founder or small team, in 2026.

→ guide

Cloud · Fly

Firecracker microVMs in 30+ regions with a Heroku-ish CLI. Rails' unofficial second home, and the best story for global read replicas we've seen.

→ guide

Cloud · DigitalOcean

Predictable pricing, a UI you can actually navigate, and two great paths to prod: App Platform (PaaS) or Droplets + Managed Postgres (build-your-own).

Ready?

Blueprint your Rails app on Render

Best fit for teams that loved Heroku's ergonomics but want modern pricing, real containers, and preview environments without setting up a whole platform team.