I'm looking for a concise but practical introduction to Docker Compose. I'd like to understand where to keep Compose files, configuration, persistent data, and large media or application datasets for services such as Jellyfin, Nextcloud, ZoneMinder, and Home Assistant. It would also help to see how to organize multiple applications, choose between bind mounts and named volumes, handle permissions, create networks, update containers, and back everything up. I'm mainly after a sensible starting structure and the basic commands, along with enough explanation to understand what survives container replacement or upgrades.
4 Answers
A simple structure is to create one directory per application or stack, with its Compose file inside. For example, use something like /opt/stacks/jellyfin/compose.yaml and /opt/stacks/nextcloud/compose.yaml. Keeping each stack separate makes updates, backups, and troubleshooting much easier. There isn’t one mandatory location or filename, but compose.yaml or docker-compose.yaml are common choices. From the stack directory, start it with `docker compose up -d`, inspect problems with `docker compose logs`, and stop it with `docker compose down`.
Start with one small service and expand gradually. The Compose file describes the container, image, ports, environment variables, networks, and storage. Use bind mounts when files need to be visible on the host, such as media libraries, editable configuration, or data you want included in ordinary backups. Named volumes are useful when the application owns the data and you don’t need to browse it directly from the host. For large datasets, keep the actual data on a suitable disk and bind-mount that host path into the container. Always check the application documentation for the expected container paths and make sure the host directories have permissions matching the user the container runs as.
Networking and storage are where the short tutorials usually fall short. It’s worth learning which services need to share a network and which directories are disposable before deploying several applications.
For a beginner, a management tool can make the first few stacks easier to observe, but it’s still worth learning the command line underneath. A typical workflow is to edit the YAML, run `docker compose config` to validate it, use `docker compose up -d` to apply it, and check `docker compose ps` and `docker compose logs` when something fails. When updating, pull the new image and recreate the containers with `docker compose up -d`; persistent bind-mounted data or named volumes should remain unless you explicitly remove them. Avoid deleting volumes casually, since that can remove application data.
Treat each stack as something you should be able to rebuild. Keep the Compose files, environment files, and important configuration in an organized directory, and document which volumes and host paths contain irreplaceable data. Back up the configuration as well as the application data, but don’t waste backup space on caches or easily recreated files. Before upgrading, know how to restore the stack and which services must be stopped together. Testing a Compose file locally or on a spare machine is a good way to learn without risking your main data.
Writing down the restore process while setting things up makes sense. I hadn’t separated disposable cache data from the configuration and actual application data.
That helps. I’m currently trying Jellyfin and the confusing part is mapping my existing media directories while deciding where its configuration and cache should go.