Render: Deploy Web Apps, Workers & Postgres

Render

Render is a managed cloud platform for running web applications, APIs, background workers, scheduled jobs, static sites, and databases without operating servers or Kubernetes. You connect a Git repository, choose a runtime or a Dockerfile, and Render builds and deploys on every push — with TLS, custom domains, health checks, zero-downtime deploys, logs, and metrics included. Managed Postgres and a Redis-compatible Key Value store cover the most common stateful needs.

Render occupies the space Heroku popularized: platform as a service for full-stack apps, with more modern defaults — infrastructure as code through Blueprints, private networking between services, preview environments per pull request, and Docker support. It suits startups, small teams, and internal tools that want production-grade hosting with minimal operations.

TL;DR

Service types: web services, static sites, private services, background workers, cron jobs, plus Postgres and Key Value.
Deploys come from Git pushes (or images); builds use native runtimes or Docker.
Blueprints (render.yaml) define services, databases, and environment variables as code.
Health checks enable zero-downtime deploys; failing deploys never receive traffic.
Private networking connects services in the same region without exposing them publicly.
Preview environments spin up full copies of a Blueprint for pull requests.

Quick Example

A Blueprint defining an API, a worker, a nightly job, Postgres, and Key Value — committed as render.yaml:

Creating a Blueprint from the repository provisions everything; later pushes to the linked branch redeploy the services.

Core Concepts

Service Types

Builds and Runtimes

Render detects native runtimes — Node.js, Python, Ruby, Go, Rust, Elixir — or builds a Dockerfile, or deploys a prebuilt image from a registry. Build and start commands are configurable, and environment variables and secret files are injected at build and run time. Environment groups share variables across services.

Deploys and Health Checks

Each deploy builds a new version, starts it, and checks the health check path. Only healthy instances receive traffic; the previous version keeps serving until then, giving zero-downtime deploys. Failed deploys leave the old version running. Rollbacks redeploy a previous build. A pre-deploy command runs tasks such as database migrations before the new version takes traffic.

Networking and Scaling

Services in the same region communicate over a private network using internal hostnames, so databases, caches, and private services stay off the public internet. Services scale vertically by instance type and horizontally by instance count, manually or with autoscaling on CPU and memory targets. Persistent disks can be attached to a single-instance service for data that must survive deploys.

Preview Environments

With preview environments enabled, every pull request gets its own copy of the Blueprint's services — and optionally databases — at a unique URL, torn down when the pull request closes. Reviewers test real behavior instead of reading diffs, and product and design teams can click through changes. Seed data and secrets for previews need deliberate setup.

Render Compared With Similar Platforms

See Vercel and Cloud Computing.

Costs and Limits

Pricing is per service instance type, plus database plans, bandwidth, and build minutes; teams pay per workspace plan.
Free instances spin down after a period without traffic and take time to wake, making them suitable for demos, not production.
Watch costs from many small services, preview environments with databases, and oversized instances.
Platform limits — regions, instance sizes, network features — define when moving parts of a system to a hyperscaler makes sense.

Best Practices

Define Everything in a Blueprint

Keep services, databases, and environment variable wiring in render.yaml so environments are reproducible and changes are reviewed. See Infrastructure as Code.

Use Real Health Checks and Pre-Deploy Migrations

Point health checks at an endpoint that verifies the app can serve requests, and run backward-compatible migrations in the pre-deploy step. See Deployment Strategies.

Keep Internal Services Private

Use private services and the private network for databases, caches, and internal APIs; expose only what must be public.

Plan Backups and Recovery

Know your Postgres plan's backup and point-in-time recovery options, and practice restoring. See PostgreSQL.

Common Mistakes

Production on Free Instances

Binding to a Hard-Coded Port

Storing Uploads on the Local Filesystem

FAQ

What is Render used for?

Hosting web applications, APIs, static sites, background workers, cron jobs, and managed Postgres and Key Value databases, with Git-based deploys and minimal infrastructure management.

Is Render a good Heroku alternative?

Yes. It offers a similar developer experience — push to deploy, managed databases, workers — with infrastructure as code, private networking, preview environments, and Docker support built in.

Does Render support Docker?

Yes. Services can be built from a Dockerfile in the repository or deployed from a prebuilt image in a container registry.

How do zero-downtime deploys work on Render?

Render starts the new version alongside the old one and switches traffic only after the new instances pass health checks. If the deploy fails, the previous version keeps running.

When should I move off Render?

When requirements exceed platform capabilities — specific regions or compliance controls, specialized networking, very large scale, or services Render does not offer — or when cost at scale favors managing infrastructure on a cloud provider directly.