Environment Variables
Secret configuration values (like API keys and database URLs) stored outside your code so they stay secure and can change between environments.
What It Is
Environment variables are configuration values that live outside your source code. They typically store sensitive information like API keys, database connection strings, and secret tokens that your application needs to function but should never be committed to your code repository. They are called “environment” variables because they can change depending on where your code is running: your local machine might use a test database key, while your production deployment on Vercel uses the real one. They are usually stored in a .env file locally and configured through your hosting platform’s dashboard for production.
Why It Matters
If you hardcode an API key directly in your code and push it to GitHub, anyone who sees your repository can steal and misuse that key. Environment variables solve this by keeping secrets separate from code. Every deployment platform, every API service, and every tutorial will reference environment variables. Understanding how to set them, where they live, and how your code reads them is a non-negotiable skill for building anything that connects to external services. Getting this wrong is one of the most common and costly mistakes new builders make.
In Practice
When setting up a project, you create a .env file in your project root and add values like SUPABASE_URL and RESEND_API_KEY. Your code reads these values at runtime. The .env file is listed in your .gitignore so it never gets pushed to GitHub. On Vercel, you add the same variables in the project settings dashboard, and Vercel injects them during deployment. The “vercel env pull” command can sync your production variables to your local .env file.