When I started with Docker, my biggest challenge was to get a container up and running. While copy-pasting docker run commands felt straightforward, I’ve often forgotten the correct flags and had to change volume directory details. Over time, deploying Docker containers via the CLI felt empowering as I learned the ropes of containers.

When I first tried Docker Compose, it felt like a complex chore, and I had gotten used to editing docker run commands in the Terminal. Once I started using it to deploy stacks, I realized how much time I had wasted trying to run them individually via the CLI. Gradually, Docker Compose became my go-to for installing containers, and I now prefer it over the CLI.

Docker CLI felt the correct way to begin

Works with individual containerization​

Using the CLI in Terminal was vital for learning the fundamentals of container core concepts: images, containers, ports, volumes, and networks. Goofing up on even one of them meant dealing with errors when starting a container. Otherwise, it was difficult to identify the flags in a long string of docker run commands.

I found it really easy to use a string of text as a command to start a container. However, it was very tedious to change values like volumes. Also, most GitHub projects and Docker tutorials always start with CLI instructions. That kept me using the CLI longer, since I had gotten patience with directly adjusting values in the Terminal.

Adding databases, volumes, dependent services, or environment variables through the CLI in Terminal is difficult. Reproducing the same on another machine becomes a challenge because scrolling and finding the exact command are difficult.

Using CLI for Docker feels right for quick action, as long as I need to deploy and manage a single container at a time. Everything changed once I started using Docker Compose to run multiple containers on my home server.

Why I switched to Docker Compose

More than convenient

Digging through the Terminal history and scattering notes for deploying containers had become tedious. So when I moved to using Docker Compose, I felt comfortable defining the variables to deploy a container. My focus shifted to defining the necessary values in a Compose file rather than simply running it.

The YAML configuration file serves as a plan or storyboard where I clearly define ports, networks, databases, and other services. I enjoy how I can define multiple containers simply by accurate names, and declare dependencies to make them run properly.

The freedom from having to find out IP addresses and services that talk to each other by name is refreshing. Also, I get to define a single network for all containers or leave them running on isolated networks. For example, I managed to run the Netdata app along with its database on the same network as other containers to monitor my home lab.

Most importantly, including environment variables, like using a GPU, is possible right in the YAML file instead of creating a .env file separately.

Besides, it’s easier to spot mistakes and easier to modify someone’s existing Compose file. Everything about my containers stays in a single YAML file. Moreover, it’s convenient to spin up or down all the containers with a single command.

Hidden benefits of using Docker Compose

Not visible immediately​

Implementing version control for running containers in my home lab makes it easy to trace errors and helps roll back changes. With the same YAML file, I can replicate the container environment any number of times and won’t even have to tweak anything unless necessary.

I mistook Docker Compose as an individual tool, but it also serves as a solid documentation helper.

Because whenever I get stuck, I share the YAML file with other developer friends so they can clone the environment and help me fix the spot where I goofed up. Of course, the command for spinning containers up and down remains the same to help avoid any confusion.

The benefits of Docker Compose compounded over time, and I moved to tools like Dockge for spinning up container stacks at once.​

The Docker CLI still makes sense to use

Only in specific scenarios​

Favoring Docker Compose didn’t make the CLI obsolete. In fact, I clarified the distinction between the two tools. Using CLI to spin up individual containers is still a valid path for inspecting how a container works and debugging when it doesn’t work as expected.

Using the CLI is a worthwhile starting point for learning Docker fundamentals. It helps to remember Docker commands when starting a self-hosting journey.

Using CLI, you can learn about the low-level controls and experiment with containers before moving them to your actual home lab setup. So it’s a good idea to start with the Docker CLI, but Docker Compose is better for running actual projects.

The regret of using CLI for too long

Using the Docker CLI felt cool initially, but it turned out to be detrimental when dealing with multiple containers, and I lost several hours trying to spin them up. That’s when I realized that Docker Compose makes the complex architecture manageable and clearly visible before deploying anything.

If you’re still using Docker CLI for multi-container setups, give Compose a try. That’ll help you realize the convenience of using a single configuration file. As for me, I don’t regret using CLI, but I waited too long to switch to Compose. Ultimately, there are no wrong tools, only incorrect approaches.