Managing Environment Variables in Next.js: What I Learned the Hard Way

I remember adding an API key like this: API_KEY=123456

Then I tried using it in my frontend: console.log(process.env.API_KEY);

And guess what? Undefined. I was confused. “It’s in my .env file, why isn’t it working?”

That’s when I learned the first important rule: Not all environment variables are available on the client side.

Understanding Public vs Private Variables

Next.js separates environment variables into two categories:

Private (Server-only): API_KEY=secret_key

• Only available on the server
• Safe for secrets (DB URLs, API keys)

Public (Client-side): NEXT_PUBLIC_API_URL=https://api.example.com

• Accessible in the browser
• Must start with NEXT_PUBLIC_

Once I understood this, things started making sense.

Structuring Environment Files Properly

As my projects grew, I stopped using just one .env file. Instead, I organized them like this:

• .env.local
• .env.development
• .env.production

Why this helped:

• Different configs for dev and production
• No accidental leaks
• Cleaner deployment process

For example:

.env.development: NEXT_PUBLIC_API_URL=http://localhost:3000

.env.production: NEXT_PUBLIC_API_URL=https://myapp.com

Using Environment Variables in APIs

This is where things get interesting. Inside API routes or server components, you can safely use private variables:

export async function GET() {

const apiKey = process.env.API_KEY;

return new Response(JSON.stringify({ success: true }));

}

This is perfect for:

• External API calls
• Database connections
• Secure operations

My Simple Rules (That Save Me Every Time)