I stopped doing one mistake in Docker Compose files, and my self-hosted setup finally felt secure

Published Sep 8, 2026, 7:00 PM EDT Beginning his professional journey in the tech industry in 2018, Yash spent over three years as a Software Engineer. After that, he shifted his focus to empowering readers through informative and engaging content on his tech blog – DiGiTAL BiRYANi. He has also published tech articles for MakeTechEasier. He loves to explore new tech gadgets and platforms. When he is not writing, you’ll find him exploring food. He is known as Digital Chef Yash among his readers because of his love for Technology and Food. I love how easy Docker makes self-hosting. I can spin up an application, connect to a database, add a few settings, and have everything running with just a handful of commands. But that simplicity also made me careless about how I handled sensitive information. As I added more containers to my server, I started noticing just how often credentials, tokens, and other secrets became part of my deployment process. Nothing had gone wrong, but I knew I was relying too much on convenience. So, I made one small change to the way I manage my credentials, passcodes, and secrets in Docker deployments. It didn't make my setup complicated, but it made me much more comfortable with it. Hard-coding was convenient But too easy to expose When I first started running Docker containers, hard-coding values into my Compose files felt like the easiest way to get everything working. I could open the file, see exactly what each service needed, make a quick change, and restart the container. There was no extra setup to think about. For a small self-hosted setup, this convenience was hard to ignore. If an app needed a database password, an API token, or another configuration value, I could simply add it alongside the rest of the service settings and move on. The problem was that this approach made my Compose files do too much. They weren't just describing how my containers should run; they were also holding information that I didn't really want sitting there in plain text. I didn't notice the issue immediately because everything worked exactly as expected. My services started normally, updates were straightforward, and troubleshooting was simple. It was only when my Docker setup started growing that I began questioning whether keeping everything together was actually a good idea. Avoiding hard-coding is more powerful than you think A few approaches to prevent hard-coding Once I decided to stop putting secrets directly into my Compose files, I realized I had several ways to manage them. I didn't need to jump straight into a complicated secret-management system. I could choose an approach based on how much security and complexity my setup actually needed. The simplest step was moving sensitive values into a separate .env file. Instead of writing a password directly in docker-compose.yml, I could use something like ${DB_PASSWORD} and keep the actual value in .env. I also added .env to .gitignore so it wouldn't accidentally be committed to a repository. This made my Compose files safer to share and maintain, but there was an important limitation: .env is still a plain-text file sitting on the machine. For credentials that needed better protection, Docker secrets offered a stronger option. Compose lets me define a secret separately and give a container access to it as a file, usually under /run/secrets/. That means the secret doesn't need to be passed as a normal environment variable. The downside is application support. Some applications only look for credentials in environment variables. If the application supports the _FILE convention, I can point it to the mounted secret file instead. There are also external secret managers for setups that have grown beyond a handful of containers. Tools such as HashiCorp Vault, SOPS with age, Infisical, and Doppler can keep secrets centralized and provide more control over how they're stored and accessed. For my setup, I found it important not to overcomplicate things. A .env file was enough for some services, while Docker secrets made more sense for credentials I wanted to protect more carefully. Mistakes to avoid The Docker habits I had to change Separating secrets from my Compose files fixed one problem, but it also made me more aware of a few other mistakes that are easy to make with Docker. One thing I avoid now is putting credentials directly into a Dockerfile. Anything baked into an image can potentially remain in its layers, making it difficult to remove completely later. The same applies to environment values or configuration files copied into an image during the build. I also stopped reusing the same password across multiple services. If one application is compromised, I don't want that single credential to give someone access to everything else running on my server. Using unique credentials limits the damage when something goes wrong. Another mistake is assuming that services are safe simply because they're running on a private network. A misconfigured container, exposed port, or compromised application can still provide a path to other services. Finally, I always change default usernames and passwords when deploying a new application. Leaving the credentials supplied by the developer is an unnecessary risk, especially for services that might later become accessible from outside my network. My Docker setup finally feels under control I used to think securing a self-hosted setup meant dealing with complicated tools and endless configuration. In reality, this change showed me that better security can start with something much smaller. Once I began treating sensitive information differently from regular configuration, managing my containers became more intentional. It also changed how I think about the other services I run on my server. I don't need to make everything complicated just for the sake of security. I just need to avoid shortcuts that can create problems later. For me, separating secrets was one of those small changes that made the entire setup feel more mature.