Skip to main content

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.