Docker Contexts (platform admin)
A context is a Docker endpoint the platform drives—the shared platform pool, or a customer's own BYO cluster. Whether it builds images, runs customer services, or both, is a property of the context itself, so one screen defines them all. It lives under Admin → Docker Contexts and requires the platform-admin role.
Roles
Each context is used for one or both of:
| Role | What it means |
|---|---|
| Builds | Image builds run here, as one-shot Swarm tasks. |
| Runtime | Customer services run here. |
A context with neither role has a configuration, but sits parked—legitimate while someone is setting one up.
A new install's platform pool arrives with both roles. That's the one context seeded with Builds rather than given it by hand:
| Context | Starts as | Why |
|---|---|---|
| The platform pool that creates an install | Runtime + Builds | The platform has to be able to build on day one. Without it every uploaded bundle sits at pending and Admin → Status opens red on build, a state nobody should have to talk an install out of. |
| Anything you add on this screen, platform pool or customer cluster | Runtime only | The column defaults to runtime alone and the form follows it. For a customer cluster that's also a trust boundary—see below—so Builds there stays a deliberate tick. |
The pool's grant is a migration (Version20260814124059), not a change to the column
default, and it's conditional: it grants the role only where no context anywhere
already carries it. An install that named a dedicated builder keeps that builder. This
fixes an install that can't build. It doesn't overrule one that can.
Think before ticking Builds on a customer cluster. A build runs with the platform's own registry credentials, mounted as a Swarm secret, and pulls base images through them—so a context you grant the role to can see material beyond its own tenant's. Platform contexts are preferred for builds and take the work whenever one is reachable; a customer cluster with the role only ever picks up what nothing else can. Grant it to clusters you'd trust with the credentials.
The other fields
- Endpoint—the manager API endpoint (
tcp+TLS) or SSH target. The platform pool in development is the local socket,unix:///var/run/docker.sock. - Public address—the hostname or IP that clients outside the cluster connect
to for a service published on a raw port. Give a hostname or an IP, no scheme and
no port. Easy to confuse with the Endpoint field described earlier. It's the
opposite direction: the endpoint is where the platform reaches the daemon, and
this is where a customer's users reach a customer's service. Nothing can work it
out for you. That's why it's a field. The endpoint is routinely a socket or a
private address. A node's hostname is what the node calls itself, not what your
Domain Name System (DNS) or load balancer points at it. Leave it blank
if there is none, and the platform reports the address as unknown rather than
guessing. That's the answer an application gets when it asks
GET /cli/applications/{slug}/endpoints. Applications that speak HTTP don't need it—they answer on a name the edge assigns them. - Owner—leave as the platform pool for infrastructure this platform runs. Pick an organization for a customer Bring Your Own (BYO) cluster. This also decides the context's kind.
- Status—whether the endpoint is currently reachable. Not a field you set: it
is measured. The endpoint is probed when you save the context, again on every
RECONCILE_INTERVAL_SECONDStick, and on demand from Check now on the context's own page. An unreachable context is probed along with the rest, so one that comes back recovers by itself. - Credential—client cert/key/CA bundle or SSH key. Stored encrypted, never rendered back; leaving it blank on edit keeps the stored one.
A context's own page
Opening a context probes it live—a GET writes nothing, so this is always the truth right now, not the last scheduled check. Check now re-probes on demand for the same reason.
Capacity is the context's own promise-against-measurement, the same figures the estate topology rolls up across every context at once. Topology is the live picture underneath it: what arrives from the internet, what routes it, which container answers, and on which machine. It loads on demand, because every box on it costs a live Engine API call. So it never sits in front of the "Check now" button somebody actually opened the page to press.
Deleting a context
Soft-deleted, and it asks first—the row disappears from the list, but the history it attached to (revisions that ran here) stays unrewritten:
