In this article
docker compose restart, docker compose alpha watch, docker compose attach, and docker compose bridge act on four different kinds of targets. The useful question is not simply “What does this command do?” but “What object does it affect?”
That distinction becomes especially important after editing compose.yml. Docker explicitly states that restart does not reflect changed Compose configuration, including changed environment variables (Docker Compose restart reference). The supplied references do not document any of the other three commands as applying those configuration changes either.
Command-to-target map
| Command | Documented target | Options or qualifications | Boundary of the documentation |
|---|---|---|---|
docker compose restart |
All service containers or specified services (reference) | --no-deps; --timeout (reference) |
Compose configuration changes are not reflected; no recreation procedure is documented |
docker compose alpha watch |
A service’s build context; it can rebuild or refresh containers after file updates (reference) | Experimental; --no-up; --quiet (reference) |
No claim that it applies compose.yml changes or guarantees application-level results |
docker compose attach |
Local input, output, and error streams connected to a running service container (reference) | Detach keys, replica selection, optional STDIN, and signal proxying (reference) | No claim that it creates, rebuilds, or restarts a container |
docker compose bridge |
Compose files converted into another model (reference) | Conversion to Kubernetes manifests, Helm charts, or another model (reference) | No guarantee of complete, equivalent, or deployable output |
A quick decision example makes the boundaries clearer. If you changed an environment variable in compose.yml, restart will not apply it. If you changed application source inside a service’s build context, alpha watch is the command documented around that type of change. If you need to connect your terminal’s streams to an existing container, use attach. If you want Kubernetes-oriented output from a Compose file, examine bridge.
restart: operate on service containers
The command:
docker compose restart
restarts all stopped and running services. Adding service names narrows the operation to those services (Docker Compose restart reference):
docker compose restart web
Here, web identifies the service whose container is to be restarted. The command is not treating the Compose file as fresh configuration.
Two options adjust the restart operation. --no-deps prevents dependent services from being restarted, while --timeout specifies a shutdown timeout in seconds (Docker Compose restart reference). The supplied reference does not specify default timeout behavior.
The critical boundary is explicit: edits to compose.yml are not reflected after docker compose restart. Docker uses changed environment variables as its example; those values are not updated by restarting (Docker Compose restart reference).
The command is also distinct from a service restart policy. Docker points readers interested in policy configuration to the restart and restart_policy Compose settings rather than to this CLI operation (Docker Compose restart reference).
alpha watch: monitor the build context
The command:
docker compose alpha watch frontend
watches the specified service’s build context. Docker says it can rebuild or refresh containers when files are updated (Docker Compose alpha watch reference).
A build context and a Compose configuration file are not interchangeable concepts in this documentation. The watch reference describes changes to files in the build context. It does not say that editing compose.yml is handled as a configuration update. This is why alpha watch should not be treated as an answer to the separate question of applying changed Compose configuration.
The options also describe how watching begins and how its output appears. --no-up tells Compose not to build and start services before watching, while --quiet hides build output (Docker Compose alpha watch reference).
Most importantly, this command is experimental. Docker warns that its functionality or design may change between releases without notice, and that it may be removed entirely in a future release (Docker Compose alpha watch reference). The reference does not promise that every changed file is watched or that a rebuild or refresh will produce a particular application-level result.
attach: connect to a running container’s streams
docker compose attach connects local standard input, standard output, and standard error to a service’s running container (Docker Compose attach reference):
docker compose attach worker
This is a stream connection to an existing running container, not a build, restart, or configuration operation.
The options refine that connection. --detach-keys changes the key sequence used to detach. --index chooses a container when the service has multiple replicas. --no-stdin leaves standard input unattached. --sig-proxy, which defaults to true, controls whether received signals are proxied to the process (Docker Compose attach reference).
That final option supports a narrow conclusion about proxying signals. It does not establish how a particular application or process will respond to them.
bridge: convert the Compose model
docker compose bridge takes Compose files into a conversion workflow rather than operating on running service containers. Docker describes the command as converting Compose files into another model (Docker Compose bridge reference).
Its convert subcommand names Kubernetes manifests, Helm charts, and another model as possible conversion targets. The command group also provides transformations for managing transformation images (Docker Compose bridge reference).
These descriptions establish the conversion target, not the fidelity of the result. The supplied reference does not promise that generated output preserves every Compose behavior, completely represents every workload, or can be deployed without further evaluation.
Which command reflects changed Compose configuration?
Within these four references, none is documented as the command that applies changed Compose configuration. restart is expressly ruled out: changes to compose.yml are not reflected after restarting (Docker Compose restart reference).
The other commands address different objects: build-context updates, a running container’s streams, and model conversion. If applying compose.yml edits is the actual goal, consult the current documentation for Compose lifecycle commands. These sources do not establish a container-recreation workflow, so this article does not infer one.
This comparison is based only on the supplied Docker documentation retrieved October 26, 2026. No hands-on test, performance measurement, deployment assessment, or application-level reload test was performed.
No comments yet