Fadebox 1.1

The 1.1 line: fadebox/fadebox:1.1 follows its newest release, and the 1.1 docs describe every release on it. Moving between releases is covered in Upgrading.

1.1.5 — 2026-09-10

See what a runtime is costing. The runtimes list now shows two bars per host, CPU and memory used of its own capacity, and an instance's status shows the same per container — 0.42 cores · 312 MiB / 2 GiB — with the instance's managed volumes below them. fadebox runtime list gains CPU and MEMORY columns. The instances-per-runtime cap counts instances; this says what they actually cost, which is the number you want before putting another one on a host. Everything is read from each daemon on a timer and held in memory — no page waits on Docker, and nothing is stored — so a dash means not observed yet rather than zero, and CPU needs two readings before it says anything. There is no history: these are current readings, not a time series. See What a runtime is costing and Runtime usage to tune or switch off either pass.

Read a catalog entry before importing it. Details on a catalog card opens the entry itself — the Compose it deploys, the files it injects, its version, image and pairing — read-only, with its own linkable address. Until now the only way to see an entry's contents was to import a copy you might not want, and in a project scope may not be allowed to create. A template's catalog badge now links back to the entry it came from and names the source, entry and imported version on hover; if the entry is gone the sheet says so, since an import is a copy and the template keeps working. See The catalog.

Clearer catalog administration in a project. Global sources and the bundled catalog appear in a project's source list for their status and entry counts, and now say administered globally instead of leaving an empty gap where a maintainer's own sources have controls. See Sources for one project.

Fixed. The Service Templates list no longer scrolls sideways: the image column takes the leftover width and truncates a long registry reference (full value on hover), the others hug their content, and Created steps aside on a narrow window. The drawers that show container logs are wider, so a long log line no longer wraps into three.

Upgrade notes. None: no schema change, and the ingress stack is unchanged. Usage collection starts on its own and needs nothing configured. For API clients, GET /api/runtimes entries carry a nullable usage, GET /api/runtimes/{name}/usage is new (its container rows narrowed to the projects the caller can see), an instance's status carries volumesBytes and per-container cpuCores, memoryUsageBytes, memoryLimitBytes and rootfsRwBytes, and a catalog entry's payload now also carries source, tags and requires.

1.1.4 — 2026-09-09

HTTPS without a certificate authority. A runtime's new HTTPS certificate setting chooses how the managed ingress stack certifies HTTPS: the Let's Encrypt wildcard as before, or Traefik's own self-signed default certificate — for an internal or air-gapped host that has no public DNS to solve a challenge against but still wants deployed apps served as https://. Browsers warn on the self-signed one; that is the trade. See TLS.

The managed ingress stack follows the egress proxy. On a network that only reaches the internet through a proxy, the Traefik that Fadebox installs now inherits QUARKUS_PROXY_HOST, so Let's Encrypt is reachable, while its backends and the socket proxy stay direct. Nothing to configure; re-apply the stack after changing the proxy. See Egress proxy.

The ingress stack has its own dialog, and knows whether it is current. Install, update and remove moved out of the runtime edit form to an Ingress action on the runtimes list. The dialog says whether the running stack is up to date with the saved settings or outdated — read off the host itself, so a changed setting, a Fadebox upgrade or a changed proxy all show — and saving ingress settings ends by offering it. Saving never touches the running stack. See Setting it up.

Upgrade notes. One migration runs on startup, V007, adding the certificate mode to runtimes; existing runtimes keep Let's Encrypt. Every managed ingress stack installed by an earlier release reads as outdated once, because it carries no record of what it was created from: Update it at a convenient moment — the containers are replaced, issued certificates are kept — and it reads as up to date from then on. For API clients, GET and POST /api/runtimes/{name}/ingress now return { state, containers } instead of a bare list of containers.

1.1.3 — 2026-09-08

An instance's runtime is a choice, and can be changed. The Runtime field is always offered when an instance is created, pre-filled with what the server would pick — local when it is enabled and available to the project, otherwise the project's only enabled runtime — and left for you when several qualify; a request that names none in that case is refused with the candidates rather than guessed. An instance whose runtime has since been disabled says so on its card and cannot deploy or reset there; Move takes a stopped or draft instance to another runtime, from the card or fadebox instance move <slug> --runtime <runtime>. A move keeps the name, the overrides and the history, not the data: volumes stay on the old daemon and the new runtime has its own ingress domain, so the next deploy comes up on new URLs and empty. See Runtime. Before this, a free-tier installation that switched local off in favour of one remote runtime created instances that could never deploy.

Catalog cards say what the software is. Beside the entry's own version, a card shows the tag of the image its main service runs (18-alpine, 26.7), with the full reference on hover; and the pairs with badge names the first provider and counts the rest instead of running off the card. See The catalog.

Fixed. Signing out no longer crashes the web interface before the browser reaches the identity provider's sign-out page.

Upgrade notes. None: no schema change, and the ingress stack is unchanged. For API clients, instances gain runtimeEnabled, catalog entries gain image, and PUT /api/projects/{project}/environments/{env}/instances/{slug}/runtime is new; every existing call answers as before. Quarkus moved to 3.39.2.

1.1.2 — 2026-09-07

A project's catalog is its maintainers'. A maintainer registers, syncs, switches and removes the project's own catalog sources, imports entries into the project, and creates, edits and deletes the project's own templates — no global role needed. Test runs stay with the global template roles. Over MCP, the catalog and template tools take an optional project for the same.

Unsafe template configuration is refused by default. A project template that declares a privileged container, a bind mount, a host port binding or a traefik./fadebox. label is refused when saved or imported, unless an administrator allows it under Project → Settings → Template Safety. Global templates only warn. Validation lists such findings under unsafe. See Unsafe configuration.

The Members page lists each person once, with every role they hold and the group each comes from, and searches by username or email. The members endpoint (GET /api/projects/{project}/members) now answers one row per user with a roles list instead of one row per grant.

Upgrade notes. Nothing saved or running is checked against the new rule: it applies when a project template is next saved or imported, and the project's switch is off until an administrator turns it on. The members endpoint's changed row shape is the only API change; the web interface is its only shipped client.

1.1.1 — 2026-09-05

Every project comes with its groups. A project now owns a group per role from the start — acme-viewers, acme-deployers, acme-editors and acme-maintainers for a project acme — shown under Access → Groups with a Project group badge. They take claim mappings, so a directory group maps straight onto one role in one project, and they cannot be deleted by hand or lose their grant; they go with the project. Creating a group under a name a project owns is refused, and so is creating a project whose group names a hand-made group already holds. See Access control.

Fixed. Opening a group under Access → Groups no longer switches the sidebar to project scope.

Upgrade notes. On first start, every existing project gains the project groups it lacks. A hand-made group that already holds one of those names is left alone and logged; rename or delete it, and the project group appears at the next start.

1.1.0 — 2026-09-05

Deployers can vary an instance. An environment names the services a deployer may change — their variables, their image tag, or both — and whoever creates or redeploys an instance sets values on those services and no others. Everything else stays as the definition says. See What deployers may change and Overrides.

Reset an instance. Removes its containers, network and volumes, then deploys it again with the same values — start over without losing the name or the URL. A deployer action, behind a confirmation; fadebox instance reset in the CLI. See Reset.

Deploy history. Every deploy and reset records what it actually ran — the image per service after every resolution pass, and the values applied — so an instance card stays truthful after the branch a git reference points at has moved. See Deploy history.

Catalog imports through your own registry. With a system image registry configured, the import dialog offers to pull an entry's Docker Hub images from it, and shows exactly what it would rewrite before you accept. The choice is kept, so Update from catalog does not revert it. See Pulling the entry's images from your own registry.

One egress proxy setting. On a network that only reaches out through a proxy, QUARKUS_PROXY_HOST now covers all three outbound paths — OIDC discovery, the OIDC client's own calls, and git. See Egress proxy.

The runtime list shows what you can use. It is narrowed to the runtimes your projects may deploy onto; a global admin still sees them all, and the admin-only fields stay admin-only. See Project roles.

Installation isolation is always on. Several Fadebox installations sharing one Docker daemon no longer need a setting to keep out of each other's containers: every container is stamped with its installation's own id. Containers deployed by an earlier version, before stamping, still count as yours.

The bundled catalog moved on. New and updated entries from the catalog's master as of 2026-09-04 — what changed.

A fix. Two instances whose names happened to join into the same namespace could remove each other's containers on deploy; a deploy now refuses to touch a container that is not its own.

Upgrade notes. Three migrations run on startup — V003 (which services an environment opens to deployers), V004 (the deploy record) and V005 (a template's registry choice). The FADEBOX_INSTALLATION_ID setting is gone; if you had set it, remove it — isolation now keys on the installation's own id, and the setting is ignored. To take the minor, change the compose file's image from fadebox/fadebox:1.0 to fadebox/fadebox:1.1; the 1.0 tag keeps following 1.0.x patches and never moves to 1.1.