Running & Maintaining a Site

Environment Variable

Definition

An environment variable is a key and a value handed to a process by whatever starts it — a shell, a build system, a hosting platform. The convention is upper case with underscores, such as API_BASE_URL or NODE_ENV, and the point is to keep values that change between machines out of the source code. In a server application the process reads them at runtime and the visitor never sees them. A static site has no server and no process: the build runs once, on someone else's computer, and what it produces is a set of files sent to the browser exactly as written. So a build-time variable is not a secret store. It is a find-and-replace that happens before publishing, and whatever it substitutes is in the bundle for anyone to read.

Why It Matters

Put it bluntly: anything in the page source is public. A key inlined by a build into 'app.js' is as published as the text on the homepage — view source, or open the file directly, and there it is. Minification does not hide it; nor does a variable name prefixed to look like a framework convention. People find these keys without trying, because automated scanners crawl deployed sites for patterns that look like credentials, and a leaked key for a paid API can run up a bill in hours. Treat a key that has ever been in a published bundle as compromised: rotate it, do not merely remove it, because the old file may still be in a cache, an archive or someone's browser history.

How It Works

In a typical build, tools read variables at compile time and substitute their values into the output — anything prefixed with something like VITE_ or NEXT_PUBLIC_ is explicitly intended to be public, and the prefix is a warning label rather than a protection. The safe pattern is that only values you would happily print belong in the bundle: a public API base URL, an analytics site identifier, a feature flag. Anything with power — a secret key, a database credential, a token that can write — must live behind something that is not the browser: an edge function or the vendor's own backend, with the page calling that instead. Where a vendor issues both a publishable key and a secret key, only the first belongs in the page, restricted by referring domain in the vendor's dashboard. Locally, keep values in a '.env' file excluded from version control, and remember that excluding the file does nothing once the build has baked the value in.

Real-World Example

Someone publishes an AI-generated dashboard at trellis-metrics.99helpers.site that charts figures from a third-party service. The generated code carried the API key straight into the JavaScript, and because 99helpers serves the files as given, the key is readable by anyone who opens the page source. The fix is two steps: rotate the key with the vendor immediately, then move the call behind a small function hosted elsewhere and have the page fetch from that. The dashboard is unchanged to look at; the difference is that the credential is no longer part of what is published.

Common Mistakes

  • Putting an API key in a build-time variable and treating it as hidden — the value ends up in the bundle, which is the same as publishing it
  • Assuming minified or obfuscated code conceals a secret, when the file is plain text to anyone who opens it and to any scanner
  • Deleting the key from the code and not rotating it, leaving a live credential in cached copies, archives and any fork of the source
  • Adding '.env' to the ignore list and thinking the job is done, when the build has already substituted the value into the published output

Related Terms

Put a file online in seconds

Drop in a document, an image, a page or a whole static website and share the link — free, with no build step and no server to set up.

Host a file free →