Skip to content

Environment

This project uses two canonical runtime settings profiles.

Settings Profiles

  • config.settings.dev: local development and shared dev environments
  • config.settings.prod: production runtime
  • config.settings.test: test-only profile (kept for faster, deterministic tests)

Compatibility aliases currently exist:

  • config.settings.local -> config.settings.dev
  • config.settings.production -> config.settings.prod
  • Local development: config.settings.dev
  • Shared dev environments (container/preview): config.settings.dev
  • Production: config.settings.prod
  • Test execution: config.settings.test

Environment Files

Under apps/api/envs/:

  • dev.env / dev.env.example are for development settings.
  • local.env / local.env.example are local variants and also use dev settings.
  • prod.env.example is for production settings.

When DJANGO_READ_DOT_ENV_FILE is enabled, the settings loader will choose an env file based on the settings module profile.

Quick Examples

From apps/api:

export DJANGO_SETTINGS_MODULE=config.settings.dev
export DATABASE_URL=sqlite:////tmp/prismio_local.db
export USE_DOCKER=no
uv run python manage.py runserver

Production-style check (requires prod dependencies and secrets):

export DJANGO_SETTINGS_MODULE=config.settings.prod
uv run python manage.py check

Notes

  • config.settings.test remains separate by design to keep tests fast (for example faster password hashers and in-memory email backend).
  • New references should use dev and prod names directly.
  • For static marketing exports, set CLOUDFLARE_TURNSTILE_SITE_KEY in the CI environment so generated pages render live Turnstile widgets.
  • For contact form submission from generated marketing pages, set CLOUDFLARE_CONTACT_WORKER_URL in CI so forms post to the deployed Worker.
  • Do not inject the Turnstile secret key into Django templates or static site builds. Keep the secret only in your Cloudflare Worker runtime environment and verify tokens server-side there.