2.1.2.5 Docker Context Switching

Docker context switching is the mechanism that lets a single Docker client maintain multiple named configurations — each pointing at a different daemon, local or remote — and switch between them without retyping connection details for every command.

Defining a Context

A context bundles the connection information needed to reach a particular daemon: where it is, and how to authenticate with it if needed. Once defined, it can be referred to by a short name instead of its full connection details.

docker context create staging --docker "host=ssh://deploy@staging-server.example.com"
docker context create production --docker "host=ssh://deploy@prod-server.example.com"

Switching the Active Context

Once contexts are defined, switching which daemon the client talks to by default is a single command, after which every subsequent command operates against that context's daemon until switched again.

docker context use staging
docker ps
docker context use production
docker ps

Each docker ps here lists containers on a different remote host, with the switch between them requiring no repeated connection details.

Running a Single Command Against a Specific Context

A context can also be specified for a single command without changing the default, which is useful for one-off operations against a host other than the currently active one.

docker --context staging logs myapp

Listing and Inspecting Available Contexts

Because multiple contexts can be defined, it is useful to confirm which one is currently active before issuing commands, especially in situations where running a command against the wrong host (for example, production instead of staging) would be consequential.

docker context ls
docker context inspect production

The output of docker context ls marks the currently active context, which is a useful habit to check before issuing commands that modify running containers.

Why Context Switching Matters

Context switching removes the need to either repeat full connection strings on every command or maintain separate shell scripts per environment, making it practical to manage several distinct Docker hosts — development, staging, production — from a single, consistently configured client.