Environmental variables

Environment variables are configuration settings that you store outside your source code, such as database passwords, API keys and server addresses. They act as a separate file or system setting where you place sensitive data or environment-dependent values. This allows the same code to run on different environments (development, test, production) without having to modify code each time. For an SMB with an ecommerce store or custom application, this prevents passwords from ending up in your GitHub repository or a developer from accidentally overwriting production data during a test.

How environmental variables work in practice

You define environment variables in a separate configuration file (often called .env) or directly in your hosting environment. Your application reads these variables at startup. Suppose you have an ecommerce store that connects to Mollie for payments. Instead of putting your Mollie API key hard-coded into your PHP or JavaScript file, you put it into an environment variable such as MOLLIE_API_KEY. Your code retrieves that value with a function like getenv() or process.env. Switching from test key to live key? Then you only modify the value in your .env file, not your entire codebase. That saves errors and makes deployment to new servers much faster.

Why environmental variables arose and why they are essential today

In the past, developers often placed configuration directly in the code. That became a problem as teams got bigger and code was shared through platforms like GitHub. Passwords and keys became publicly available online, resulting in data breaches and security incidents. The Twelve-Factor App methodology made environment variables standard. Today, hosting platforms like Kinsta, Cloudways and Vercel require you to configure sensitive data via environment variables. It also makes sense for AVG compliance: you separate configuration from code, making audits easier and reducing your risk of inadvertent disclosure of personal data.

What environmental variables bring to web projects

For an SME with a WordPress site, ecommerce store or custom application, environment variables offer three concrete benefits. First, you increase security: API keys and passwords are not in your code repository. Second, you make deployment more flexible: the same codebase runs on local development environment, staging server and production, each with its own database credentials. Third, you simplify collaboration: a new developer clicks his own .env file and can get started right away without production access. With web development by Monkey Vision, we set up default environment variables for all custom projects, so your application remains scalable and secure as your team or infrastructure grows.

Environmental variables appear in almost every Web project, but how you deploy them varies from situation to situation. Here are four concrete applications you might encounter as an SME entrepreneur, plus a decision criterion for when environmental variables are or are not the right choice.

Securely manage database credentials and API keys

The most common application: you store database username, password and hostname in environment variables such as DB_HOST, DB_USER and DB_PASSWORD. The same goes for API keys from services like Mailchimp, Google Maps, Stripe or Mollie. This keeps sensitive data out of your Git repository and allows team members with different access levels to work without everyone seeing production passwords. An ecommerce store with 500 products and integrations with an ERP system often has ten to fifteen API keys. By placing them centrally in environment variables, you change an expired key in one file instead of searching through dozens of PHP or JavaScript files.

Environment-specific configuration for development, test and production

You want your application to run on your local laptop against a test database, on the staging server against a copy of live data, and in production against the real database. With environment variables, you set an APP_ENV for each environment (for example, local, staging, production). Your code reads that variable and adjusts behavior: debug notifications only in local, caching only in production, email notifications only to real customers in production. So a B2B service provider building a customer portal can safely test new features without customers seeing error messages or receiving test emails. This prevents you from accidentally overwriting production data during development.

Feature flags and A/B test configuration

Want to test a new checkout flow without immediately showing all visitors the new version? Place an environment variable such as FEATURE_NEW_CHECKOUT=true or false. Your code checks that variable and shows the old or new flow. This way you switch functions on or off without deploying code. This is useful for gradual rollouts: first test internally, then 10% of visitors, then everyone. An ecommerce store running A/B testing on product pages can use environment variables to quickly switch between variants without pushing code each time. Note: for complex feature management, dedicated tools like LaunchDarkly are more powerful, but for simple on/off switches, environment variables suffice.

Centralize external service endpoints and CDN URLs.

Your application retrieves images from a CDN, sends notifications via a webhook or synchronizes data with an external API. Those URLs sometimes change (migration to new CDN, new API version). By putting them in environment variables (CDN_URL, WEBHOOK_ENDPOINT), you modify one line instead of dozens of references through your code. A content-heavy site with thousands of images on a CDN can thus switch from cloudflare.com to its own domain in minutes without code modifications. This reduces downtime on infrastructure changes from hours to minutes.

When environmental variables are the right choice and when they are not

Use environment variables for data that varies by environment or must be kept secret: passwords, API keys, database credentials, service endpoints. Don't use them for business logic or settings that are part of your application configuration (such as product categories or rates). Those belong in a database or configuration file within your code. Also not useful: environment variables for data that marketers or editors need to modify. They don't have access to server environments. For those kinds of settings, a CMS or admin interface is better. A common mistake: creating too many variables for things that are actually constants, such as the name of your company or default language. That makes configuration unnecessarily complex.