Apelora v0.1.0-alpha.9

Upgrading from v0.1.0-alpha.8

• Migration 0036 runs at start (it allows the new update kind of application operation).
• Deploying a version that changes a stateless module's image or settings now replaces its running replicas one at a time (each new one healthy before the old one goes); before, they were kept as they were. Singleton and stateful modules are still kept. Deploying the same version again changes nothing.
• New worker settings, with defaults: APELORA_UPDATE_HEALTHY_SECS (20), APELORA_UPDATE_TIMEOUT_SECS (300), APELORA_UPDATE_DRAIN_SECS (5).

Changes

• Rolling updates for stateless modules (issue #48, slice 2): deploying a version that changes a stateless module's image, settings or storage plans each running replica as replace and starts one application operation of kind update, which
• The sectors browser test scans for accessibility problems only after the dialog has closed: axe measured the fading heading as low contrast on every run; with the lesson (4522115)
• Bump the actions group across 1 directory with 2 updates (#56) (73c9e6f)
• Bump base64 from 0.22.1 to 0.23.1 (#55) (ea27e65)
• Bump the npm group with 3 updates (#53) (0072c0d)
• The remote desktop sequence diagram renders: a semicolon in a message ended the Mermaid statement (33016e8)
• Development builds can run the deployment worker inside the control plane on the same mock cluster (APELORA_MOCK_WORKER=1 with the dev-worker feature, refused against Incus and off in releases), so deployments made locally show their inst

Full list: v0.1.0-alpha.8...v0.1.0-alpha.9

Install

Follow Install Apelora Fabric with TAG=v0.1.0-alpha.9.

Check the downloads

sha256sum --check --ignore-missing SHA256SUMS-services-$ARCH SHA256SUMS-apps
gh attestation verify <archive> --repo Apelora/apelora-fabric

What this version has been tested against: what works today.

Apelora v0.1.0-alpha.11

Upgrading from v0.1.0-alpha.10

• No new migration. The Console and the Studio in this release already use the API below; only scripts and clients of your own need changes.
• This release changes the API in ways that break existing callers (issue #49), so the API is settled before the beta:

  • GET /api/v1/storage-pools is removed. GET /api/v1/storage/pools lists the same pools, with how full each one is.

  • The alert rule and alert channel lists answer {"items": [...]}, like every other list.

  • The dry run of a backup restore moves from GET …/backups/{backup}/restore to GET …/backups/{backup}/restoration. POST …/restore is unchanged.

  • A deletion that needs the name typed again takes the name as a query parameter instead of a JSON body: DELETE …?confirm=<name>. This applies to volumes, backups, directories, identity providers and sectors.

  • The audit log, the identity audit history and the alert history use one paging scheme, the same as jobs. Pass after=<next> from the previous page; a page carries next while older entries remain. before is gone, and a cursor that is not one is refused.

  • GET /api/v1/system reports incusTestedRelease (for example "7.0.2") instead of incusTestedWith.

  • A role's string identifier is key (builtin:<key> or custom:<uuid>).

  • Generated client functions are renamed. URLs are unchanged.

    Old function	New function
    list_machines	machines
    list_directories	directories
    list_join_tokens	join_tokens
    projects_list	projects
    projects	incus_projects
    machine_admission	preview_machine_admission
    cluster_upgrade	upgrade_cluster
    approve_request	approve_approval
    reject_request	reject_approval
    cancel_request	cancel_approval
    sessions	remote_sessions
    open_session	open_remote_session
    terminate_session	end_remote_session

  • Some path parameters are renamed. URLs are unchanged.

    • The MAAS machine parameter is systemId.
    • The Apelora project in /api/v1/identity/projects/{projectId}/environments is projectId. {project} now always means an Incus project name.
• In the generated types, a role grant's scope is Scope and an audit event's scope is AuditScope (organization, project and application ids). Before, both were free-form objects. The JSON is unchanged.
• The API document states its conventions at the top:
  • items lists, paged with after and next;
  • 201 for something created at once;
  • 202 for queued work, with how to follow it;
  • 204 when there is nothing to return;
  • confirm as a query parameter;
  • noun paths for checks that change nothing;
  • Idempotency-Key for requests that queue work;
  • one status per error code.

Changes

• API document (issue #49): a role grant's scope is the Scope schema and an audit event's scope is AuditScope (organization, project and application ids) instead of a free-form object; the objects that stay free-form say what they hold: a j
• Console: a wrong API token keeps saying it was not accepted. The sign-in check and the overview's own request are both refused for the same token; when the overview's refusal came first, the check's later one found the token already clear
• API breaking pass, part 6 (issue #49): the Apelora project an identity path names is {projectId} (/api/v1/identity/projects/{projectId}/environments), so {project} always means an Incus project name; the API document states its convention
• API breaking pass, part 5 (issue #49): operation names follow one pattern, so the generated client's functions do: lists are plural nouns (machines, directories, join_tokens; projects for Apelora's projects and incus_projects for the Incu
• API breaking pass, part 4 (issue #49): one paging scheme: the audit log, the identity audit history and the alert history take after (the previous page's next) and answer next while older entries remain, as jobs always did, instead of bef
• API breaking pass, part 3 (issue #49): a deletion that needs a name typed again takes it as the confirm query parameter instead of a JSON body, which some clients and proxies drop from a DELETE: volumes, backups, directories, identity pro
• API breaking pass, part 2 (issue #49): GET /api/v1/system reports incusTestedRelease, the plain Incus release this version was last tested with (from tested_release in upstream.lock.yaml), instead of incusTestedWith, the evidence note, wh
• API breaking pass, part 1 (issue #49), before the beta: GET /api/v1/storage-pools is removed (GET /api/v1/storage/pools lists the same pools with how full each is); the alert rule and channel lists answer items, like every other list; the
• The lab install uses v0.1.0-alpha.10 by default (4a6030b)

Full list: v0.1.0-alpha.10...v0.1.0-alpha.11

Install

Follow Install Apelora Fabric with TAG=v0.1.0-alpha.11.

Check the downloads

sha256sum --check --ignore-missing SHA256SUMS-services-$ARCH SHA256SUMS-apps
gh attestation verify <archive> --repo Apelora/apelora-fabric

What this version has been tested against: what works today.

Apelora v0.1.0-alpha.10

Upgrading from v0.1.0-alpha.9

• No new migration.
• Deploying a version that changes a singleton or stateful module's image or settings now rebuilds its instance in place (stopped, rebuilt from the new image, given the new settings, started again; name, server, address and volumes with their data are kept). Before, it was kept as it was. Such a deployment is refused with 409 confirmation_required unless the request carries "confirmDisruption": true; the Studio asks with a checkbox. A change to a module's volumes is still not applied.
• Error statuses an API client may check:
  • incus_unreachable is always 502 (operating an application answered 503).
  • provisioner_not_configured is always 503 (registering a MAAS machine answered 400).
  • The cap on a person's waiting approval requests answers too_many_open_requests (was too_many_requests); rate_limited is the only code for a request rate.
• The API document lists, for every operation, the error statuses it can answer and their codes.

Changes

• Bump utoipa from 5.5.0 to 6.0.0 (#54) (1171c5d)
• Answer a loop pool's size on join, and start the plane on a restored database. (#47) (9f5ca42)
• One error code, one status (issue #49): incus_unreachable is always 502 (operating an application answered 503) and provisioner_not_configured always 503 (registering a MAAS machine answered 400); the cap on a person's waiting approval re
• Every operation documents the error statuses its handler can answer and names their error codes (issue #49): a table of the codes each operation can return, by status, from the handlers and the helpers they call; the OpenAPI modifier adds
• Updating singleton and stateful modules (issue #48, slice 3): deploying a version that changes such a module's image or settings plans it as rebuild, and the update operation rebuilds it in place instead of recreating it (a new instance w
• The lab install uses v0.1.0-alpha.9 by default (d755ac3)

Full list: v0.1.0-alpha.9...v0.1.0-alpha.10

Install

Follow Install Apelora Fabric with TAG=v0.1.0-alpha.10.

Check the downloads

sha256sum --check --ignore-missing SHA256SUMS-services-$ARCH SHA256SUMS-apps
gh attestation verify <archive> --repo Apelora/apelora-fabric

What this version has been tested against: what works today.

Apelora v0.1.0-alpha.8

Changes

• The lab install uses v0.1.0-alpha.8 by default (d7a3df8)
• Sectors, slice 1 (ADR 0008): other Incus clusters are registered with their site, address and the name of their credentials (the identity's files stay on the control plane as APELORA_SECTOR__* paths; nothing secret is stored), read
• Remote desktop into Windows modules, off unless APELORA_RDP_GATEWAY=enabled: the session broker carries the RDP stream with the same permission (instance.desktop), approval, ticket, limits, re-checks and audit as a terminal; inside the gu
• Diagrams for the install topology, health and capacity, the proposed rolling update, alert delivery and sign-in; the sign-in design shows issue_session as it is and the local_accounts_disabled answer, alert retries mention their jitter, a
• Upgrade assistant: recording a member's package upgrade is refused while the member still reports an Incus release older than the pin or does not answer yet (a Blocked member is accepted: it already runs the new release), so the restore i
• Releasing: how to confirm the build attestations with a GitHub CLI older than 2.49, and the lesson behind it (ad8ec0f)
• Documentation gaps: the deployment design names the resize action and its job; the member maintenance runbook has a sequence diagram of evacuation and restore with the drain and the supervisor leaving moved replicas to Incus; the readines

Full list: v0.1.0-alpha.7...v0.1.0-alpha.8

Install

Follow Install Apelora Fabric with TAG=v0.1.0-alpha.8.

Check the downloads

sha256sum --check --ignore-missing SHA256SUMS-services-$ARCH SHA256SUMS-apps
gh attestation verify <archive> --repo Apelora/apelora-fabric

What this version has been tested against: what works today.

Apelora v0.1.0-alpha.7

Changes

• The lab install uses v0.1.0-alpha.7 by default (4945db3)
• The supervisor leaves a stopped replica that an evacuation or a restore moved (volatile.evacuate.origin) for Incus to start for 60 s before starting it itself, so the two starts no longer race and no needless restart is audited (issue #52
• The lab install uses v0.1.0-alpha.6 by default (dc57aec)

Full list: v0.1.0-alpha.6...v0.1.0-alpha.7

Install

Follow Install Apelora Fabric with TAG=v0.1.0-alpha.7.

Check the downloads

sha256sum --check --ignore-missing SHA256SUMS-services-$ARCH SHA256SUMS-apps
gh attestation verify <archive> --repo Apelora/apelora-fabric

What this version has been tested against: what works today.

Apelora v0.1.0-alpha.6

Upgrading from v0.1.0-alpha.5

The control plane adds one table at first start (instance_drains, migration 0034). Upgrade the control plane and the worker together:

• Evacuating or restoring a member now waits for the worker. Before Incus moves anything, the control plane queues a network.resync job per affected application and waits for it, at most APELORA_DRAIN_WAIT_SECS (default 30). A worker from an earlier version fails that job kind, so the wait runs out and the move goes ahead as before. APELORA_DRAIN_WAIT_SECS=0 turns the drain off.
• The evacuate and restore responses (POST /api/v1/cluster/members/{member}/evacuate and /restore) have a new field, drain, that says what was done first. The audit entries carry it too.
• The worker syncs an application's networks more often: whenever its replicas move, start or stop, or a member goes down or comes back.

Known limitations: a replica that moved back to a restored member was unreachable from the other members for at least 11 s in one of five lab runs (issue #51). During an evacuation, the supervisor can start a replica that Incus is still moving (issue #52).

Changes

• Evacuating or restoring a member first takes the replicas Incus will move out of their service addresses, and a moved replica rejoins once it runs and has its address, so requests no longer go to a replica that is stopping (issue #50); th
• The lab install uses v0.1.0-alpha.5 by default (8913aeb)

Full list: v0.1.0-alpha.5...v0.1.0-alpha.6

Install

Follow Install Apelora Fabric with TAG=v0.1.0-alpha.6.

Check the downloads

sha256sum --check --ignore-missing SHA256SUMS-services-$ARCH SHA256SUMS-apps
gh attestation verify <archive> --repo Apelora/apelora-fabric

What this version has been tested against: what works today.

Apelora v0.1.0-alpha.5

Changes

• Valkey, Uptime Kuma and Blackbox exporter are deployable, and module settings either reach the software or say they do not: an OCI runtime turns number, choice and on/off settings into its command and others into its environment (Valkey's
• The health page's retry test keeps the servers stub failing until its own retry, so a poll in between no longer removes the button it clicks (335d582)
• API descriptions say what a field means instead of citing ADR numbers or repository paths, and the error body documents the currentVersion a draft conflict returns (issue #49) (0d96233)
• The API document lists the refusals any request can get on every operation (429 with Retry-After, and 401 outside the public routes) and says what each error status means (issue #49) (b24b157)
• Every timestamp in the API document says it is a date-time (format: date-time on the 100 …At fields), and the mock's snapshot times and join token expiry are real timestamps (issue #49) (c99540e)
• A deployed module's properties in the Studio list where each replica runs and its addresses, read only while they are open so the status every canvas polls stays one listing; a failed read says so instead of looking like no address (fb22d
• The lab install uses v0.1.0-alpha.4 by default (fa5c942)

Full list: v0.1.0-alpha.4...v0.1.0-alpha.5

Install

Follow Install Apelora Fabric with TAG=v0.1.0-alpha.5.

Check the downloads

sha256sum --check --ignore-missing SHA256SUMS-services-$ARCH SHA256SUMS-apps
gh attestation verify <archive> --repo Apelora/apelora-fabric

What this version has been tested against: what works today.

Apelora v0.1.0-alpha.4

Upgrading from v0.1.0-alpha.3

No database changes: replace the files and restart the control plane and the worker. Check these before you upgrade:

• Removing someone from a group that holds roles now needs the right to revoke those roles, as revoking them directly does. group.manage alone is no longer enough.
• Outdated replicas. Instances record what they were built from only when they are created by this version. Instances created earlier are never shown as outdated in the deployment review; they are compared once they have been recreated.
• Application status (GET /api/v1/applications/{name}/status) may include a new field, trafficBlocked, while a cluster member is unreachable and Incus refuses load balancer changes. Clients that reject unknown fields need updating.

Known limitations: deploying a new version does not update running modules yet; remove the module and deploy it again to apply the design (issue #48). Evacuating a member can drop requests for about ten seconds (issue #50).

Changes

• Member failure evidence: Incus refuses load balancer changes in every run, and whether OVN's health check still takes the dead replica out varies, which explains the earlier drills that recovered (4b8353b)
• Lab: demo.sh checks that a stuck service says which member is unreachable and clears once it returns, counts only its own run's restarts, and never leaves a member evacuated; evacuation can drop requests for about ten seconds until the he
• Removing someone from a group that holds roles needs the right to revoke those roles, as revoking them directly does (f6a7651)
• The supervisor no longer starts a new replica that its create job is still starting, which was recorded as a needless restart right after a deployment (1770d42)
• Each new instance records what it was built from, and the deployment plan marks a running instance whose image, settings or storage the design now asks differently as outdated, with a warning that deploying does not update running modules
• When Incus refuses load balancer changes because a cluster member is unreachable, Apelora says so and names the member: in the failed network sync, the jobs-failing alert, the application's status (trafficBlocked), the Console's applicati
• Keycloak and Fedora use generic icons: their marks come with custom trademark terms (c5b0b49)
• Screenshots show the catalog as categories with counts (64dbdcd)
• Releases that change what an existing installation relies on get an upgrading section in their notes (c6b1664)

Full list: v0.1.0-alpha.3...v0.1.0-alpha.4

Install

Follow Install Apelora Fabric with TAG=v0.1.0-alpha.4.

Check the downloads

sha256sum --check --ignore-missing SHA256SUMS-services-$ARCH SHA256SUMS-apps
gh attestation verify <archive> --repo Apelora/apelora-fabric

What this version has been tested against: what works today.

Apelora v0.1.0-alpha.3

Upgrading from v0.1.0-alpha.2

The control plane updates its database at first start. Check these before you upgrade:

• Groups mapped to an identity provider or a directory now name their source. If exactly one identity provider and nothing else is configured, existing mappings are bound to it at first start. Otherwise they match nobody until a platform administrator chooses Set source… under Identity & Access → Groups. Directory groups are entered as their full DN.
• Adding someone to a group that holds roles now also needs role.assign and those roles, not only group.manage.
• Only people decide approvals. API tokens and service identities can no longer approve or reject a request.
• An existing Incus project is adopted by an environment only when it carries that environment's marker or a platform administrator named it.
• Alert webhooks to loopback or link-local addresses are refused. A channel's status gives a short reason; the details are in the worker log.
• Terminal sessions end when the sign-in that opened them ends (sign-out, password reset).
• Behind a trusted proxy, the sign-in limit and the recorded addresses use the client's own address.

Known limitation: while a cluster member is offline, Incus 7.0 refuses every load balancer change, so a substitute replica gets no traffic until the member returns or is removed. See the Member failure runbook.

Changes

• The lab install uses v0.1.0-alpha.3 by default (9f3e3ee)
• The test through the screens also deletes the volumes its applications kept, and passes 10 of 10 on the test cluster with the security fixes and the grouped catalog in place; current-state lists today's test counts (68ef411)
• Module catalog as a two-level menu, with 59 more open-source modules (847b92c)
• Describe the hardened identity, tenancy, session and webhook behaviour (c4d80d2)
• Tie external group mappings to their identity provider or directory (ddd39ea)
• Neutralise formula characters after leading white space in the audit CSV export (20f19fb)
• Keep alert webhooks off this computer and link-local addresses, and report coarse reasons (d735510)
• Parse identity-provider URLs before allowing plain http, and follow no redirects (da31f7c)
• Keep Incus's address out of transport error messages (b66784c)
• Refuse owner labels and network attachments set by callers (06880db)
• Adopt an existing Incus project only when it is the environment's own or a platform administrator named it (21c3c79)
• End a terminal session when the sign-in that opened it ends (7c00c70)
• Key the sign-in limit and recorded addresses on the client behind trusted proxies (eee0582)
• Approvals are decided only by signed-in people (ddd3a47)
• Check the escalation guard when a member is added to a group (40fd27b)
• End-to-end test through the screens on the test cluster (scripts/test-cluster/ui-e2e.sh, tests/lab): an administrator signs in and sets up a local account with a role, that person signs in to the Studio with a password, builds application
• A deployed application's canvas shows what runs however it is opened (a link, a reload, the next day), not only right after deploying in the same page; the Console's application details link each instance to its page (addresses, disks, lo
• Member failure: Incus refuses every load balancer change while a member is unreachable, so a substitute gets no traffic until the member returns or is force-removed; the runbook says what to do, the lab run of 2026-10-25 is recorded, and
• Releases: alpha, beta and rc tags publish at once as pre-releases (final versions stay drafts), only from a commit on main whose CI passed, with notes from the commits since the previous tag and a build-provenance attestation for every ar
• Local development addresses as code, not links (3dbc80b)
• A control plane without a database answers database_not_configured (store_unavailable stays for a database that is unreachable), and the Console says what is missing instead of offering a retry that cannot work; sessions and permissions d
• Reader guides and runbooks as clean steps: what each page achieves, numbered commands with what success looks like, and one plain limits list; test evidence, dates and issue numbers moved to current-state and the lab guide. Corrected: eva
• Refuse instance settings outside an allow-list from callers (resources, live migration, environment and user keys), so a deploy right cannot become host access on an unrestricted project; lab VMs no longer forward ports bound to the guest
• Install v0.1.0-alpha.2 instead of the October draft (#46) (0923d95)

Full list: v0.1.0-alpha.2...v0.1.0-alpha.3

Install

Follow Install Apelora Fabric with TAG=v0.1.0-alpha.3.

Check the downloads

sha256sum --check --ignore-missing SHA256SUMS-services-$ARCH SHA256SUMS-apps
gh attestation verify <archive> --repo Apelora/apelora-fabric

What this version has been tested against: what works today.

Apelora v0.1.0-alpha.2

Second alpha, cut from main (bf323a7). The control plane, the worker, Studio and Fabric Console are this same commit.

Use this package instead of v0.1.0-alpha.1. That October draft has no sign-in page and no GET /api/v1/sign-in. This one does. v0.1.0-alpha.1 stays unpublished.

This is not a production-host install. Issue #17 stays open until a published release has been run on a production host.

Verify the checksums before installing.