The Daily Driver Commands
Once your docker-compose.yml is written, you interact with your environment through a small set of commands, all run from the directory containing the file: bringing the stack up in detached mode (optionally rebuilding images first), stopping services without removing them, tearing them down along with their containers and networks (with a separate destructive flag needed to also remove named volumes), checking service status, streaming logs for all services or just one, running a one-off command inside a service container (like a database migration or an interactive shell), and scaling a service to multiple replicas.
Environment Variables and .env Files
Hardcoding passwords in docker-compose.yml is a security risk and makes the file non-portable. The standard pattern is to define secrets in a .env file (never committed to git) and reference them from the Compose file using ${VARIABLE} syntax — for example, a service's POSTGRES_PASSWORD environment entry set to ${POSTGRES_PASSWORD} rather than a literal value.
Compose automatically reads .env from the same directory and substitutes ${VARIABLE} references. Add .env to your .gitignore and commit a .env.example with placeholder values instead.
Interviewers sometimes ask: "How do you handle secrets in Docker Compose?" The .env file approach is acceptable for local development but not for production. For production, the correct answers are: Docker Swarm's secrets feature (which mounts secrets as files in /run/secrets/), Kubernetes Secrets, or a dedicated secrets manager like HashiCorp Vault or AWS Secrets Manager. The key point: environment variables are visible in docker inspect output and in process listings — they are not truly secret.