Skip to content

Test your website now

Free, no card. We read only public pages.

Run free audit →

AI APIs

What is a .env file, and how do you keep it safe?

A .env file stores configuration and secrets as environment variables for local development. How it works, how it leaks, and how production handles secrets.

A .env file is a plain text file of KEY=value lines that development tools load as environment variables, typically holding API keys, database URLs and settings. It is meant for your machine only. Add it to .gitignore, commit a .env.example with empty values instead, and set production values in your host's environment settings, not in a deployed file.

Published · Last updated

By Michal Měřínský. Audit methodology.

What a .env file is

DATABASE_URL=REPLACE_WITH_SERVER_DATABASE_URL
STRIPE_SECRET_KEY=sk_test_...
NEXT_PUBLIC_SITE_URL=http://localhost:3000

Frameworks such as Next.js and Vite, and libraries such as dotenv, read this file at startup and expose the values to your code as environment variables. It keeps configuration out of the code, so the same code can run with different settings in development and production.

The rules that keep it safe

  • Add .env to .gitignore before your first commit.
  • Commit a .env.example with the variable names and empty or fake values, so others know what to set.
  • Never deploy the .env file as a public static file.
  • Set production values in your hosting platform's environment variables.
  • Use separate keys for development and production.
# .gitignore
.env
.env.local
.env.*.local

Public versus secret variables

Frontend frameworks deliberately expose some variables to the browser:

  • Next.js exposes variables starting with NEXT_PUBLIC_.
  • Vite exposes variables starting with VITE_. Anything with those prefixes is compiled into JavaScript every visitor downloads. Use them only for values that are safe to publish, such as a site URL or a publishable key.

Renaming a secret to NEXT_PUBLIC_ or VITE_ to make an error go away publishes the secret. Move the code that needs it to the server instead.

In AI-built apps

AI app builders usually keep secrets in their own settings panel and inject them at build or run time. When you export the project or connect it to GitHub, check that no .env file with real values came along, and set the same variables in your new host. If the tool asks you to paste a key into a chat to make something work, put it in the secrets panel instead.

How .env files leak

  • Committed to Git, especially in the first commit before .gitignore existed. It stays in history even after deletion.
  • Served by a misconfigured web server at /.env, a path bots request constantly.
  • Copied into a Docker image without a .dockerignore.
  • Shared in chat or pasted into an AI assistant. If it happened, rotate every secret in the file. Removing the file is not enough.

What a scan can and cannot tell you

WebAuditOS does not currently request /.env or detect secrets in your code. It checks related exposure: directory listings that reveal files, HTML error pages with recognizable debug output, and headers that disclose server versions.

Check yourself that https://example.com/.env returns 404, and use secret scanning on your repository.

curl -sI https://example.com/.env

If that request returns 200, take the file down and rotate every value in it now.

Short answers

Should I commit my .env file? No. Commit a .env.example instead.

Where do production environment variables go? In your hosting platform's environment settings.

Is .env.local different? It is a local override that should also never be committed.

Can the browser read my .env? Only variables with public prefixes, which are bundled into your JavaScript.

In the product

The checks this maps to

Every check named here runs on every scan, on every plan - what a plan changes is how many pages are crawled, how long the history is kept and what you can do with the result. These are the ids the findings carry, so you can match a line in a report to the explanation above.