Controllers
A controller is the piece of PlatformSmith that runs on your infrastructure. It is what makes "bring your own compute" true rather than a slogan.
What it does
- Connects outbound to PlatformSmith over a WebSocket and stays connected. You never open an inbound port, and PlatformSmith never dials into your network.
- Receives instructions — start this container, stop that one — and carries them out against the local Docker daemon or Kubernetes API.
- Reports back: container state, readiness, logs, and its own version.
It registers itself
You do not create a controller record and then go find it. You run the install command from step 2, the controller starts, dials home, and registers itself against the environment named in its configuration. Registration is how the setup checklist knows to move on.
A controller self-reports its version at registration, so the version PlatformSmith shows you is what is actually running, not what you think you deployed.
How much you will see of it
That depends entirely on your topology:
- On a Docker host you manage — you will see it. It is a container on your machine; you restarted it, you can read its logs, and when it goes away your environment stops accepting launches.
- On Kubernetes — it is a workload the manifest installed. You see it the way you see any other workload in the cluster.
- On a hosted environment somebody else set up for you — you may never see one at all. It is just a green dot on the environment.
When one goes offline
An environment whose controller is disconnected cannot start anything, and the launcher says so rather than queueing forever. Containers that were already running keep running — they reconnect to the controller when it comes back.
The usual causes, in order of likelihood: the host went to sleep or was rebooted, the container was removed, the network path to PlatformSmith closed, or the workspace token was rotated.