How Fleetwide works

You publish a release. Every container that follows the channel pulls it, checks its own health and rolls back on its own. The part that does the work, the supervisor, runs inside the container: there is nothing to install on the host, no Docker socket to hand over and no cluster role to grant.

The supervisor is a small process that starts your application the way your image says to (entrypoint, command, user, environment), watches its health, and keeps it on the release the console assigns. It enrolls over mutually authenticated TLS with a deployment key, checks in on a schedule, and when the release changes it downloads only the image layers that changed and swaps them in during about the time of a restart. If the new release fails its health check, it puts the previous one back from its own cache.

There are two ways to run it. On the supervisor runtime your customer runs the Fleetwide supervisor image, which pulls your image and runs it as a whole. On the embedded runtime the supervisor is built into your own image with fleetwide embed, so there is one image, it runs as your image's own user, and it needs no capabilities; see enhanced security mode.

Either way there is no redeploy, no SSH and no pipeline to re-run, and your customer's own readiness and liveness probes keep working. The console has three parts under Run: Fleets, where releases reach containers; Monitoring, where every container's health, resources and metrics are in one place; and Fleetwide Proxy, which opens a container port to you at a URL with nothing exposed on the customer side.

The Overview is the live summary: fleets, apps and releases at a glance, rollouts in progress with how far each has reached, what needs attention, the last releases published and where they are promoted, and what is scheduled next.