reminds me of tons docker tutorials, where all of them are doing default password in plaintext in docker-compose file

I put devonly: as part of every placeholder secret in docker-compose.yml or similar config that is committed to Git. The goal is a developer who has just cloned the repo should be able to run the setup script and have the whole system running with random seed data without futzing with copying secrets from coworkers.

> I put devonly: as part of every placeholder secret in docker-compose.yml or similar config that is committed to Git. The goal is a developer who has just cloned the repo should be able to run the setup script and have the whole system running with random seed data without futzing with copying secrets from coworkers.

This problem is solvable without hard coding env variables into your docker-compose.yml file.

You can commit an .env.example file to version control which has non-secret defaults set so that all a developer has to do is run `cp .env.example .env` before `docker-compose up --build` and they're good to go.

There's examples of this in all of my Docker example apps for Flask, Rails, Django, Phoenix, Node and Play at: https://github.com/nickjj?tab=repositories&q=docker-*-exampl...

It's nice because it also means the same docker-compose.yml file can be used in dev vs prod. The only thing that changes are a few environment variables.

> *I put devonly: as part of every placeholder secret in docker-compose.yml or similar config that is committed to Git.&

I put it `insecure`. I think it makes it clear that the password, and file, aren't secure by default and should be treated as such.

With buildkit Docker now has support for secrets natively with `--secret`. This mounts a file that will only be exposed during build.