Fadebox 1.2
The 1.2 line: fadebox/fadebox:1.2 follows its newest release, and the
1.2 docs describe every release on it. Moving between releases is covered in
Upgrading.
1.2.1 — 2026-09-12
Fixed. Switching straight from one project to another in the project switcher froze the whole web interface. The project's Environments page stays open across the switch, and while the new project's environments were still loading its table was handed a fresh empty list on every render, which the table answered with a state change of its own — a loop that never gave the browser back. Only a switch between two projects hit it; entering a project from All projects never did. The page now hands the table one list until the real one arrives.
Upgrade notes. None.
1.2.0 — 2026-09-11
A redeploy restarts only what changed. Until now deploying an instance that was already running removed every container and started the stack from nothing, so bumping one service's tag restarted the Postgres, the Keycloak and everything else with it — and a bad tag on the third of five services failed after the first two had already been torn down. A deploy now converges the running stack: it creates what is missing, recreates what changed — a different configuration, an image that moved under its tag, a container Fadebox would not call healthy — keeps the rest, and removes what the environment no longer names. Images are pulled before anything is touched, so a tag that does not exist fails the deploy with the instance still running. A service is a unit, so its init helpers and sidecars restart with it; nothing cascades to the services that merely depend on it. Each attempt records what it did — the status panel reads restarted backend · kept 4 — and Reset still replaces everything, volumes included. See Redeploy restarts only what changed.
Unused images can be reclaimed. Image layers are the largest thing on most runtime disks and
nothing in Fadebox removed one: per-PR tags, nightly :dev rebuilds and deleted environments left
them there forever, while docker image prune -a by hand takes the cache a stopped instance would
redeploy from and everything an air-gapped host can never pull again. Every image on a runtime is
now classified — in use, wanted, unused, foreign — and only the unused ones are offered.
An admin removes them for the whole host from Resources on host, with foreign images behind an
explicit tick and a confirmation; a deployer removes, from the project's Environments page, only
what no other project ever pulled; and a per-runtime image retention setting, off by default,
removes them on a timer. Nothing younger than five minutes is ever touched, so a reclaim cannot
race a deploy, and every figure is unique bytes — what actually comes back. See
Images.
The dashboard shows what the fleet is costing. CPU and memory as bands per runtime against the fleet's capacity, and a bar per daemon of what it stores — images, volumes, containers. The charts are the open page's own memory: they fill as the page watches, one point per sweep, and a reload starts the window over. Fadebox still stores no usage history by design. See Across the fleet.
Prometheus can scrape it. For history that outlives a page, GET /api/metrics publishes the
same readings as fadebox_* series — per runtime, per container, per instance, plus instance
counts by lifecycle status — beside what Micrometer knows about the Fadebox process itself. A
scrape renders the last sweep and never calls a daemon, so a hung host shows up as
fadebox_runtime_up 0 rather than as a hung scrape. Switching the exporter on is an Enterprise
act and the only gated part: the scrape answers on every tier once it is on, switching it off is
never gated, and an exporter enabled under a license goes on answering after that license lapses.
See Prometheus metrics.
An agent can run the estate, not just the environments. The MCP registry grew from 46 tools to
82. New: projects and their access (create a project, grant and revoke roles, directly or by
group), runtimes and instance time (list_runtimes with what each host has room for,
extend_instance, move_instance, deploy history), environment configuration (protection, start
waves, injected files), the catalogue-source lifecycle (read, update, enable, delete), git
repositories and registry logins, the audit log, and update_template_from_catalog so a copy can
follow the entry it came from. What stays human-only is stated rather than left to be discovered:
API keys, identity administration, runtime registration and the license. See
What the agent can do and
What has no tool at all.
Sessions last thirty minutes, and now say so. Users were being signed out at unpredictable
times, and both sign-in paths had their own reason. A form session enforced thirty minutes while
telling the browser to keep the cookie for a day, so an idle tab came back to a 401 rather than
to a clean sign-in page; an SSO session was capped at the identity provider's ID token life-span
with no renewal, so a provider issuing the customary five-minute token signed everyone out every
five minutes. Both now hold one idle window of thirty minutes, slid forward by any request, with
SSO sessions renewed with the provider behind the scenes. Your provider's own session policy is
still the ceiling. See Sessions.
A service row says where it came from. On an environment page a service's template name is now a link to that template, and a template imported from a catalog carries a catalog badge linking to the entry it was copied from.
Fixed. On a Docker daemon shared by two Fadebox installations, the managed ingress stack's status, update and removal reached every installation's stack: a neighbour's stack could be reported as yours, read as outdated against your settings, and replaced by an update you approved on that basis. Each installation now sees and touches only its own. Signing out expired a cookie by the wrong name on any installation that had renamed the session cookie, leaving the session alive; it now expires the one the server actually set. Sheets, dialogs and drawers no longer freeze part-way open when the page is busy — their animations run on the compositor again.
Upgrade notes. One migration runs on startup, V008, adding image retention to runtimes;
existing runtimes get no retention, which means images are never removed on a timer. The first
redeploy of each instance after the upgrade recreates all of its containers — they carry no
configuration stamp for the new convergence to compare against — and every redeploy after that
restarts only what changed. The metrics exporter is off until an admin switches it on. The ingress
stack is unchanged and needs no reinstall. Anyone signed in through SSO who had been living with
constant sign-outs will notice them stop; nobody needs to change a setting for that. For API
clients: GET/PUT/DELETE /api/system/metrics-export and GET /api/metrics are new (admin);
so are GET/POST /api/runtimes/{name}/images[/reclaim] (admin) and
GET/POST /api/projects/{project}/images[/reclaim] (viewer to read, deployer to remove);
runtimes carry imageRetentionDays (null unchanged, 0 off, ≥ 1 days) and their usage carries
disk; a deploy record's resolved carries a per-container containers outcome map; an
environment service carries catalogSource, catalogId and templateGlobal; and an anonymous
call to a project's audit listing now answers 401 rather than 403.
Documentation. The 1.2 docs are the ones served by default, and the
1.0 and 1.1 docs are archived — still published for installations still running
those lines, and marked as no longer maintained.