Environment Configuration Guide
This guide explains how to think about environment variables and configuration across:
- Local development
- Preview/staging
- Production
For the authoritative list of variables, see:
Overview of configuration areas
The main application and supporting services use environment variables for:
- Sanity (project, dataset, tokens).
- Site URL and domains.
- Email delivery (Resend).
- Careers/Breezy HR.
- Analytics and tracking (GTM).
- Caching and webhooks (Redis, cache auth, webhook secrets).
Refer to:
Local development
Use a .env.local (or equivalent) file in the main application repository:
NEXT_PUBLIC_SANITY_PROJECT_ID=your_project_id
NEXT_PUBLIC_SANITY_DATASET=production
SANITY_API_TOKEN=your_api_token
NEXT_PUBLIC_SITE_URL=http://localhost:3000
ENABLE_REDIS=false
CACHE_PREFIX=infowebplus
CACHE_AUTH_TOKEN=your-local-cache-token
SANITY_WEBHOOK_SECRET=your-local-webhook-secret
For docs-specific development (this repo), environment needs are minimal. You may add:
GTAG_ID=G-XXXXXXX
if you enable Google Analytics on the docs site.
Preview and production
For the main application on Vercel:
- Set variables in Project Settings → Environment Variables.
- Keep Preview and Production values aligned, except for URLs and secret scopes where needed.
For documentation on Cloudflare Pages:
- Use Pages → Project Settings → Environment Variables.
- Typically only
GTAG_IDor similar analytics IDs are required.
Avoid committing secrets to source control. Use environment variable management in your hosting platforms instead.
Keeping environments in sync
To keep behavior predictable:
- Maintain a shared internal list of all required variables and their intent.
- Automate validation where possible (for example, startup checks that log missing variables).
- Update the Configuration page when new variables are introduced.
Review the real environment configuration in Vercel, Cloudflare, and any other deployment targets to ensure the Configuration guide and this page accurately reflect the current setup.