← Lessons

quiz vs the machine

Platinum1750

Frontend

Environment Variables and Config

Separate per environment settings from code, and never bake secrets into a public client bundle.

5 min read · advanced · beat Platinum to climb

Config that varies by environment

An app needs different settings in development, staging, and production: API base URLs, feature flags, analytics keys. Environment variables hold these values outside the code, so the same build logic adapts to each environment without edits to source.

  • The build tool reads variables and inlines the allowed ones.
  • A prefix often marks which variables are safe to expose to the client.
  • Defaults live in a checked in file, secrets stay out of the repo.

The exposure trap

A frontend bundle ships to every user, so any value inlined into it is public. Build tools inline only prefixed variables for this reason. Putting a real secret in a client variable leaks it to anyone who opens dev tools.

  • Client safe: public API base URLs and feature flags.
  • Never client: private API keys and database credentials.
  • True secrets belong on a server that the client calls.

Treat the prefix as a publicity warning, not just naming. Anything inlined into the client is readable by users. Keep genuine secrets server side and expose only what is safe, validated at startup so a missing value fails loud.

Key idea

Environment variables externalize per environment config, but anything inlined into the client bundle is public so keep secrets server side.

Check yourself

Answer to earn rating on the learn ladder.

1. Why is a real secret unsafe in a client environment variable?

2. Where should genuine secrets like private API keys live?