Deploying to Render

The template ships with a render.yaml at the repo root — a Render Blueprint that describes the whole deploy. You don’t hand-configure services in the dashboard; Render reads this file.

Why there’s only one service

backend/Dockerfile builds the frontend first and copies the built files straight into the FastAPI image — the backend serves them as static files (see app/main.py). One container, one Render service, no CORS to configure between “the frontend” and “the backend” because there isn’t a separate one.

1. Connect the repo

On Render: New → Blueprint, pick your repo. Render finds render.yaml and shows you the one service it defines (fastapi-template) before creating anything.

2. Set the secrets

render.yaml declares which environment variables the service needs but deliberately leaves their values out (sync: false) — nothing secret belongs in a committed file. Set the actual values in the Render dashboard under the service’s Environment tab:

Variable	Value
POSTGRES_SERVER, POSTGRES_PORT, POSTGRES_DB, POSTGRES_USER, POSTGRES_PASSWORD	Your Aiven credentials — see Database Setup
SECRET_KEY, FIRST_SUPERUSER, FIRST_SUPERUSER_PASSWORD	See Environment Variables — don’t reuse your local dev values
FRONTEND_HOST	This service’s Render URL once it’s created (e.g. https://fastapi-template.onrender.com), or your custom domain
SMTP_*, EMAILS_FROM_EMAIL, SENTRY_DSN	Optional — leave unset until you need them

3. Deploy

Render builds backend/Dockerfile and starts the container. Every deploy runs scripts/prestart.sh first — the same migration script used locally — so alembic upgrade head and the first-superuser setup happen automatically before the app starts serving traffic.

4. After that

Render auto-deploys on every push to the branch you connected — no GitHub Actions workflow needed for this. Push to that branch when you’re ready to ship; everything else (PR checks, tests) still runs through the workflows in .github/workflows/.