Environment Variables

This document lists every environment variable the application uses, along with its purpose, whether it is required, and its default value.

Configuration Location

Environment variables are configured in Vercel project → Settings → Environment Variables. For local development, create a .env file in the project root (see .env.example).

Changes to environment variables take effect only after a Redeploy.

Variable Reference

Required

Recommended

LLM providers can also be added dynamically from the admin panel /admin; these variables configure the default provider.

Third-party Sign-in (OAuth)

See the OAuth callback table in the main README for the exact callback URLs.

Email Verification (Resend)

Human Verification (Turnstile / reCAPTCHA)

Configuring either provider locks that provider's settings in the admin panel; environment variables take precedence over admin-panel configuration.

File Sharing (Cloudflare R2)

Pages Deploy (Cloudflare Pages — deploy apps)

The Pages feature (/pages) deploys workspace files, Git repositories (GitHub/GitLab), or ZIP uploads to Cloudflare Pages as static sites, and auto-creates short links.

Git-source deploys (from GitHub / GitLab repositories) also need the corresponding OAuth variables from the Third-party Sign-in section (GITHUB_CLIENT_ID/GITHUB_CLIENT_SECRET and/or GITLAB_CLIENT_ID/GITLAB_CLIENT_SECRET). Those are reused for Pages Git deploys.

Cloudflare Workers (Compute → Worker) deploy (optional)

The Compute → Worker nav entry deploys JS scripts as Cloudflare Workers. It is separate from Pages and uses its own WORKER_ env vars (uppercase) so it never collides with PAGES_*. The Worker feature is available once WORKER_API_TOKEN and WORKER_ACCOUNT_ID are set.

Cloudflare KV Response Cache (optional)

Used to make slow cross-service calls (the Cloudflare Pages project list, GitHub/GitLab repo enumeration) feel instant on repeat visits. Everything degrades gracefully when not configured (falls back to a per-instance in-memory cache).

Up to 5 KV namespaces. The first store uses the base names; additional stores append a numeric suffix (_2 … _5). Reads try the stores in order (store 1 first) and fall through on a miss; writes fan out to every configured store so any reader finds the value. You only need one store to get going — the rest are optional.

Store 1 (required base):

Stores 2–5 (optional) — same three vars with a numeric suffix:

Example — two stores:

KV_ACCOUNT_ID=...
KV_API_TOKEN=...
KV_NAMESPACE_ID=...
KV_ACCOUNT_ID_2=...
KV_API_TOKEN_2=...
KV_NAMESPACE_ID_2=...

Shared tuning vars (one set, applies to all stores):

Cloudflare D1 Secondary Backup (optional, OFF by default)

A redundant store that mirrors the KV cache (and can hold copies of important data alongside Neon). When enabled, every KV cache write is also copied to D1, and a KV miss falls back to D1. Default OFF — set D1_ENABLED=true to turn it on.

The mirror table (cache_store) is created automatically on first use. All D1 operations are best-effort: a D1 failure never breaks a request — it just means the mirror/fallback is skipped.

Backups are stored IN D1 (not R2 — R2 is reserved for file sharing). The cron job copies the most important Neon data into D1 (neon_backup snapshot) and dumps the D1 database(s) into D1 (d1_dumps table), keeping only the newest D1_BACKUP_RETENTION entries.

Cloudflare Access (full-site gate)

Site Appearance & Comments

Other

Multiple Databases (optional)

See «Multiple Databases» below for the enablement steps and behavioral guarantees.

Generate AUTH_SECRET

node -e "console.log(require('crypto').randomBytes(32).toString('base64'))"

Paste the command output into AUTH_SECRET.

Multiple Databases

When a single Neon database is close to its storage limit, low-priority cold data (audit log, email verification codes) can be routed to dedicated Neon databases (up to 4 secondaries plus 1 primary, 5 in total), keeping the primary for important data.

Enablement

1. Create the secondary database(s) and set their connection strings in DATABASE_URL_2; add DATABASE_URL_3 through DATABASE_URL_5 as needed.
2. Set MULTI_DB_ENABLED=true.
3. Optionally use MULTI_DB_COLD_TABLES to specify which table goes to which secondary; by default both audit and verification route to the first secondary.

Behavior

• Once enabled, newly written audit log entries and email verification codes are written directly to the designated secondary; the primary stops growing.
• Reads merge the primary with all secondaries: the admin panel, analytics, and verification-code checks query and combine results, so old primary data and new secondary data are both visible.
• Existing primary data is not migrated or deleted automatically; this feature only stops primary growth and does not clean historical data.
• If a secondary connection or initialization fails, cold-data writes fall back to the primary automatically; registration, email-change, and audit flows are unaffected.
• Merged reads tolerate individual secondary failures: a failing secondary is skipped without blocking the overall result.
• When no secondary is configured or MULTI_DB_ENABLED is unset, all data is written to the primary, matching the single-database behavior.

Hard Limits

• The project supports at most 5 Neon databases (1 primary + 4 secondaries).
• The build validates the configuration: if a 6th or higher connection string is present (e.g. DATABASE_URL_6), the build fails to signal that the limit was exceeded.
• Only the audit (audit log) and verification (email verification code) tables, which have no foreign-key relations, can be routed to secondaries. Important foreign-keyed tables (users, workspaces, files, chats) are never migrated.
• If the secondaries live on a different Neon instance from the primary, run pnpm db:push:secondary once against each secondary connection string to create the two tables from schema-secondary.prisma.