38 Production Containers Audited: No `depends_on.restart` in Use

The `depends_on.restart` Oversight

For months, a manual step in a n8n upgrade runbook involved manually restarting a specific container after the main one reported healthy. This manual intervention, written by hand, was a placeholder for a boolean option that has existed in Docker Compose since version 2.17.0, released in 2023. The field, depends_on.<service>.restart, automates the process of ensuring dependent services are restarted in the correct order, a task previously handled by human operators.

This realization prompted an audit of 38 production containers across eight servers on September 17, 2026. The audit focused on two key pieces of information from each running container: its healthcheck configuration and the com.docker.compose.depends_on label. The goal was to understand the practical adoption of the depends_on.restart feature in real-world, client-facing environments.

The findings were stark: not a single one of the 38 audited containers utilized the depends_on.<service>.restart directive. This indicates a significant gap between the capabilities offered by Docker Compose and its implementation in production systems. The manual workaround, as seen in the n8n upgrade runbook, is still the de facto standard for managing service dependencies during restarts, despite a built-in solution being available for over three years.

Understanding `depends_on` and `restart`

Docker Compose allows developers to define dependencies between services. The depends_on key in a docker-compose.yml file specifies that one service must start before another. However, simply starting a service doesn't guarantee it's ready to receive connections or perform its function. This is where healthchecks come into play. A healthcheck defines a command that Compose runs periodically to test if a service container is healthy.

Historically, managing the startup order and ensuring readiness of dependent services required custom scripting or manual intervention. Developers often relied on polling healthcheck statuses or implementing arbitrary delays. The introduction of depends_on.<service>.restart in Compose v2.17.0 aimed to streamline this. When set to true, Compose would wait for the dependent service to be healthy before proceeding with the startup of the service that depends on it. Crucially, it also implies that if the dependent service crashes, Compose can be configured to restart it, ensuring the dependent service remains available. This feature is designed to simplify complex startup sequences and improve the resilience of multi-container applications.

The audit's negative findings suggest that many teams, like the one managing the n8n instance, are either unaware of this feature, accustomed to their manual workflows, or perhaps have concerns about its reliability or compatibility with their specific use cases. The manual approach, while functional, introduces potential for human error, delays in deployment, and increased operational overhead.

Implications for Production Deployments

The absence of depends_on.restart in these production environments has several implications. Firstly, it points to a potential fragility in application startup sequences. If a dependent service fails during an upgrade or a restart event, the application might enter an unhealthy state without an automated recovery mechanism. Operators might be unaware of the failure until end-users report issues, or until their manual runbooks are executed, which may not always be timely.

Secondly, it represents a missed opportunity for operational efficiency. Automating service dependency management reduces the cognitive load on operations teams and minimizes the risk of human error. The manual restart step in the n8n runbook is a clear indicator that this process is still being managed by humans, consuming valuable time and attention that could be directed elsewhere. This is akin to having a self-driving car feature available but continuing to manually steer, brake, and accelerate for every trip because you haven't updated your car's software.

Furthermore, this oversight could impact the perceived reliability of containerized applications. While Docker Compose offers sophisticated tools for orchestration, their underutilization means that applications may be less resilient than they could be. The audit suggests that many teams are operating with a manual safety net, rather than leveraging the built-in resilience features provided by the platform.

The Path Forward

The widespread lack of adoption for depends_on.restart is not necessarily a reflection of poor engineering but likely an indicator of evolving best practices and awareness. As container orchestration matures, so do the tools and configurations available to manage complex applications. For teams still relying on manual steps for service dependency management, the audit serves as a clear call to action.

Developers and operations teams should review their docker-compose.yml files and deployment runbooks. Integrating depends_on.<service>.restart: true can significantly enhance the robustness of application deployments. This requires understanding the healthcheck configurations of each service and ensuring they accurately reflect service readiness. The benefit is a more automated, reliable, and efficient deployment process, reducing the risk of downtime and operational burden. If you manage production containers, taking an hour to audit your own Compose configurations for this feature could prevent future headaches.

The surprising detail here is not that the feature exists, but that it has been largely ignored in practice for years. This suggests a significant portion of the developer community might be operating on slightly outdated mental models of Compose's capabilities, or simply haven't had a compelling reason to revisit their established, albeit manual, workflows.