Stop Using .env Files: Managing Secrets in Production

Stop Using .env Files: Managing Secrets in Production

While .env files are excellent for local development, they pose significant risks in production environments. If an attacker gains access to your server, the .env file serves as a roadmap to sensitive information such as your database credentials, Stripe keys, and AWS credentials. Therefore, a professional production environment should never store secrets in plain text on disk.

The Better Way: Environment Injection

In today's modern CI/CD workflows, secrets should be injected into the application's process memory at runtime. For instance, if you utilize GitHub Actions, you can securely store your keys in Repository Secrets. These secrets are encrypted and only decrypted during the build and deploy steps, ensuring they never appear in your logs or repository.

The Enterprise Way: AWS Secrets Manager

For applications requiring high security, such as those in Fintech or ESG sectors, consider using AWS Secrets Manager or HashiCorp Vault. Instead of having your application read from a file, it can make an API call to the secret manager using its IAM Role. This approach offers several advantages:

• Automatic Rotation: Change your database passwords every 30 days without redeploying your code.
• Audit Trails: Monitor exactly who or which service accessed a secret and when.

Securing the Deployment

When deploying to AWS EC2, it is essential to use IAM Instance Profiles. This configuration allows your Node.js application to communicate with S3 or Secrets Manager without the need to store an AWS_ACCESS_KEY on the server. Consequently, if the server is compromised, there are no static keys for an attacker to exploit.