fleetwide embed
Builds the supervisor into your image. With --api-key and --app it reads the app's runtime, sync paths and assets from the console and makes those paths writable for the image's USER; the image records which console and app it belongs to, and refuses a key for another app. From a built image to a running, updating container:
- Register the app in the console with runtime embedded and the directories a release may change (enhanced security mode). Create an API token under Settings → Security.
- Embed and push. Point fleetwide embed at the image you already have and at a destination tag; --push sends the result to your registry, --output writes a tarball instead.
- Publish the pushed tag as a release of the app and promote it to a channel, like any other release. Every release of an embedded app is an image made this way.
- Run it with a deployment's FLEETWIDE_KEY, as the image's own user, with no added capabilities. It enrolls, syncs the assigned release and starts your app; later releases update the declared directories in place.
# one image with the supervisor inside: runs as your image's USER, no extra privileges
fleetwide embed --app my-app --api-key $FLEETWIDE_API_KEY \
--image ghcr.io/acme/my-app:1.4.2 --start latest \
--tag ghcr.io/acme/my-app-fw:1.4.2 --pushdocker run -d --name my-app --restart unless-stopped \
--user 101 --cap-drop ALL --security-opt no-new-privileges \
-v my-app-state:/var/lib/fleetwide \
-e FLEETWIDE_KEY=fw1.… \
-p 8080:8080 ghcr.io/acme/my-app-fw:1.4.2--start embedded runs the application immediately, which works with no network, and syncs once the console answers. --start latest waits for the assigned release first, so a fresh container never serves a stale one; if the console stays unreachable past --start-timeout, fallback starts what is in the image and strict stays down with ready and live at 503. The enrollment key is never embedded: pass FLEETWIDE_KEY at run time.
All flags:
--api-key TOKEN API token from Settings → Security (env FLEETWIDE_API_KEY)
--app KEY the app to embed for: brings its runtime, sync paths and assets
--console URL only for a self-hosted console (default https://fleetwide.io; env FLEETWIDE_CONSOLE)
--release ID which release to embed (default: what the stable channel points at)
--image REF source image in a registry (tag or digest)
--local-image NAME source image in the local Docker daemon
--dockerfile PATH build it first (--context DIR, --build-arg K=V, --build-tag NAME)
--start embedded|latest embedded: run now, sync when the console answers
latest: enroll, sync the assigned release, then start
--start-fallback fallback|strict console unreachable past the timeout (default fallback)
--start-timeout 60s
--tag DEST destination reference (required)
--push push it there
--output FILE.tar write a docker-load tarball instead, or as well
--platform os/arch[,…] default: this machine's; several need --push
--all-platforms every platform the source image has
--profile slim|telemetry|developer which supervisor goes in (default slim)
--supervisor-image REF take the supervisor from this image instead of the published one
--version LABEL release version label, recorded in the image
--verify run the result here and check the app starts
--console-ca FILE PEM of a self-hosted console's CA
--insecure-tls, --plain-http local testing only
--json machine-readable summaryWithout --api-key, --app is only a label and nothing is declared: the supervisor image is layered onto yours and the result runs as root with the whole image under supervision, which is the supervisor runtime in one image. Useful as a fallback image that starts your app offline. fleetwide bake is the same command under its older name.
# without --api-key the app is only a label: the supervisor image is layered onto yours,
# nothing is declared, and the result runs as root with the whole image under supervision
fleetwide embed --app my-app --image ghcr.io/acme/my-app:1.4.2 \
--tag ghcr.io/acme/my-app-fw:1.4.2 --push