Guides / Concepts explained

What Are Environment Variables and Secrets? A Plain Guide

Environment variables are settings kept outside your code; secrets are the private ones, like API keys. How they work and how to keep them out of the browser.

Mythex Team · 2026-09-29 · 5 min read

An environment variable is a named setting — like DATABASE_URL or STRIPE_SECRET_KEY — that is handed to your app when it runs, instead of being written into the code. A secret is an environment variable whose value must stay private: an API key, a password, a signing key. Keeping these values outside the code means you can change them without editing the app, use different ones for testing and for real customers, and stop them from leaking when you share or publish your code.

Why it matters when you build with AI

The moment your app does something useful with another service — takes a payment, sends an email, calls an AI model — it needs a key. AI app builders ask for these keys regularly, and where the key ends up decides whether your app is safe.

Two things commonly go wrong in AI-built apps:

• The key is pasted into the chat or the code. It then lives in the chat history, the project files and any export or repository. Anyone who sees them can use your account.
• The key is used in the browser. If the code that calls Stripe or OpenAI runs in the page, the key is sent to every visitor. People do look — and automated scanners look for exposed keys constantly.

Understanding environment variables lets you spot both, and ask for the fix.

An everyday analogy: the hotel safe

Your app's code is like the hotel room. Guests (and cleaners, and anyone you give the key card to) walk through it. You wouldn't leave your passport on the desk.

Environment variables are the in-room safe. The room knows there is a safe and how to open it when needed, but the passport isn't lying around. And if you move to a different room — from your test setup to your live site — you put a different passport in that room's safe, without redecorating.

How it works

Your code refers to a name, not a value. In JavaScript on a server, that looks like process.env.STRIPE_SECRET_KEY. When the app starts, the platform it runs on fills in the value for that name. Change the value in the platform's settings, restart or redeploy, and the app uses the new one — no code change.

Where the values come from depends on where the app runs:

Public vs secret variables

Not every environment variable is secret. It helps to sort them into two groups:

Web frameworks make this split explicit. In Vite, only variables whose names start with VITE_ are included in browser code; in Next.js, the prefix is NEXT_PUBLIC_. That's a safety feature: anything with those prefixes ends up in the files every visitor downloads, so a secret must never be given one.

A worked example: an AI summary button

You want a "Summarise this note" button that calls an AI model.

The unsafe version: the button's code, running in the browser, calls the AI provider directly with the API key written into it. It works in the preview. It also means anyone can open the browser's developer tools, copy the key, and run up a bill on your account.

The safe version:

1. You create the key at the AI provider and store it as a secret named OPENAI_API_KEY (or similar) in your project settings.
2. The backend gets a route, POST /api/summarise, that reads process.env.OPENAI_API_KEY, checks the user is logged in, and calls the provider.
3. The button calls your route, not the provider. The browser never sees the key.
4. You add the same secret to the published app's settings and redeploy, so the live site has it too.

That pattern — browser calls your server, your server holds the key and calls the service — applies to payments, email, maps and every other paid API. The guide to using LLM APIs covers the AI case in more depth.

Key terms

• .env file: a text file of NAME=value lines used in local development. List it in .gitignore so it isn't committed.
• .env.example: a copy with the names but no real values, committed so others know which variables to set.
• Rotate: replace a secret with a new one and revoke the old one.
• Scope / permissions: many providers let you create keys that can only do certain things. A key that can only send email is less dangerous than one that can do everything.
• Test vs live keys: providers such as Stripe give you separate keys for testing and for real money. Use test keys until you launch.
• Signing secret: a secret used to check that a message, such as a webhook, really came from the sender.

Common mistakes and misconceptions

• "My repository is private, so keys in it are fine." Private repositories get shared, forked, exported and cloned to laptops. Keys still don't belong there. If you connect a project to GitHub, check that no .env file is included.
• "I deleted it, so it's gone." Git keeps history, and chat logs keep messages. If a key was ever exposed, rotate it.
• Using a public prefix on a secret. VITE_OPENAI_KEY puts your key in the browser bundle.
• Forgetting to redeploy. Changing a variable in settings usually only takes effect after the app restarts or is published again.
• One key for everything. Separate keys for test and live, and per app, make it possible to revoke one without breaking the rest.
• No spending limit. For paid APIs, set a budget or limit in the provider's dashboard in case a key leaks.

What to ask your AI builder for

• "Read the Stripe secret key from an environment variable called STRIPE_SECRET_KEY. Use it only on the server."
• "Make sure no secret is used in client-side code or given a VITE_ / NEXT_PUBLIC_ prefix."
• "Create a .env.example listing every variable the app needs, without values, and make sure .env is git-ignored."
• "Check the built frontend files for any string that looks like an API key."

Our security checklist for AI-built apps covers secrets alongside the other checks worth running before launch.

Secrets on Mythex

On Mythex, secrets are project environment variables that are injected into both the preview sandbox and your published app. You add them under project settings → Secrets or with /secrets in chat, and when the agent needs a key it shows a secrets card in chat, so the value goes into a form field rather than the message transcript. If you change a secret for a live app, publish again so the deploy picks it up. Project exports leave secrets out, and imported .env files are stripped so you re-add them in settings. See environment variables and secrets and secrets in chat in the docs.