Demo environments

The hosted demo exists to show the platform to people who can't or shouldn't see production — funders, partner constituencies, new members evaluating the Hub before joining. It runs the same code as production with two deliberate differences: NEXT_PUBLIC_HUB_DEMO is set, and its database holds a generated population rather than real members.

The population rule

The demo's people, organisations and records are generated into its database by provisioning scripts — never committed to the repository, never embedded in seed files. This is the same rule the rest of the project lives by, applied to the environment that most tempts people to break it. When you refresh the demo cast, you run a script against the demo database; you do not add a fixture.

The corollary: if the demo needs new scenario data, write or extend the provisioning script so it generates the scenario. "Check in a SQL dump" is not an option.

What demo mode does

• The interface marks the deployment visibly as a demo, so a screenshot of an "adopted" motion there cannot be mistaken for a real YOUNGO decision.
• Mail respects EMAIL_RECIPIENT_ALLOWLIST, so demo notifications stay inside the demo.
• Provisioning scripts may provision accounts and content freely — the guardrails are NEXT_PUBLIC_HUB_DEMO plus the allowlist, not a read-only database.

Refreshing the demo

DATABASE_URL=<demo connection string> npx tsx scripts/seed.ts
# plus whatever scenario provisioning the demo currently uses

Confirm the target before running anything — the same command pointed at production by mistake is exactly the accident the env-var discipline exists to prevent. echo $DATABASE_URL first; make it a habit.

Preview deployments as demos

The per-PR Neon-branch previews are disposable demos — they exist for review, seeded by neon-preview.yml, and are destroyed on merge. Use them for "does this change feel right" questions; use the hosted demo for "show someone the platform".