Environment Variables for Sensitive Data

What Are Environment Variables and Why Do We Need Them?

At their core, environment variables are key-value pairs that exist outside your application's source code. They are provided by the operating system or environment where your application is running.

Think of them as external settings that your application can read at runtime. This separation of configuration from code is crucial for several reasons.

As you just read, the main benefits are:

• Security: You can keep secrets like API keys and database passwords out of your Git repository, preventing them from being exposed.
• Flexibility: You can use different configurations for development and production (e.g., a local database vs. a cloud database) without changing a single line of code.
• Portability: Other developers can run your project by simply creating their own local configuration file, without needing your personal secrets.

Managing Environment Variables in Node.js (Your Backend)

In Node.js, environment variables are accessible through the global process.env object. For example, you could access a variable named PORT with process.env.PORT.

While you can set these variables in your terminal before running your app, this is cumbersome for development. A much more common practice is to use a .env file to store your variables and a package called dotenv to load them into process.env automatically.

Let's watch a video that walks through this entire process.

To summarize the process for your backend:

1. In your backend directory, run npm install dotenv.
2. Create a file named .env in the backend directory.
3. Add your secrets and configurations to this file. Remember, no spaces around the = and no quotes.

   # backend/.env
   DATABASE_URL=postgresql://user:password@localhost:5432/mydatabase
   JWT_SECRET=thisisareallylongandsecuresecret
   PORT=3001
   

4. At the very top of your backend/index.js (or server entry file), add this line:

   require('dotenv').config();
   

5. Replace the hardcoded values in your code with references to process.env:

   // Before
   // const PORT = 3001;
   
   // After
   const PORT = process.env.PORT || 3001; // Use the env variable, or default to 3001
   
   // Before
   // const client = new pg.Client({ connectionString: 'postgresql://...' });
   
   // After
   const client = new pg.Client({ connectionString: process.env.DATABASE_URL });
   

6. Finally, and most importantly, add .env to your root .gitignore file to ensure you never commit it to version control. You can also create a .env.example file that lists the required variables without their values, which is safe to commit.

Managing Environment Variables in React (Your Frontend with Vite)

Handling environment variables on the frontend is different because all frontend code is public. Anything you expose here, including environment variables, can be seen by anyone using their browser's developer tools.

Therefore, you must never place true secrets (private API keys, database credentials, JWT secrets) in your frontend environment variables.

Frontend environment variables are for non-sensitive, public configuration, like the URL of your backend API.

Vite (the build tool your React project uses) has a specific system for this:

1. Variables must be stored in a .env file in the frontend directory.
2. Variables must be prefixed with VITE_. This is a security feature to prevent accidentally exposing other variables.
3. You access them in your code using import.meta.env.VITE_VARIABLE_NAME.

Let's watch a quick video that demonstrates this Vite-specific approach.

For your project, a good use case would be defining the base URL for your API.
In your frontend/.env file:

# frontend/.env
VITE_API_URL=http://localhost:3001

Then, in your frontend code where you make fetch requests:

// Before
// fetch('http://localhost:3001/api/tasks')

// After
const API_URL = import.meta.env.VITE_API_URL;
fetch(`${API_URL}/api/tasks`);

This makes it easy to change the API endpoint when you deploy.

Handling Different Environments (Development vs. Production)

Your application will run in at least two environments: development (on your machine) and production (on the live server). Each may need different settings.

For the Backend (Node.js):
When you deploy your application, most hosting services (like Render, which we'll use next) have their own system for setting environment variables directly on their platform. You won't upload your .env file. A common pattern is to only load the .env file if the application is not in production.

// In backend/index.js
if (process.env.NODE_ENV !== 'production') {
  require('dotenv').config();
}

This way, your local machine uses .env for development, and the production server uses its own provided variables.

For the Frontend (Vite):
Vite has built-in support for environment-specific files that it loads automatically:

• .env.development: Loaded only in development (npm run dev).
• .env.production: Loaded only in production (npm run build).

For example, you could have:

frontend/.env.development

VITE_API_URL=http://localhost:3001

frontend/.env.production

VITE_API_URL=https://www.your-live-app.com

Vite will automatically pick the right file based on the command you run, embedding the correct VITE_API_URL into your code.

Security Best Practices: A Summary

Properly managing environment variables is a cornerstone of application security. Let's consolidate the most important rules.

Conclusion

You have now learned how to decouple your application's configuration and secrets from its source code—a critical step towards building professional, secure, and deployable applications.

Key Takeaways:

• Environment variables store configuration outside your code, enhancing security and flexibility.
• In Node.js, use the dotenv package to load variables from a .env file into process.env.
• In React with Vite, use a .env file and prefix variables with VITE_ to expose them to the frontend via import.meta.env.
• Never put sensitive secrets in frontend (client-side) code, even in environment variables.
• Always add your .env files to .gitignore and use a .env.example file as a template for other developers.

Preview of the Next Lesson:
Your application is now fully configured and secure. All that's left is to get it on the internet! In our next lesson, you will deploy the full-stack application to a Platform-as-a-Service (PaaS) like Render, where you will apply your new knowledge of environment variables in a real production setting.