Before talking about starting and stopping anything, let’s be clear about what we’re starting and stopping.

One container, one job

A single Docker container is designed to do one focused job well — run a web server, run a database, run a background worker. This is intentional: keeping each container narrow makes it easier to update, scale, or replace independently of everything else.

Real applications need several jobs done together

Almost no real application is just one job. A typical web application might need a database to store data, a backend service to handle business logic, a cache to speed up repeated requests, and a web server to handle incoming traffic. Each of these naturally becomes its own container. A “multi-container app” is simply this collection of separate, single-purpose containers that are meant to run together, talk to each other, and be managed as one logical unit.

If starting containers in any order “usually works,” why is this even a topic worth studying?

Problem 1 — Dependencies aren’t ready yet

If a backend API container starts and immediately tries to connect to a database container that hasn’t finished starting up yet, the connection attempt fails. Depending on how the backend handles that failure, it might crash, hang, or silently misbehave — none of which is a good first impression for an application.

Problem 2 — Shutdown can lose data or drop requests

Stopping is just as delicate as starting, in the opposite direction. If a database container is stopped while a backend container is still mid-write, that operation can be interrupted. If a web server is stopped before in-flight requests finish, users see failed requests instead of clean responses.

Problem 3 — Manual coordination doesn’t scale

With two containers, a person could plausibly start them in the right order by hand and remember to stop them in reverse. With ten, fifteen, or twenty containers — a realistic number for a mid-sized application — manual coordination becomes error-prone and exhausting, and it’s exactly the kind of repetitive, rule-based task computers are good at and humans are not.

Docker’s answer to “manage several containers as one app” is a tool called Docker Compose.

What Compose actually is

Docker Compose lets you describe every container your application needs — what each one does, how they connect to each other, and which ones depend on which — in a single declarative description. Instead of manually typing out separate start commands for each container, you describe the whole application once, and Compose figures out how to bring it all up (and later, tear it all down) correctly.

Services, not just containers

In Compose’s vocabulary, each piece of your application (database, backend, cache, web server) is called a “service.” A service describes what a container should look like — which can also include how many copies of it should run, and what it depends on. Compose’s job is to turn that description into actual running containers, correctly wired together.

The project as a unit

All the services described together are treated as one “project.” This matters enormously for starting and stopping: instead of issuing separate stop commands to five different containers, you issue one command against the project, and Compose applies it to every service that belongs to it, in the correct order.

Let’s look at the actual components that make coordinated starting and stopping possible.

The Docker daemon

As with everything in Docker, the background daemon process (dockerd) is what actually creates, starts, and stops containers. Compose doesn’t bypass this — it talks to the same daemon, just in a much more organized, batched way.

The application description

This is the declarative description mentioned in Chapter 3 — a structured file listing every service, its dependencies, its network connections, and any storage it needs. This description is the single source of truth for what the “whole application” looks like.

The default network

When Compose brings up a project, it automatically creates a private network shared by all the services in that project. This is what lets, say, the backend service reach the database service simply by using the database’s service name — no manual network wiring required.

The dependency graph

Compose builds an internal graph of “which service depends on which” based on the application description. This graph is the actual blueprint used to decide start order (and, in reverse, stop order).

flowchart TD
    A[Application Description] --> B[Docker Compose]
    B --> C[Dependency Graph]
    B --> D[Docker Daemon]
    C --> D
    D --> E[Shared Project Network]
    D --> F[Container: Database]
    D --> G[Container: Cache]
    D --> H[Container: Backend API]
    D --> I[Container: Web Server]
    F --> E
    G --> E
    H --> E
    I --> E
        

This is where the real mechanics live — how does Compose know what to start first?

Declared dependencies

When you describe a service, you can explicitly state that it depends on one or more other services. This is a direct instruction: “don’t even attempt to create me until these other services have been created first.”

Topological ordering

Internally, Compose treats the whole set of services and their dependency relationships as a graph, and calculates what’s called a topological order — essentially, a valid sequence where every service appears only after everything it depends on. This is the same kind of technique used for tasks like “put on socks before shoes.”

“Created” vs. “ready” — an important distinction

A common point of confusion: Compose can guarantee that a database container has been started before a backend container is created, but that’s not the same as the database being fully ready to accept connections. Starting a container process and that process finishing its own internal startup work (like initializing a database) are two different moments in time. This is why many applications add their own internal “wait and retry” logic when connecting to a dependency, rather than relying purely on start order.

sequenceDiagram
    participant U as You
    participant C as Compose
    participant DB as Database Service
    participant API as Backend API Service
    U->>C: Start the project
    C->>C: Calculate dependency order
    C->>DB: Create and start container
    DB-->>C: Container process started
    C->>API: Create and start container (depends on DB)
    API->>DB: Attempt connection
    DB-->>API: Ready (after its own internal startup)
        

Let’s walk through the complete lifecycle of a multi-container app, from a cold start to a full teardown.

Stopping a container isn’t an instant, brutal kill — Docker gives every container a fair chance to shut down cleanly first.

The polite request first

When a container is told to stop, Docker first sends it a polite termination signal — essentially a request that says “please finish up and shut yourself down.” A well-built application uses this moment to stop accepting new work, finish anything already in progress, close open connections, and exit cleanly.

The grace period

Docker then waits for a configurable grace period, giving the application time to actually respond to that polite request. Most applications finish well within this window under normal circumstances.

The forceful fallback

If the container hasn’t exited by the end of the grace period — because it’s hung, ignoring the signal, or simply too slow — Docker escalates to a forceful termination, ending the process immediately regardless of what it was doing. This is a safety net, not the preferred outcome, since it can interrupt in-progress work.

Coordinating multiple containers also means coordinating how they’re allowed to reach each other.

Shared networks are convenient — and risky if too open

The automatic shared network that lets services talk to each other by name is convenient, but it also means every service on that network can potentially reach every other service, unless deliberately restricted. A compromised, internet-facing web server could then attempt to reach an internal database directly if nothing limits that path.

Startup order and exposed weak points

During the brief window while dependent services are still starting up and not yet fully protected by whatever safeguards they normally apply once running, there can be a short period of unusually high vulnerability — something worth being aware of for security-sensitive services.

Shutdown and data exposure

An abrupt, forced shutdown (see Chapter 7) can leave a service in a partially-written state. For services handling sensitive data, this makes graceful shutdown not just a reliability concern but a data-integrity and security concern too.

With several moving parts, visibility into what’s happening — and in what order — becomes essential.

Aggregated logs across services

Rather than checking each container’s logs individually, it’s common practice to view the combined, interleaved log output of every service in a project at once, which makes it far easier to see how services are reacting to each other in real time — especially during startup.

Per-service health status

Beyond simply “is the container running,” many setups track whether each service is actually healthy and ready to do its job, giving a clearer picture than process status alone — a container can be “running” while its internal application has already crashed or hung.

Startup and shutdown timing

Tracking how long each service takes to start (and to shut down gracefully) helps catch slow-growing problems early — a service that used to start in seconds but now takes minutes is often an early warning sign of a deeper issue.

Good pattern — explicit dependencies, always

Every service that genuinely relies on another should declare that relationship explicitly, rather than hoping things happen to start in a workable order by coincidence. Explicit dependencies make the system’s true shape visible to anyone reading the application description.

Good pattern — application-level readiness checks

Because “started” and “ready” aren’t the same thing (Chapter 5), well-designed services perform their own readiness checks and retry logic when connecting to a dependency, rather than assuming the dependency is instantly usable the moment it starts.

No. Tools like Docker Compose let you describe the whole application once and bring every service up (or down) together, in the correct order, with a single command.

It guarantees A was created and started first, but not necessarily that A has finished its own internal startup work. Many applications add their own readiness checks to handle that gap.

The reverse of the start order — services that depend on others are stopped first, and the services everything else relies on are stopped last, avoiding requests to already-gone dependencies.

Docker requests a graceful stop and waits for a grace period. If the container hasn’t exited by then, Docker forcefully terminates it, which can interrupt whatever work was still in progress.

No. Stopping — or even fully tearing down — the containers and network leaves any persistent data in volumes untouched by default, since volumes are separate, independently managed objects.

Starting and stopping a multi-container application is fundamentally about coordination, not just individual container commands. Tools like Docker Compose describe every service and its dependencies in one place, calculate a valid start order automatically, wire services together on a shared network, and reverse that order cleanly on the way down. Understanding the difference between a container being “started” and a service being truly “ready,” respecting graceful shutdown, and treating the whole group of services as one managed application rather than a loose collection of separate containers is what separates a fragile setup from a dependable one.