Environment Variables and Secrets: The One Thing That Breaks Every App in Production

Your app works perfectly on your laptop. You push it to a server and it crashes immediately. The error says something about an undefined environment variable or a database connection refused. This is the single most common production failure for apps built with AI tools, and it has a straightforward fix.

Here is what is happening. On your local machine, your code reads secrets — API keys, database passwords, third-party service tokens — from a .env file. That file is (hopefully) in your .gitignore and never committed to your repository. When you deploy to a server, that .env file is not there. The server has no idea what your Stripe secret key or database URL is unless you tell it explicitly.

The first rule of secrets management: never hardcode secrets in your source code. An API key sitting in a JavaScript file will eventually be committed to a git repo and exposed, either to a team member, in a public repository, or via a git history leak. Rotate any secret immediately if you discover it was ever in a commit, even a private one.

The right mental model is a separation between code (which lives in git and is the same across environments) and configuration (which is environment-specific and never in git). Your database URL in development points to a local Postgres instance. In staging it points to an AWS RDS instance. In production it points to a different RDS instance with stricter credentials. The code itself never changes; only the injected configuration does.

In practice, you manage this through environment variables. On a Linux server or EC2 instance, you set variables in a file like /etc/yourapp.env, or you use a process manager like systemd or PM2 that reads an env file and injects the variables before starting your Node.js or Python process. The application reads process.env.DATABASE_URL (Node.js) or os.environ.get('DATABASE_URL') (Python) at runtime, not from a file baked into the container.

For Docker-based deployments, you pass secrets via the --env-file flag or use Docker secrets if you are on a Swarm or Kubernetes setup. Never bake secrets into a Dockerfile or a Docker image layer — image layers are readable by anyone who can pull the image, including from a leaked registry credential.

For AWS specifically, the two right tools are Parameter Store (AWS SSM) for configuration values and Secrets Manager for sensitive credentials like database passwords and OAuth secrets. Both let you store a value once and retrieve it programmatically at deploy time. Your deployment script fetches the secret from SSM, writes it to the runtime env, and the application never touches the secret at build time. This is the pattern used in production by most serious AWS deployments.

A practical setup for a Node.js app on EC2: store your DATABASE_URL as a SecureString in AWS SSM Parameter Store. In your deploy script (or via an IAM role on the EC2 instance), run aws ssm get-parameter --with-decryption to fetch the value and write it to /etc/yourapp.env. The systemd service that starts your app loads that file before the process starts. Rotate the password in SSM and your next deploy picks up the new value automatically.

One common mistake with AI-built apps: the generated code uses dotenv and loads a .env file at the top of the entry file. That works locally but it means the production server also needs a .env file sitting on disk, which is acceptable for simple setups but harder to manage at scale and easier to accidentally expose. Moving to runtime environment variable injection is worth doing before you have users.

The biggest win here is not technical sophistication — it is the discipline of separating secrets from code from the first day. If your current codebase has API keys in source files, spend two hours refactoring them out before you go live. It is far cheaper than a security incident.