Environment Variables & Configuration Management

Q: How do you add environment variables to a Next.js project?

You create a file named .env.local in the root of your project and define key value pairs there, which Next.js automatically loads and makes available to your server side code through process.env, keeping sensitive values like API keys out of your actual source code.

Q: What is the difference between a regular environment variable and one prefixed with NEXT_PUBLIC in Next.js?

A regular environment variable is only available on the server and stays hidden from the browser, while one prefixed with NEXT_PUBLIC gets included in the JavaScript bundle sent to the browser, making it accessible from client components, so you should never put secrets behind that prefix.

Q: How do you manage different environment variable values for development, staging, and production environments?

You create separate files such as .env.development, .env.production, and rely on your hosting platform's environment variable settings for staging or production secrets, since Next.js automatically loads the appropriate file based on the current environment, letting each environment use its own database URLs and API keys.

Q: How would you validate that all required environment variables are present and correctly formatted before your app starts?

You can write a small validation script or use a library like zod to define a schema for your expected environment variables, checking them once at startup and throwing a clear error immediately if anything is missing or malformed, rather than discovering the problem later through confusing runtime errors.

Q: What security risks are associated with environment variables, and how do you avoid them?

The biggest risk is accidentally exposing a secret to the browser by using the NEXT_PUBLIC prefix on something sensitive, or committing an env file containing real secrets to version control. You avoid this by carefully reviewing which variables are public, adding your env files to .gitignore, and using your hosting platform's secret management for production values.

5 questions found

How do you add environment variables to a Next.js project?

Beginner

You create a file named .env.local in the root of your project and define key value pairs there, which Next.js automatically loads and makes available to your server side code through process.env, keeping sensitive values like API keys out of your actual source code.

# .env.local
DATABASE_URL=postgresql://user:password@localhost:5432/mydb
API_SECRET_KEY=your-secret-key

Real-world example A team stores their database connection string in a .env.local file, keeping it out of version control while still making it available to their application code at runtime.

Common follow-ups: Should the .env.local file be committed to version control?;What is the difference between .env, .env.local, and .env.production?

Security Best Practices in Next.js;Database Integration with Next.js

What is the difference between a regular environment variable and one prefixed with NEXT_PUBLIC in Next.js?

Beginner

A regular environment variable is only available on the server and stays hidden from the browser, while one prefixed with NEXT_PUBLIC gets included in the JavaScript bundle sent to the browser, making it accessible from client components, so you should never put secrets behind that prefix.

# .env.local
DATABASE_URL=secret-connection-string
NEXT_PUBLIC_API_URL=https://api.example.com

Real-world example A weather app exposes its public API base URL using the NEXT_PUBLIC prefix so client components can build request URLs, while keeping its actual API secret key as a regular, server only environment variable.

Common follow-ups: What happens if you accidentally put a secret behind the NEXT_PUBLIC prefix?;Can you change a NEXT_PUBLIC variable after the app has already been built?

Security Best Practices in Next.js;Client Components & Hydration

How do you manage different environment variable values for development, staging, and production environments?

Intermediate

You create separate files such as .env.development, .env.production, and rely on your hosting platform's environment variable settings for staging or production secrets, since Next.js automatically loads the appropriate file based on the current environment, letting each environment use its own database URLs and API keys.

# .env.development
DATABASE_URL=postgresql://localhost:5432/dev_db

# .env.production
DATABASE_URL=postgresql://prod-server:5432/prod_db

Real-world example A team uses a local development database while developing, but automatically switches to their production database credentials when the app is deployed live, without ever changing a single line of code.

Common follow-ups: How does Vercel handle environment variables for different deployment environments?;What happens if a required environment variable is missing in production?

Deployment;Next.js Project Setup & Configuration

How would you validate that all required environment variables are present and correctly formatted before your app starts?

Intermediate

You can write a small validation script or use a library like zod to define a schema for your expected environment variables, checking them once at startup and throwing a clear error immediately if anything is missing or malformed, rather than discovering the problem later through confusing runtime errors.

import { z } from 'zod';

const envSchema = z.object({
  DATABASE_URL: z.string().url(),
  API_SECRET_KEY: z.string().min(10)
});

envSchema.parse(process.env);

Real-world example A team adds environment variable validation to their build process, catching a typo in their database URL immediately during deployment instead of after the app was already live and failing for users.

Common follow-ups: What happens if validation fails during the build step?;Should this validation run in development, production, or both?

Security Best Practices in Next.js;Testing Next.js Applications

What security risks are associated with environment variables, and how do you avoid them?

Advanced

The biggest risk is accidentally exposing a secret to the browser by using the NEXT_PUBLIC prefix on something sensitive, or committing an env file containing real secrets to version control. You avoid this by carefully reviewing which variables are public, adding your env files to .gitignore, and using your hosting platform's secret management for production values.

# .gitignore
.env.local
.env.production.local

Real-world example A company accidentally committed a database password to their git repository history, so they rotated the credential immediately and added stricter rules to prevent env files from being tracked in the future.

Common follow-ups: What should you do if a secret is accidentally committed to version control?;How do secret management tools differ from plain environment variable files?

Security Best Practices in Next.js;Deployment