Skip to content

Deployment

Deployment model

Backend deployment is defined in render.yaml and the root Dockerfile.

Relevant services:

  • api: Docker-based FastAPI backend
  • docs: static MkDocs site

render.yaml also includes admin-related services, but those are outside this backend documentation scope.

API service

Current Render API configuration:

  • service type: web
  • runtime: Docker
  • health check: /health
  • container start command comes from Dockerfile

The API service is the only backend runtime service currently defined. There is no worker service for ingestion.

Required configuration

At minimum, production needs:

  • OPENAI_API_KEY
  • PINECONE_API_KEY
  • PINECONE_INDEX_NAME
  • SUPABASE_URL
  • SUPABASE_SERVICE_ROLE_KEY
  • SUPABASE_JWT_SECRET
  • CORS_ALLOWED_ORIGINS

Review render.yaml and app/core/config.py together before introducing new runtime settings.

Deployment checklist

Before deploy:

  1. ensure database migrations are applied
  2. ensure Pinecone index exists and matches EMBEDDING_DIMENSIONS
  3. run pytest
  4. run python postman/check_sync.py if routes changed
  5. run mkdocs build

After deploy:

  1. verify GET /health
  2. verify authenticated access to /me or /admin/test-role
  3. verify retrieval works against real Supabase and Pinecone data
  4. verify scraping and ingestion operations with an admin token if the release changed those paths

Docs deployment

The docs site is built separately with:

mkdocs build

Render publishes the generated site/ directory for the docs service.

Rollback considerations

Rollback is mostly application-level because the repo does not define automated schema rollback tooling. For backend releases:

  • keep migrations additive when possible
  • validate backward compatibility of route and schema changes
  • coordinate schema changes before rolling app code backward