Environment Variables and Configuration
Managing environment variables in our project is an essential task, but it can also be challenging. This project uses environment variables for configuration management, leveraging t3-env for type-safe environment variables with runtime validation. When you add new environment variables, you need to update the .env.example
file and the src/env.js
file to ensure everything is working correctly.
Configuration Files
1. Environment Schema (src/env.js
)
The env.js
file defines the schema and validation rules for all environment variables using Zod. It’s divided into three main sections:
2. Environment File (.env
)
Create a .env
file in the project root with your environment-specific values:
Key Features
- Type Safety: All environment variables are validated at build and runtime
- Runtime Validation: Ensures your app isn’t built with invalid env vars
- Client-Side Safety: Clear separation between server and client variables
- Default Values: Fallbacks for certain variables when not specified
- Empty String Handling: Empty strings are treated as undefined by default
Usage Guidelines
-
Server-Side Variables:
- Access using
env.VARIABLE_NAME
- Never exposed to the client
- Example:
env.DATABASE_URL
- Access using
-
Client-Side Variables:
- Must be prefixed with
NEXT_PUBLIC_
- Can be accessed in both server and client code
- Example:
env.NEXT_PUBLIC_POSTHOG_KEY
- Must be prefixed with
-
Development:
- Create a local
.env
file based on.env.example
- Never commit
.env
to version control - Update
env.js
schema when adding new variables
- Create a local
Example Usage
You can access the environment variables in your code like this: