It is common for your backend services and frontends to run in more than one environment. They can run in development in your localhost machine. You can have a staging environment as close to production environment to be able to test everything before a release. And finally, you have the production environment where your real users are using your product.
If you read 12factor about config 12factor Config, you know you need to keep your environment config separate from your code as a good practice.
You can have credentials to external services like email providers. You can have database URI that will be used per environment. And, you can also have some specific endpoint per environment.
Should your code change based on the environment they are running?
This is a hard question, and most of the time you want your code to behave the same independent of the environment its running.
However modifying behavior on development and staging can be useful to make it easy to test.
We can also be even more strict in production if needed.
How to check the current environment
At Woovi, we have a special environment variable called APP_ENV. APP_ENV has only 3 possible values: development, staging and production.
We use APP_ENV checks to enable or disable behavior based on the environment.
const isStating = process.env.APP_ENV === 'staging'
Use cases to modify behavior based on the environment
When we are in development or staging, we only send emails to users and customers that have the @woovi.com domain.
This helps us ensure we are not sending test email to our users in production. The same applies to web push notifications.
We also disable sending SMS because it is not cheap.
We disable some KYC validation to be able to create bank accounts with fake data in development and staging.
We only enable some experimental feature flags based on environment to avoid causing problems in production.
How to share .env with your team
You can use DotEnv service to save your .envs files to share with your team.
Conclusion
Modifying code behavior is better using feature flag then checking environment variable. However, using environment variables makes more sense to some scenarios and both strategies can be used together.
We do use process.env as feature flags for development to enable better DX, you can read about it here https://dev.to/woovi/processenv-as-feature-flags-nf
Woovi
Woovi is a Startup that enables shoppers to pay as they like. To make this possible, Woovi provides instant payment solutions for merchants to accept orders.
If you want to work with us, we are hiring!
Photo by Robert Lukeman on Unsplash
Top comments (1)
find out if website is production or development by Checking your app's environment (development, staging, or production) is crucial for separating config from code, ensuring proper testing, and preventing unwanted actions in production. Use environment variables like APP_ENV to adjust behavior—e.g., restricting emails, disabling costly services, or enabling feature flags. This helps maintain consistency and safety across environments while improving development efficiency.