Docker Compose Homelab Guide: Persist Data, Check Desktop Licensing

The guide is written from one self-hoster's experience, and the author says Docker runs his entire homelab. That is personal testimony, not a benchmark, but Docker's own documentation backs up the approach he recommends. Below, the tutorial is checked against Docker's documentation, and the details a Windows or Linux homelab owner needs before moving services into containers are filled in.

Docker Compose Turns a Homelab Into a File You Can Read​

The guide's strongest point is its comparison of docker run and Docker Compose. With docker run, every setting sits on the command line: environment variables, port mappings, bind mounts. To change one, the author explains, you stop the container, rebuild the command from memory and redeploy. With Compose, those settings live in a docker-compose.yml file inside the service's folder. You edit the file, run docker compose up -d again, and Compose applies the changes.

Docker describes Compose the same way. It is a tool for multi-container applications where you use a YAML file to configure your application's services. Then, with a single command, you create and start all the services from your configuration. Docker's architecture documentation calls Compose another Docker client, one that works with applications made of several containers. Like the docker command, it talks to the Docker daemon (dockerd), which builds and runs the containers.

For a homelab, the benefit is maintenance rather than less administration. A Compose file is a written record of what image a service uses, which ports it opens and where its data is stored. It can be copied, backed up or put under version control. A docker run command typed six months ago is gone unless you saved it somewhere. Docker's current hands-on lab shows how far the format goes. Its exercises include control service startup order using health checks and depends_on conditions and persist data across container restarts with named volumes.

The author also uses Portainer, a web interface for managing Docker. He says Compose is the easiest way to work with Docker unless you use a web UI like that. The two work together: Portainer is a management front end, while Compose files are a portable text format.

What Containers Are, and Why the "Mini VM" Picture Misleads​

The guide calls a container a lightweight virtual machine that isn't really a virtual machine, and later describes it as a miniature operating system configured for one application. Its example is a Plex container built on an Arch Linux image that contains only the parts of Arch needed to run Plex.

Docker's documentation is more precise. It defines a container as an isolated process with all the files it needs to run. Multiple containers on one host share that host's kernel. A virtual machine runs a complete operating system with its own kernel, drivers and programs. That shared kernel is why containers use fewer resources than one VM per application. On Linux, Docker builds its isolation from kernel features called namespaces: each container gets its own set, and each part of the container can only see its own namespace.

The distinction affects decisions. A container's isolation is lighter than a VM's, and Docker's documentation describes the environment as "loosely isolated." Docker also notes that containers and VMs are often used together. A cloud VM running a container runtime can host many containerized applications, and a homelab can do the same thing on a hypervisor.

The guide also mixes up images and containers in places. An image is a read-only template that packages an application's files, libraries, binaries and configuration. Docker says images are immutable: to change one, you build a new image or add layers on top. A container is a running instance of an image, with its own writable layer that starts empty each time the container is created.

Where Your Plex Settings Actually Live: Volumes and Bind Mounts​

The guide's best practical story is about recovery. The author says he broke something on his Docker server and took several containers down. He started them again fresh, pointed their mounted folders back at his storage, and the services came back "like they never stopped." It works because each container's data lived outside the container.

The tutorial's wording could leave beginners thinking Docker does this for them. It says each container has persistent storage that survives, plus disposable storage that is wiped when the container is updated. The persistence only exists if you set it up. Docker's documentation says that when a container is removed, any changes not stored in persistent storage disappear. By default, anything written to a container's writable layer is lost when the container is destroyed. A settings file you never mapped to a volume or host folder goes with it.

Docker offers two ways to keep data:

• Named volumes are Docker's preferred way to persist container data. Docker manages them, they exist independently of any container, and removing a container does not remove its named volume.
• Bind mounts link a folder on the host to a path inside the container. This is the /config or /data pattern the guide describes, and it suits files you want to open from both the host and the container.
• Bind-mounted files are not isolated from the host. Processes on the host and inside the container can both change them.
• Volumes are deleted with a separate command, and unused volumes can be pruned in bulk. A careless cleanup can delete the data you meant to keep.

Persistence is not a backup. A named volume survives a container being replaced, but it does not survive a failed disk or an accidental prune. The author's recovery worked because his data sat on storage he could point new containers at. If those folders had been damaged, restarting the containers would not have brought the services back.

Running hello-world and Your First Compose File​

The guide's first-run procedure is short. Install Docker for your operating system, then open a terminal and run a test container:

1. Run sudo docker run hello-world. Docker pulls the image from Docker Hub and starts it, and the container prints a message listing the steps Docker took to produce it.
2. Create a docker-compose.yml file containing a service called hello that uses the hello-world image. The file needs only three lines: services:, then hello: indented beneath it, then image: hello-world indented beneath that.
3. Run docker compose up in the same folder. The output should match what the first command printed.

Two parts of this need context. First, sudo is a Linux habit. Docker Desktop on Windows and macOS does not use it, and whether you need it on Linux depends on how Docker Engine is set up. Second, hello-world is only a smoke test. It prints its message and exits. Docker's beginner material uses a longer-running example, docker run -d -p 8080:80 docker/welcome-to-docker, which starts a web server you can open at localhost:8080. You then check it with docker ps, which lists only running containers. Add -a to see stopped ones.

The guide's explanation of Compose commands also needs fixing. It says docker compose up "just run it once and shut it down," while docker compose up -d runs the container in the background. Docker's CLI reference describes plain up differently: the docker compose up command aggregates the output of each container (like docker compose logs --follow does). In other words, it runs attached to your terminal and streams output. The hello-world demo looks like "run once" because that particular container exits by itself. The -d flag means detached: it starts your containers in the background, freeing up your terminal for other tasks. For long-running homelab services, -d is the normal choice. To stop and remove a stack cleanly, use docker compose down, which Docker's own lab uses for teardown. Named volumes are not deleted unless you ask for that separately.
The guide writes the command as docker compose, with a space, which is Docker's current syntax. The hyphenated docker-compose belongs to the older standalone binary, and you will still see it in older tutorials. The filename docker-compose.yml still works, and Docker's newer material often uses compose.yaml.

Docker Hub, OCI and Alternatives to Docker​