Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

troccoli's avatar

Which variable in .env and which in AWS secrets?

I would like to see what the best practice or consensus is regarding where to store environment variables.

I know not to store passwords, for example, in a committed .env file, and instead use AWS Secret (or equivalent) for that. On the other hand, I have not problem committing the app name (I don't in reality because I don't commit the .env file at all, but that's beside the point).

So where do people draw the line? What do you use secrets for, and what instead you just keep it in an .env file on the server?

0 likes
7 replies
Sinnbeck's avatar

I would never commit the env. Simple as that. Any default values are set in config anyways

If I was forced to I would encrypt it :)

troccoli's avatar

@Sinnbeck

I don't commit it either. But are you saying you don't have a .env at all?

reaz's avatar

I think your .env on the server should have the final real value. Now the question is how that .env file will be built. there are several ways, i have seen using aws parameter store, some uses git-secret.

troccoli's avatar

@reaz

That's a good point. So I'm guessing the .env is built as part of the deployment, with some values coming from AWS secrets or git secret, or something else. But what variables would you store as secrets to be retrieved during this process?

reaz's avatar

@troccoli , mostly third party api keys, like aws, mail service, etc, which should be kept secret. Rest can be in text file part of the repo

LaryAI's avatar
LaryAI
AI
1 year ago
Level 58

When deciding where to store environment variables, it's important to consider the sensitivity and security implications of each variable. Here's a general guideline to help you determine which variables should be stored in your .env file and which should be stored in AWS Secrets Manager (or a similar service):

Store in AWS Secrets Manager:

  1. Sensitive Information: Any sensitive data such as database passwords, API keys, and third-party service credentials should be stored in AWS Secrets Manager. This ensures that sensitive information is not exposed in your codebase or version control.

  2. Rotatable Secrets: If you have secrets that need to be rotated regularly for security reasons, AWS Secrets Manager can automate this process, making it a suitable place for such secrets.

  3. Access Control: Use AWS Secrets Manager for secrets that require strict access control. AWS IAM policies can be used to manage who can access these secrets.

Store in .env File:

  1. Non-Sensitive Configuration: Variables that are not sensitive, such as application name, environment (development, production), or feature flags, can be stored in the .env file.

  2. Environment-Specific Settings: Configuration settings that are specific to the environment (e.g., local development settings) and do not contain sensitive information can be kept in the .env file.

  3. Local Development: For local development, you might store some less sensitive information in the .env file to simplify the setup process. However, ensure that this file is not committed to version control.

Best Practices:

  • Do Not Commit .env Files: Ensure that your .env file is included in .gitignore to prevent it from being committed to version control.

  • Use Environment Variables in Production: In production, load environment variables from a secure source like AWS Secrets Manager or a similar service, rather than relying on a .env file.

  • Audit and Review: Regularly audit your environment variables and secrets to ensure that sensitive information is stored securely and access is properly controlled.

By following these guidelines, you can maintain a secure and organized approach to managing environment variables and secrets in your applications.

troccoli's avatar

Thanks for all your comments, I think I have an idea of what to store in AWS secrets.

However, we use Docker so that sensitive information, like for example the database password, are set as environment variables in the container during deployment (the values coming from AWS). Non-sensitive information are instead written in the .env file directly (still during deployment).

At this point, from a security point of view, there is no difference. What I mean is, if someone gains access to the container, they can examine all environment variable as easily as looking at .env, right?

So, now I'm thinking of setting even the sensitive information in the .env file, still with the values coming for AWS. It's easier to have everything in one place, in case I need to inspect something.

What do you think?

Please or to participate in this conversation.