OK, you wanted a conversation… :-)
I did read the post, but I assumed it was the starting point of a system or mechanism, not the end-point. Wanting to just run “docker compose up” is fine, but there is more to developing and deploying to production (and continuing post-launch).
That’s why I mentioned the CLI. It lets you go from a simple local app (Django on sqlite) to a Docker one (postgres, celery, redis, etc.), to all the way out to the cloud (ECS/EKS/serverless lambda/RDS), without having to remember what commands do what or managing lots of separate docker-compose files.
I can see we are VERY far apart on how docker should be used in moving toward a production-ready system.
For one thing, recommending putting secrets inside docker-compose is an instantly disqualifying piece of advice. There’s a whole ‘secrets’ section of docker compose that is there to prevent people from inadvertently including those in cleartext and baking them into images: https://docs.docker.com/compose/how-tos/use-secrets/.
Github itself has a secret scanning mechanism to prevent leakage: https://docs.github.com/en/code-security/secret-scanning/introduction/about-secret-scanning. For gitlab, there’s also Blackbox or HashiCorp vault. Putting AWS key/secret inside a repo can be VERY expensive and open one to legal liability if the account is misused. Repeated infractions could lead to AWS banning one’s account.
I really recommend you take down that part of your post, instead of proliferating bad practices.
As for the rest, to each their own.
I wouldn’t put any load on it until it was stained. At least two coats and a sealer.