Deploy to Render
Managed Postgres with real backups, and a free tier you can demo on.
Teams that want managed Postgres with point-in-time recovery without thinking about it, and a blueprint file checked into the repo.
Anything latency-sensitive on the free tier — free services spin down after inactivity and cold starts run to tens of seconds.
Setup
- 1
Describe the stack in render.yaml
Committing the blueprint means the environment is reviewable in a pull request instead of living in a dashboard nobody can diff.
services:- type: webname: my-app-apiruntime: dockerdockerfilePath: ./apps/api/DockerfilehealthCheckPath: /api/healthenvVars:- key: APP_ENVvalue: production- key: JWT_SECRETgenerateValue: true- key: DATABASE_URLfromDatabase:name: my-app-dbproperty: connectionStringdatabases:- name: my-app-dbplan: basic-256mb - 2
Run migrations before the first boot
Grit does not auto-migrate on boot in production — a process that rewrites the schema every time it restarts is a bad idea when the platform can restart it for its own reasons. Run migrations as an explicit step. On Render that is a pre-deploy command, which runs after the build and before traffic moves over.
Pre-Deploy Command: /app/migrate
What catches people out
Free Postgres instances expire after 90 days. Fine for a demo, quietly fatal for anything you forgot about.
Health check failures roll the deploy back rather than leaving it half-live — good behaviour, but it means a wrong `healthCheckPath` looks like "my deploy never finishes".
Free web services sleep. The first request wakes them, and the wake is slow enough that a health check can time out first.
Platform dashboards and CLI flags change faster than these docs. For anything that looks different from what is written here, Render's own documentation is the authority: render.com/docs
