Why is the .env file tracked in git?

[Exadra37]

The .env is widely used across all kinds of software projects and is well known to be used to configure sensitive information, like secrets, and tokens to third party services, etc.

I know that at the moment the .env file is not holding any sensitive data, but developers deploying Appwrite on their own may end-up using the .env file to store sensitive data, therefore they may commit it to their own forks and make it public accidentally. The extent of the damage that this can cause will depend on the type of info leaked, that may lead or not to financial losses or abuse of other systems.

As a Developer Advocate for security I would recommend to add the .env file to .gitignore and create instead a .env.example file that could then be copied when deploying Appwrite for the first time.

[eldadfux]

This .env file is used only for Appwrite maintainers and is not part of the installation script on instructions. It makes development much easier and is never used in production or take part of any official setup process. The file used for installation is generated by this config: https://github.com/appwrite/appwrite/blob/master/app/config/variables.php and the recommended docker-compose manual setup is located here: https://gist.github.com/eldadfux/977869ff6bdd7312adfd4e629ee15cc5

[Exadra37]

Thanks for your explanation and links.

Having the .env file as a .env.example will not harm how easy the maintainers life is during development, because all it needs is to copy it to .env after cloning the repo.

No one can guarantee that other developer using Appwrite will not use the .env file and accidentally commit it to their fork of Appwrite with whatever secrets are in the file. Please remember that .env file is widely used and developers have the muscle memory of using it across all their backend projects to drive their configuration and store secrets.

So, despite that Appwrite doesn't encourage its use in production, I think it would be better to be on the safe side and not have it tracked.

[Mabenan]

It would also prevent accidently commiting any changes to the file made in development.

[Exadra37]

If the Appwrite team is ok with it I can make a pull request with the change.

I can also provide a bash script to make it easier to work in development with the docker compose stack

The bash script could even have a bit of code to copy the .env.example file to .env:

if [ ! -f ./.env ]; then
    cp ./.env.example ./.env
fi

[stnguyen90]

I wonder if it would be useful to do something like this.