You have to see the `.env` file from the context of where it gets deployed.
For example, when we [1] deploy applications in Kubernetes, we have built an admission controller that fetches secrets from vault and converts them into env variables or secrets for the application at runtime. In this way, you will only have a reference in the form of annotation for the application.
If you give an `.env` as is, people will extract that value and start using it. You will end up leaking secrets.
Another way we have been exploring injecting secrets is via a sidecar for the application or via SDK but the lift seems to be a bit too much.
I think the deployment environment should be responsible for injecting the credentials for the best posture.
For example, when we [1] deploy applications in Kubernetes, we have built an admission controller that fetches secrets from vault and converts them into env variables or secrets for the application at runtime. In this way, you will only have a reference in the form of annotation for the application.
If you give an `.env` as is, people will extract that value and start using it. You will end up leaking secrets.
Another way we have been exploring injecting secrets is via a sidecar for the application or via SDK but the lift seems to be a bit too much.
I think the deployment environment should be responsible for injecting the credentials for the best posture.
[1] https://adaptive.live