Env Validation
Environment variables are validated in src/env.js using @t3-oss/env-nextjs and Zod.
This validation layer reduces the chance of launching the app with incomplete or malformed infrastructure settings that could break authentication, billing, email delivery, or public routing.
Related docs
For the user-facing setup workflow, see Environment. This page focuses on why environment validation is a security and reliability concern, not only a setup concern.
Why this matters
This prevents the app from booting with missing or malformed configuration for critical services such as:
- database access
- authentication
- Stripe
- Resend
- public app URL generation
Fail fast
The app rejects invalid configuration early instead of allowing hidden runtime failures later.
Service safety
Critical systems like auth, Stripe, database access, and email delivery depend on validated configuration.
Operational clarity
Keeping validation and documentation aligned helps teams avoid silent misconfiguration in staging and production.
Current behavior
- server variables are validated at startup
- client variables must be prefixed with
NEXT_PUBLIC_ - empty strings are treated as undefined
- validation can be skipped with
SKIP_ENV_VALIDATION
These rules create a predictable contract between the environment file, the runtime, and the rest of the application code.
Operational advice
If you add a new integration:
- add it to the schema in
src/env.js - add it to
runtimeEnv - document it in
docs/reference/env-vars.mdx
Keeping validation and docs in sync is one of the easiest ways to avoid production misconfiguration.
Do not treat environment setup as optional
A missing variable is not only a developer inconvenience. In many cases it changes security, delivery, or billing behavior in ways that are hard to spot until production.