DEV Community

Cover image for .ENV Files
Jon Raxa
Jon Raxa

Posted on

.ENV Files

Source Code (skipped)

Env Configuration (.env) <-- YOU ARE HERE

Build Tool (Vite)

Bundler Output (JS/CSS/assets)

API Contracts (OAS)

CDN / Hosting

Browser Runtime

Testing (Playwright)

Observability (Datadog)


I was introduced to .env files during a personal project I was creating before getting hired. I then encountered it twice during conversations at work regarding testing feature flags. I couldn't contribute effectively because I'm fairly new to the concept of .env files. So here we are...


What are .env files?

What problem do they solve?

They separate code from configuration.

You do not want:

  • API keys
  • environment URLs
  • feature flags

hardcoded into bundles. These pose significant security risks if you were to leave them in your codebase.


How .env actually works

.env files are...

  • plain text
  • key/value pairs
  • read at build time, not runtime (in frontend). Meaning, it's built and put together before you start developing or seen in production.

Example:

VITE_API_URL=https://api.myapp.com
Enter fullscreen mode Exit fullscreen mode

In frontend builds:

  • .env values are read by the build tool (Vite)
  • injected into the bundle as string constants
  • replaced at build time
console.log(import.meta.env.VITE_API_URL)
Enter fullscreen mode Exit fullscreen mode

⬇ becomes ⬇

console.log("https://api.myapp.com")
Enter fullscreen mode Exit fullscreen mode

⚠️ Important implication

  • Once built, values are public
  • You cannot “hide” secrets in frontend envs
  • .env controls which environment you’re building for, not runtime switching

Note

.env files define build-time configuration, not secure storage.

They control what kind of app you’re shipping, not secrets.


Summary

In its simplest terms, .env files give us a way to define and shape the environment we're working in. They run and are checked during the build process, so they don't change on the fly while we're working with the code.

The variables within the .env files are specific to the environment we're building. So for things like feature flags, we can determine if someone could see certain features doing something like, VITE_FEATURE_NEW_DASHBOARD=true, in a file called, .env.localhost. This means, "turn on this flag to show the new dashboard within the localhost environment."


I've found the best way for me to learn is to teach. My dumb brain cannot retain information without solidifying concepts through teaching. And what better way to do that than to post a public blog about what I've learn so others could tear it up. This post is part of my ongoing frontend dev series.

Top comments (0)