Environment Variables: Client vs. Server

Managing environment variables is a fundamental part of building modern applications, but it’s crucial to understand the differences between how you handle them on the client-side versus the server-side.

Why Use Environment Variables?

Environment variables are external configuration values used by your application. They’re great for storing sensitive information like API keys, database credentials, or connection strings. They also help manage different configurations for various environments (development, staging, production) without hardcoding values directly into your codebase. This separation improves security and flexibility.

Server-Side Environment Variables

On the server, environment variables are your primary defense for sensitive data. They are not exposed to the client’s browser. When you run a Node.js application, for example, you can access environment variables through process.env.

Example (Node.js)

Let’s say you have a .env file (often used with libraries like dotenv) in your project:

1
DATABASE_URL=postgres://user:password@host:port/database
2
API_SECRET_KEY=yourSuperSecretKey123

In your Node.js code, you’d access them like this:

1
require('dotenv').config(); // Load variables from .env file
2

3
const dbUrl = process.env.DATABASE_URL;
4
const apiKey = process.env.API_SECRET_KEY;
5

6
console.log("Database URL:", dbUrl);
7
// This will NOT be printed to the client console
8
console.log("API Key:", apiKey);

Key Point: Anything stored in server-side environment variables stays on the server. They are part of your server’s operating environment. You can use them for critical operations, connecting to databases, or making authenticated API calls from your backend. You should never expose these directly to the client.

Client-Side Environment Variables

Handling environment variables on the client-side (e.g., in a React, Vue, or Angular application that runs in the browser) is trickier and requires a different approach. You cannot directly expose sensitive information to the client. If you did, any user could inspect your browser’s JavaScript and find your API keys, leading to potential security breaches and unauthorized access.

Instead, client-side environment variables are typically built into your application bundle during the build process. They are often prefixed with a specific identifier, like NEXT_PUBLIC_ in Next.js, to indicate that they should be exposed to the client.

Example (Next.js)

In a Next.js project, you might have a .env.local file:

1
NEXT_PUBLIC_API_URL=https://api.example.com/v1
2
NEXT_PUBLIC_GA_TRACKING_ID=UA-XXXXXXXXX-X

Notice the NEXT_PUBLIC_ prefix. In your client-side code, you can access these:

1
// In a React component or client-side script
2

3
const apiUrl = process.env.NEXT_PUBLIC_API_URL;
4
const trackingId = process.env.NEXT_PUBLIC_GA_TRACKING_ID;
5

6
console.log("API URL:", apiUrl);
7
console.log("Tracking ID:", trackingId);
8

9
// You could use apiUrl to fetch data
10
// fetch(`${apiUrl}/users`)

Crucial Distinction: These NEXT_PUBLIC_ variables are embedded directly into your JavaScript bundle when the application is built. This means they are visible in the browser’s source code. Therefore, they should never contain secrets. Use them for non-sensitive configuration like API endpoints, feature flags that don’t expose internal logic, or public keys that are meant to be known.

The Hybrid Approach

Often, you’ll have a combination. Your server might use sensitive credentials to fetch data, and then expose that data to the client through a secure API endpoint. The client then uses non-sensitive configuration (like the API endpoint URL) to communicate with your backend.

For instance, your Node.js server might use a DATABASE_URL to fetch user data. It then exposes a public API route like /api/users that the client can call. The client app would have NEXT_PUBLIC_API_URL set to your backend’s address, but it wouldn’t know the DATABASE_URL or any secret keys.

Summary

• Server-Side: Access via process.env. Can hold sensitive data. Stays on the server.
• Client-Side: Must be prefixed (e.g., NEXT_PUBLIC_). Embedded into the build. Never hold sensitive data. Used for public configuration.

Understanding this separation is key to building secure and well-configured applications. Treat client-side variables with caution, as they are inherently public.