Enhanced security mode

Clusters that forbid root (Pod Security restricted, OpenShift) cannot run the supervisor image, which writes your image over the container's filesystem. For those, build the supervisor into your image instead.

Register the app with runtime embedded and the directories updates may touch, your code and configuration, say /app and /etc/nginx/conf.d. fleetwide embed makes exactly those writable for your image's USER, adds the supervisor and keeps your entrypoint.

# 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 --push

The result runs with no elevated privileges and no capabilities, and every release updates those directories in place.

docker 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

securityContext:
  runAsNonRoot: true
  runAsUser: 101
  allowPrivilegeEscalation: false
  capabilities: { drop: ["ALL"] }
  seccompProfile: { type: RuntimeDefault }
# /var/lib/fleetwide: an emptyDir is fine; a PVC needs fsGroup: 0 or that uid

The trade: a release that changes anything outside the declared paths, a new base image, a patched library, cannot be applied in place. The container reports redeploy required, keeps serving what it has, and stays out of the rollout's arithmetic until your orchestrator gives it the new image. Every release of an embedded app is an image built by fleetwide embed.

Files the app writes under a declared path are removed at the next update. Declared paths are for code and configuration, not runtime data.