Fleet Commander
Problem
Running Twingate Connectors at scale is a manual chore. Operators have to pre-mint tokens, stand up seed connectors, watch load by hand, and add or remove capacity as demand shifts. When a connector goes unhealthy, someone has to notice and replace it. None of this scales gracefully, and the credential handling - static tokens minted ahead of time - is exactly what you want to avoid.
Approach
Built a containerized control plane that runs a continuous asynchronous control loop over the connector fleet. Each cycle it discovers managed Connector containers, collects load and liveness signals, auto-scales Remote Networks against demand, provisions new connectors when load stays sustained and high, drains them when demand falls off, and restarts or replaces any unhealthy instance. The Twingate GraphQL Admin API acts as the bookkeeping layer that creates and deletes the logical connector and mints its token; Fleet Commander actuates through the Docker socket, minting tokens dynamically at provision time rather than relying on anything pre-configured. It supports multiple compute backends - a single Docker host, AWS ECS, or Azure Container Instances - and emits structured JSON event logs plus Prometheus metrics for symmetric observability.
Outcome
Operators get hands-off connector scaling with no pre-minted tokens and no manually configured seed connectors. The fleet grows and shrinks on its own, self-heals unhealthy instances, and reports its state through Prometheus and JSON logs that drop straight into CloudWatch, Azure Monitor, or Datadog. Published as an example project under the Twingate-Solutions organization (Apache-2.0).