In modern development and production environments, Docker Compose is the primary tool for orchestrating multi-container applications, such as LNMP stacks or microservice clusters. However, as projects evolve, environments shift, and builds occur frequently, servers often become cluttered with "debris"—unused data volumes, dangling image layers, disk-filling logs, and "zombie" containers.

Many operations engineers rely on the blunt-force `docker system prune -a` command, but this carries a high risk of accidentally deleting data belonging to active services. Managing and optimizing multi-container stacks requires a more nuanced approach. This article outlines seven advanced Docker Compose techniques to help you manage resource usage throughout the entire lifecycle—from building and running to cleaning up.

Technique 1: Perform a "Total Wipe" with `docker compose down -v --rmi all`

The most fundamental cleanup steps are often the most overlooked. Frequently, users run only `docker compose down`, which stops containers and removes networks, while leaving data volumes and local images behind to consume disk space on the host.

When you are finished with a project, you should destroy it completely:

docker compose down -v --rmi all

`-v`: Removes named volumes defined in the Compose file (use with caution, as this results in data loss).

`--rmi all`: Removes all local images that were built or pulled for this stack.

This combination can instantly free up tens of gigabytes of disk space.

Technique 2: Clean Up "Orphan Containers" with `--remove-orphans`

If you rename a service in your Compose file or remove one entirely from `docker-compose.yml`, the previously running containers do not disappear automatically. They become "orphan containers"—left behind without a configuration, yet still occupying ports and memory.

When starting your stack, include this flag:

docker compose up -d --remove-orphans

Compose will automatically identify and remove any containers that are no longer defined in your configuration file, keeping your environment clean. Tip 3: Use `profiles` for on-demand loading—avoid resource-hogging "all-in-one" setups

In multi-container environments, the biggest risk is that everything rises or falls together. For instance, your `docker-compose.yml` might include not only core services like Nginx and MySQL, but also debugging tools—such as phpMyAdmin, Redis-Commander, or even Prometheus—that you rarely use. These tools end up consuming memory and CPU unnecessarily.

Advanced optimization: Use the `profiles` tag in your configuration file.

yaml

services:

phpmyadmin:

image: phpmyadmin

profiles: ["debug"] # Only starts when the 'debug' profile is specified

With this setup, running `docker compose up -d` by default will only launch your core services. When you need to troubleshoot the database, you can simply run `docker compose --profile debug up -d`. Once you're finished, you can stop the services, significantly reducing the load on your system.

Tip 4: Enforce log rotation to prevent disk space exhaustion

By default, Docker containers write application console output (stdout/stderr) to disk using the `json-file` format—without any limits. A container that continuously logs errors can consume all available disk space on the host machine in a single night. Don't wait until your disk is full to take action; set limits directly within your Compose configuration:

yaml

services:

web:

image: nginx

logging:

driver: "json-file"

options:

max-size: "50m"

max-file: "3"

This configuration limits each container's log file to a maximum of 50MB, keeping no more than 3 files (a total of 150MB). Once these limits are reached, older logs are automatically overwritten, effectively preventing logs from filling up your disk.

Tip 5: Use `run --rm` to avoid leaving behind "disposable" clutter

When performing one-off tasks—such as database migrations, running test scripts, or generating data—never use `up` or `exec`. Using `up` leaves behind a container that has finished its task but remains in an "Exited" state. Over time, this can lead to hundreds of "zombie" containers cluttering your system (visible via `docker ps -a`). When executing one-off tasks, always use:

docker compose run --rm web python migrate.py

The `--rm` flag ensures that the container is automatically deleted the moment the task finishes and the container exits, leaving no trace behind.

Tip 6: Use `healthcheck` to prevent resource waste caused by "zombie" states

A container being in a "Running" state does not necessarily mean the application is healthy and functional. For example, a MySQL container might have started, but if it is still undergoing internal initialization, Nginx might encounter errors when routing traffic to it—potentially even triggering repeated container restarts. Such "zombie" processes can end up consuming backend resources indefinitely.

Configure health checks in Compose to let the system manage container states automatically:

yaml

services:

db:

image: mysql

healthcheck:

test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]

interval: 10s

timeout: 5s

retries: 3

Combine this with `depends_on` using the `condition: service_healthy` setting to ensure that dependent services are truly healthy before subsequent containers are started. If health checks fail repeatedly, Docker will mark the container as `unhealthy`, allowing you to easily identify and clean it up using monitoring tools.

Tip 7: Regularly clear orphaned build caches

When you rebuild images using `docker compose build`, Docker retains old build layer caches by default to speed up future builds. Over time, as code commits accumulate, these caches can consume tens or even hundreds of gigabytes of disk space.

Instead of using the global `system prune` command, you can use a command specifically designed for clearing build caches:

docker builder prune --filter until=168h -f

This removes unused build caches older than 7 days (168 hours), freeing up disk space while still maintaining the performance benefits of cached layers for recent, frequent builds.

By applying these 7 Compose tips, you can keep your multi-container stacks well-organized and avoid issues like disk space warnings or wasted resources.

However, keep in mind that frequent building, pulling, and starting/stopping of containers places significant demands on your server's disk I/O and network throughput. If your underlying infrastructure lacks robustness, frequent image builds can instantly push poor-quality disk I/O to 100% capacity, causing the entire system to lag. Furthermore, if there is significant packet loss when pulling images from overseas, the build process may become trapped in an endless loop of retries.

Efficient code requires an efficient runtime environment. Master these 7 advanced techniques—and leverage Jtti’s powerful underlying infrastructure—to ensure your multi-container stack not only runs with a light footprint but also delivers high-speed performance.