Djass
Documentation navigation

Generator Options

When creating a project in Djass, each option toggles concrete code/config in the generated repository. These are build-time generator choices, not runtime release controls. The Django feature-flags production guide explains when a generated application needs a separate flag system for rollout and rollback.

Djass keeps the supported starter template fields in the typed catalog at apps/core/generator_options.py. That catalog feeds the UI, API, and MCP payload shape so all entrypoints expose the same options and category metadata.

The django-saas-starter template itself is bundled in the Djass repository under starter/, so the catalog and starter/cookiecutter.json change in the same pull request.

Run:

python manage.py sync_cookiecutter_options --check

to confirm the catalog matches starter/cookiecutter.json. If the command fails, update the catalog defaults, labels, and categories intentionally instead of copying raw cookiecutter.json values into the UI.

CI runs this check on every pull request. Because the source is on disk, there is no network fallback and drift always fails the build.

Core fields

  • Project Name / Slug: naming used in generated files and package metadata.
  • Repo URL / Description / Author fields: metadata used in templates and defaults.
  • CapRover App Name: deployment app name derived from the project slug.
  • Project Main Color: controls primary Tailwind color references used in templates.

Integration toggles

Monitoring

  • Use the production Django logging guide to define stable event fields, carry correlation into workers, protect sensitive data, and test the records that monitoring integrations consume.
  • Use PostHog: product analytics. Backend logs use standard Python logging, so PostHog Logs can read the same structured fields when its handler is attached. Use the Django analytics with PostHog guide to define stable identity, event ownership, verified conversion events, and tests.
  • Use Sentry: error monitoring plus breadcrumbs, events, and optional logs from standard Python logging records. Use the Django Sentry production guide to set release identity, privacy filters, web/worker sampling, ownership, canaries, and incident closure.
  • Use Healthchecks: outbound scheduled-job heartbeat setup when enabled. The generated project always includes its database-and-Redis readiness route; use the Django health check design guide to wire readiness, liveness, and worker freshness to the right consumers.
  • Use Apprise: Apprise-backed admin notification helper, config, deployment docs, and tests.

CX

  • Use Chatwoot: customer support/chat integration scaffolding.
  • Use MJML: email templating/rendering support. The production Django email guide covers the delivery contract around those templates: durable intent, workers, retries, provider outcomes, suppressions, and tests.

UX

  • Use Keyboard Shortcuts: keyboard shortcut helpers, data attributes, and visible shortcut hints for command-oriented UI controls.

Commerce

  • Use Stripe: Stripe integration scaffold pieces. Before taking recurring billing live, use the Django Stripe subscriptions production guide to define entitlement policy, webhook idempotency, invoice events, and lifecycle tests.

Storage

  • Use S3: storage configuration paths for media assets. Before production, use the Django S3 storage guide to choose public or private access, verify provider settings, and migrate existing media safely. This option does not generate upload forms, validation, malware scanning, or direct-upload endpoints; add those with the Django file upload production pipeline.
  • Use Qdrant: authenticated Qdrant client configuration with lazy connection setup. This option does not provision a Qdrant service, create collections, or define vector indexing and query workflows. It is off by default.

AI

  • Use AI: AI-related service/config scaffolding.
  • Use MCP: Model Context Protocol server/tooling support for agent workflows.

Content toggles

  • Generate Blog: includes apps/blog and related routes/templates.
  • Generate Docs: includes apps/docs and markdown-driven docs pages.

Delivery toggles

  • Use CI: includes GitHub Actions CI workflow.

Recommendation

Keep your first generation conservative. Enable only what you plan to use in the next 2–4 weeks.

It is usually easier to add one integration intentionally later than to maintain several unused integrations from day one.