Oarbank 2.11.1

A fix release for 2.11.0. Module SDK: oarbank-sdk 1.8.0, unchanged. Coming from 2.10, read the
2.11.0 section as well.

Fixed

• A Mac node whose update trust was pinned before a package install has its update runner again. The macOS pkg
  made the update runner's state directory owner-only on every install, and update-trust --from-agent, finding the
  trust pinned already, left it so. The agent, which reads the trust's marker in that directory, then reported no
  update trust, and oarbank update plan skipped the node ("no update runner on it") while update-trust said the
  trust was pinned. Nodes pinned after their install were not affected. The pkg now leaves the directory traversable,
  and update-trust --from-agent with a trust pinned already, as well as every start of the update runner, sets the
  directory's modes and writes the marker again, so installing this release's pkg repairs an affected node. An agent
  that cannot read the directory now says so, with the command that repairs it, instead of "no update trust is
  pinned"; for an older Mac agent the plan names both causes and the fix.
• A Windows node's fleet update is no longer recorded as failed after it installed. The MSI installed the release,
  and its setup and the restarted launcher made the release's agent current and started it. The update runner then
  installed that agent again, and Windows refuses to replace the file of a running program, so the step failed with
  "the package's agent could not be made current: Access is denied. (os error 5)". The node ran the new release, but
  the rollout counted a failure against the ring and the runner tried to roll the node back. An agent build that is
  already installed is no longer written again, and a current that already names the release's agent counts as
  success. Renames that Windows refuses for a moment, while another process such as an antivirus scan has the file
  open, are retried for up to 30 s.
• A node set to containers = off or on_demand no longer starts its container VM when the agent starts. An
  agent with no kept containers mode (the first start after upgrading to 2.11.0, or a new node) took the default,
  always, and started its Colima VM (or WSL containers session) before the coordinator's first answer. It now starts
  nothing until that answer says the mode, and an always node then starts its runtime at once. A stop asked while the
  runtime is still starting (off arriving, the on-demand idle stop, a resize) now wins: the start stops the VM it
  brought up. Before, the VM came up anyway and kept running while the node reported containers disabled.
• oarbank on the PATH is the running coordinator's CLI after a coordinator self-update. The macOS pkg linked
  /usr/local/bin/oarbank and oarbank-setup into Oarbank Coordinator.app, and the deb and rpm linked /usr/bin/oarbank
  and oarbank-setup into /opt/oarbank/coordinator. A self-update installs its build under
  /Library/Oarbank/Coordinator (/opt/oarbank/coordinator-builds on Linux) and never changes the package, so after
  the fleet update to 2.11.0 the services ran 2.11.0 while oarbank was still 2.10.4 and refused the new options, such
  as oarbank node approve --state paused ("unrecognized arguments"). The commands on the PATH now run the build the
  services run (current there, which the self-update moves and a rollback moves back), and the package's own before
  setup, as the Windows MSI's oarbank.cmd already did. A coordinator installed from an earlier package gets this
  with its next package install; until then, run /Library/Oarbank/Coordinator/current/bin/oarbank
  (/opt/oarbank/coordinator-builds/current/bin/oarbank on Linux).

Oarbank 2.11.0

Module SDK: oarbank-sdk 1.8.0, which adds the cleanup stage (stages[].cleanup, requires.core >= 2.11). This
release says when a node runs its container VM and sizes it as set, approves a machine with what it starts as, deletes
what a module left on a node once it leaves, and fixes certification around running work, empty releases, update
trust on fresh nodes, session helpers across updates and retired nodes. Read Changes on upgrade below. Coming
from 2.10.3 or earlier, read the 2.10.4 section as well.

New

• Say when a node runs its container VM: containers = always, on_demand or off. Since 2.9 every node
  whose release has a module with sandbox containers started its Colima VM (or WSL containers session) and kept it,
  whether or not it ever got container work, holding 8 GB or more on small machines. The node, group or fleet setting
  containers (Settings → Containers; oarbank settings set containers on_demand --node mini) now decides. always
  is the default and keeps the old behaviour. on_demand, recommended where container work is occasional, keeps the
  runtime stopped until container work waits for the node: the coordinator tells one stopped node to start when the
  fleet's running runtimes have no room for the waiting work, and the agent stops it again after
  containers_idle_stop_s (600 s) without container work. A stopped VM holds no memory. off never runs it: the
  node reports its runtime disabled, takes no container work (its jobs explain CONTAINERS_DISABLED with the fix)
  and certifies only the stages that need no containers. A machine's managed policy may set it, tighten-only. On Linux,
  where the host's engine is not a VM, on_demand runs as always. Agents older than 2.11 ignore the setting, but
  the coordinator still keeps container work off a node set to off.
• Approve a machine with what it starts as. oarbank node approve and approve-code take --state paused,
  --module-off <module> (and --module-on), --set key=value (<module>:key=value for a module's own setting),
  --labels and --groups; the console's waiting card has Approve with options… with a review. They are written in
  the same step that creates the node and issues its certificate, so a machine that must run no work is never granted a
  job or a certification golden before you can pause it. A paused node, and a module turned off on a node, get no
  certification goldens.
• The same machine, reinstalled. For a waiting machine that looks like a known node but cannot prove it is,
  --adopt-settings-from <old node> (console: "This is the same machine: carry over its settings and retire the old
  record") carries the old node's settings, state, module switches, protection, update hold and pin, labels and groups
  over and retires the old record, in one audited step. You type the old node's name to confirm; it is refused while the
  old node is online and for a request that proves a node's key.
• Safer onboarding. The fleet settings new_node_state (active or paused) and new_node_modules (all or
  none) set what every new node starts as, a join code's automatic approvals included.
• When a module leaves a node, what it put there goes. A module's processes write only to its data directory, their
  work directories, the dataset cache and the container runtime, so the node deletes all of it without the module's
  help: its data directory, the cached datasets no other module there uses, and the container images it pulled that no
  other module uses. A module turned off on the node goes after the new setting module_retention_days (fleet, group
  or node; 7 days by default, 0 at once), and turning it back on in that time keeps everything. A module no longer in
  the node's release, or on a retired node, goes after at most a day. Before it deletes, the node runs the module's
  cleanup stage, if it declares one (oarbank-sdk 1.8, stages[].cleanup), so the module can release state outside the
  node; a failure is reported and the deletion goes ahead.
• oarbank module purge <module> --node N | --all deletes it at once (T2, previewed; --yes skips the question). It
  is refused on a node where the module is enabled; --all purges it where it is turned off. The node page has a
  Delete now button for each module leaving it.
• Per-module disk use. oarbank node show and the node page list what each module keeps on the node (its data
  directory, cached datasets and images) and, for a module that is leaving, when its data goes and why. oarbank explain node names MODULE_DATA_SCHEDULED, MODULE_CLEANUP_FAILED and DISK_CACHE_OVER_CAP; each deletion is a
  module_data_deleted event.
• The dataset cache is collected and capped. The node records which modules use each cached dataset. A dataset
  goes with the last module that used it, and one no module used (a prefetch, a cache from before this release) once
  it was not used for the retention, at least a day. disk_gb, declared before and enforced now, caps the cache: above
  it the least recently used datasets that no job on the node holds or waits for go first.
• oarbank-uninstall --purge and oarbank-node leave remove the container images the node's modules pulled into
  an engine outside the node's home (Docker on Linux) before they delete the home.

Fixed

• A node's installed package is its floor; an older agent-only channel build no longer takes it back. After the
  2.10.3 to 2.10.4 fleet update, nodes running 2.10.4 were sent back to the 2.10.3 build promoted earlier on the
  agent-only channel, and then sat staged for 2.10.4 without a go. A channel build older than the node's installed
  package, or the fleet release it last installed, is now never assigned. Starting a rollout retires older channel
  builds, and canary, promotion and rollback refuse them. The launcher refuses an older staged build. oarbank agent list, the Agent page and oarbank node show show the running build beside the package floor, and say when a channel
  build is superseded or a node runs below its package.
• Session helpers restart onto the installed agent after an update. A session helper could survive package updates
  and keep describing its person's processes to host protection with old code. A helper now reports its version, and
  the agent asks one of another version to exit so its supervisor starts the installed binary. Helpers too old for that
  are replaced by the package install itself: the macOS, deb and rpm postinstalls, and the Windows elevated helper.
  The heartbeat lists each helper's version, and the node shows PROTECTION_SESSION_HELPER_OUTDATED while one is not
  current.
• vm_mem_gb and vm_cpus size the container VM. The owner's settings never reached Colima, the WSL containers
  session or the Linux engine's budget, so every runtime got the RAM-based default (8 GB on a 24 GB Mac, whatever was
  set). The agent now makes its runtime at the configured size, within half the host's memory and its processors, and
  restarts an idle VM at the new size when the settings change or when it finds the VM running at another size. The
  containers pool follows the size (2 GB gives none). The node's line shows the configured size beside the running one.
• A machine whose node was retired joins as a new machine. A machine that enrolled again from a retired node's
  Tailscale device (reinstalled, with a new key) was taken for a re-enrolment of that node. The waiting card said
  "re-enrolment of" the retired node and that it proved the node's key, and approving it brought the retired record
  back, with its old settings. A join code that approves automatically did this with no one looking. A retired node is
  now never what a request is, by its key or by its Tailscale device, and is no lookalike: the request is a new node
  under the fleet's onboarding policy. --adopt-settings-from a retired node is refused (adopt_refused, "is
  retired") instead of answering that there is no such node. Naming the old node by its host name now finds that
  node, not the new node being approved under the same name. The waiting card says whether a re-enrolment proves the
  node's key or comes from its Tailscale device. A request already waiting is judged again when it is shown and
  approved, so it needs nothing after the upgrade.
• A platform no module runs on no longer waits for the owner's signature. With release signing on, a platform
  none of the enabled modules runs on (a Windows PC when the only module is macOS-only) got a release with no module
  that waited for the owner to sign it: its nodes never became ready, the console showed "1 release waiting for your
  signature" and the release_awaiting_owner alert opened, and every module change built that empty release again for
  another signature. The signature exists so nodes run only code the owner approved, and an empty release carries
  none, so it now needs no signature: oarbankd makes it current at once and its nodes are ready with no module. The
  agent installs an unsigned release only after checking it holds no module, no tool definition and no other file, and
  still refuses any release with module code that is not signed. After the upgrade, empty releases still waiting are
  retired, replaced and their alerts resolved; there is nothing to sign. Agents older than this change refuse the
  unsigned empty release until they update.
• A freshly installed node pins its update trust when it joins. The package pinned the fleet's owner keys at
  install time, before a fresh node had joined and had any, so oarbank update plan showed "no update trust is
  pinned" for it. Upgraded nodes were not affected. Joining as an administrator now leaves the pin pending: with
  oarbank-node join, the join window, a ma...

Oarbank 2.10.4

A fix release for 2.10.3. Module SDK: oarbank-sdk 1.7.0, unchanged; its runner protocol now spells out how a
runner's fault and retryable combine, which this release acts on. Coming from 2.8 or earlier, read the
2.10.3 and 2.9.0 sections as well.

Fixed

• A machine re-added to the tailnet keeps its node. Applying a tag in the Tailscale admin console makes a machine a
  new Tailscale device. The coordinator refused the node's certificate from there, and approving the agent's new
  enrollment made a second node with fleet defaults. The paused state, per-node module switches, caps, protection,
  labels and groups stayed on the old, offline record. The new enrollment's CSR is signed with the node's existing key,
  and the coordinator now recognises it. Approving it keeps the node id, settings and history, and moves the node to
  the new device. A machine that cannot prove a node's key but has a known node's host name still becomes a new node.
  The approval preview, oarbank status and the console say so and offer to retire the old record.
• Module readiness no longer fails when a node's container runtime is missing pieces. The readiness API and
  oarbank module ready returned an error for modules that need the containers pool; they now name each missing
  piece with the fix the agent reported.
• Missing container prerequisites are re-checked, and stale Colima instances recover. A runtime piece installed
  after the agent started is picked up within a minute, on a doctor run or on Re-detect, without a restart. A Colima
  instance left broken by a killed VM is force-stopped and started again, a bounded number of times, and a failed start
  is retried with a backoff instead of on every protection tick. A stopping agent stops its VMs.
• Probes and services run again when a module's tool grants change. A probe that ran before its host tool was
  resolved no longer stays undetected until its period ends.
• A job whose runner declares it can never succeed ends at once. fault: "job" (or exit 2 with failure.json) or
  retryable: false now fails the job immediately: it is not retried on other nodes and not quarantined.
  fault: "job" with retryable: true spends one of the stage's retries, as fault: "job" did before. The failure's
  reason, code and detail are kept and shown by oarbank job show, Explain, the campaign summary and the console, and
  modules receive them in campaign.tick and host.jobs.query. A golden job that ends this way fails the module's
  certification on that node.
• Protected processes are evaluated fail-safe without a session helper. On macOS a person's processes are listed
  and matched even when their session helper is not connected; facts that cannot be read count as holding, and usage
  that cannot be measured counts within bounded reservations. Linux covers inactive sessions and accounts whose helper
  went away the same way.
• Session helpers are served after an upgrade. The agent makes the helpers' socket directory when it is missing,
  keeps retrying to serve them, and reports when they are not served (PROTECTION_SESSION_HELPER_UNAVAILABLE, and a
  failing helpers row in oarbank-node doctor). The macOS package makes the directory on upgrade.
• Presence counts what a person is actually doing. On macOS a Screen Sharing viewer counts only while one is
  connected, not whenever the daemon runs. On Linux ssh logins are ignored, as on macOS. The why line names the signal
  that counted someone present.
• Apple silicon cores are classed by level name. Chips whose levels are named "Super" and "Performance" (with no
  efficiency cores) were given half their capacity for the second level; they now get full slots, and the why line and
  console name each level.
• max_slots is described as a CPU-slot budget, not a job count, and settings warn when it is below an enabled
  stage's resources.cpu. jobs limits how many jobs run at once.
• The macOS node and coordinator apps' settings window has a right margin.

New

• Open the console from another device. console_listen (Settings → Access) chooses where the console listens:
  localhost, tailscale, IP addresses or all. console_https set to tailscale serves the console over https on
  the machine's tailnet name through tailscale serve, so passkeys work from other devices.
• An account menu in the console header, with clearer password and sign-in help on the Access page.

Changes on upgrade

• Nodes that already re-enrolled as a second record before this release stay two records: set the new node's settings
  again, then retire the old one.
• On Macs whose CPU levels are named "Super" and "Performance", the node's slot count rises and its co-tenancy
  certificates are earned again once, since their hardware string changes.
• A setting of max_slots 1 meant to run one job at a time should become jobs 1.

Oarbank 2.10.3

2.10.0, 2.10.1 and 2.10.2 were not published. 2.10.2's macOS listener check connected immediately after
a simulated router reboot, before the fake gateway had restored its TCP forwarder. The check now waits up to
60 seconds for the exact service reply; a mapping that never recovers still fails the release checks.

2.10.1's release checks found a port-mapping failure: a listener that moved
back to an address it had mapped from before asked PCP with a new nonce, was refused, and NAT-PMP made a second
mapping beside the first. A listener now takes over what the journal holds for it whenever its address or settings
change, not only after a restart. A search of a million random runs then found four more rare ways one listener
could end up with two router mappings, or a mapping the node forgot. A releasing lease is renewed when its listener
is wanted again. A lost mapping is asked for again at its port. A renewal is journaled before it is sent. Each case
is a deterministic test now.

2.10.0 itself was not published because macOS fleet-update acceptance uncovered two failures. The acceptance script now
waits for the update runner's first result instead of exiting on an absent file. The updater gives macOS package tools a
.pkg filename for its verified cached package, so the system installer accepts it; digest and signature verification
still apply to those same bytes. Regression tests cover polling under errexit and pipefail, and package metadata
reads through the verified cache path.

The changes below ship in 2.10.3, including the 2.9.0 upgrade steps.

Module SDK: oarbank-sdk 1.7.0. This release lets fleet work earn beside the people who use the machines: modules
can accept connections from the internet, run long-lived daemons that are the work itself, and share a GPU with a
protected program at a measured, certified level. It also updates the whole fleet from the coordinator, with one click:
every node's full package and the coordinator itself, ring by ring, with automatic rollback. 2.9.0 was not published on
its own, so if you run 2.8, read the 2.9.0 section as well: its upgrade steps apply.

What's new

Fleet updates: every node's whole package, and the coordinator, from one place. Before 2.10 the coordinator could
replace only the agent binary on a node; the launcher, helpers, node app, service definitions and Python runtime
changed only when someone installed the node package on each machine, and the coordinator could not update itself
(docs/design/fleet-updates.md, D56–D62).

• One signed fleet release per version. oarbank-fleet-<version>.json (written by CI beside the release assets)
  lists every package, agent binary and coordinator build with its sha256. Import it with its assets (oarbank update import <dir>, oarbank update fetch <version>, or the console's Updates page), and in signing mode sign it once
  (oarbank update sign <version>).
• Full node package updates on macOS, Linux and Windows. The agent downloads and verifies the package, lets running
  jobs finish, and hands it to a root update runner that runs outside the agent's service (oarbank-launcher update-run, started by a launchd job, a systemd path unit, or the Windows helper as a detached copy). The runner
  verifies its own copy against owner keys pinned by root, installs it with the OS's tool (installer, msiexec,
  dpkg, rpm, or a tarball), and keeps the new version only once its agent has confirmed itself; otherwise it
  reinstalls the previous package.
• The coordinator updates itself, with a safety net. It snapshots its database and runs the new build's
  migrations on a copy first; a root runner then stops the services, keeps its own copy of the database, installs the
  new build beside the old one and starts it on probation (GET /v1/health). If it is not healthy within five minutes
  the old version and the database copy come back by themselves.
• Rollouts in rings. oarbank update start <version> (or Update fleet on the Updates page, with a preview of
  every ring) updates the coordinator first, then the canary, early and broad rings (update_ring), a node or
  two at a time (max_unavailable), each ring baked before the next. A failure halts the rollout and rolls back the
  nodes it moved; pause, resume, halt, rollback and skip are one click or command away. A node updates only
  while it is online, inside its update_window, not held or pinned elsewhere, with no protected phase on, and never
  ahead of the coordinator.
• Policy. update_auto (notify by default; on starts a rollout when a signed release is ready), holds and
  pins with a reason and an expiry (oarbank update hold|pin), and managed policy that may hold a machine or turn
  automatic updates off for it. The menu bar and tray say "Updating to …" and "Update failed: back on …".
• Invariants S29–S31 (oarbank verify) and the TLA+ model specs/OarbankRollout.tla check the slot rule, the ring
  order, the coordinator-first rule and the eligibility of every update.

Inbound listeners and port mapping. A module can accept TCP connections from the internet without ever holding a
socket: the node's agent owns the listener and relays each connection to the module's endpoint service or workload.

• A listener opens only when the module version's [sandbox].net.inbound grant is approved, you assign it to the node
  (oarbank listener set <node> <module>/<listener>, operation listeners.configure; in signing mode the node applies
  it only after oarbank node sign <node>), the module runs there, and no kill switch or managed policy forbids it.
  A compromised coordinator cannot open a port.
• The agent maps its own ports on the router with PCP, NAT-PMP or UPnP IGD (v1 and v2): short leases renewed early, a
  journal written before every request, every mapping verified, and re-mapping after a router reboot, a new public
  address, a network change or sleep. It never maps a port below 1024 or for another address, and never deletes a
  mapping it did not make. Forwarding the port by hand (mapping = "manual") and machines with a public address
  (mapping = "none") are first-class.
• Reachability is proven by a dial-back from outside: another node of the fleet on a different network, or an
  endpoint you run (oarbank-agent probe-endpoint, setting listener_probe_endpoint). The node page's Network
  card says in words what the router, the firewall and the probe found: DOUBLE_NAT (with the bridge-mode fix),
  CGNAT, NO_MAPPING_PROTOCOL, PORT_TAKEN, MAPPED_UNREACHABLE, FIREWALL_BLOCKED.
• oarbank listener list|show|mappings|set|remove|probe, and oarbank listener disable --node <node> | --all as the
  kill switch (resume undoes it). Node settings inbound_listeners (managed policies can force it off),
  listener_port_range and listener_probe_endpoint. Alerts listener_unreachable and listener_saturated.
  Invariant S24: every listener and mapping a node reports has an approved grant, an assignment and the statement the
  node applied.
• macOS: the node package adds the agent to the Application Firewall's allowed list when the firewall is on
  (oarbank-agent firewall status|allow); the Windows helper adds the listener's firewall rule. Uninstalling a node,
  and retiring an online one, releases its router mappings (oarbank-agent portmap status|release-all).

Workloads: long-running daemons that are the work. A module can declare [[workloads]], such as a node of a
peer-to-peer network or a public inference server. You assign one to nodes (oarbank workload assign <module>/<workload> --node <node>, previewed with the secrets it receives, the listeners it opens and the protection
rules that act on it); the agent runs it in the module sandbox in a process container of its own, restarts it with
backoff and withdraws it after repeated failures (alert workload_withdrawn with the last error and log tail).

• One seat per identity. A workload that runs under one identity per node holds a coordinator seat lease with a
  fence, named by the keyed fingerprints of the secrets it receives, so two nodes given the same key never run it at
  once (invariant S26). Leases last 30 minutes and are renewed with every heartbeat; workloads survive an agent restart
  by adoption and a coordinator outage until their lease runs out.
• Protection treats a workload as fleet work with its own ladder: no new seats, throttle, lower, pause up to the
  workload's declared tolerance, then stop and hold while the cause lasts.
• The module page's Workloads tab and the node page's Workloads card show each assignment, its seat, lease,
  state, last error and log tail; oarbank workload list|assign|unassign|restart|logs. Node setting workloads
  (managed policies can force it off). Containment: macOS sandbox identity, a Linux cgroup (a node without a delegated
  cgroup is not offered workloads), a Windows Job Object.

Delegated processes. Behind the node setting delegated_processes (off by default, and a managed policy can force
it off), an owner protection rule can mark the owner's own programs delegate = {actions = ["pause", "lower"]}, so
protection pauses and lowers them for a protected process the way it does fleet work. Only matchers a module cannot
spoof count (a code-signing identity on macOS, a trusted exact path on Linux and Windows); they are never stopped, and
every action is journaled. On a system install the person's session helper acts on the person's processes.

Co-tenancy you can measure. Protection reacts faster and can prove that fleet work does not slow a protected
program down.

• Event-driven owner sources. Progress and phase sources (JSONL events, log lines, fie...

Oarbank 2.8.0

Install, then join

Node packages no longer need the join code before they install, and nothing asks you to create files by hand. Every
package installs the node and asks nothing; joining is one step after it, the same on macOS, Linux and Windows.

• Oarbank Node. The macOS package adds Oarbank Node to the menu bar and opens it at its join window when
  Installer finishes; Windows adds an Oarbank Node tray app (and the MSI has a join page); Linux desktops get an
  Oarbank Node entry. Paste the code: the window checks the network and the coordinator, joins, and follows the
  machine until it is approved and connected.
• oarbank-node. join reads the code hidden, from standard input or from a file (never from the command line),
  checks it, joins and waits; check, status, leave and doctor complete it. Stable exit codes for scripts.
• One-line installers. curl -fsSL https://github.com/roeehrl/oarbank/releases/latest/download/oarbank-install.sh | sudo sh
  and irm https://github.com/roeehrl/oarbank/releases/latest/download/oarbank-install.ps1 | iex download this
  release's package for the computer, verify its SHA-256, install it and join.
• Add machine in the console. Fleet, Add machine… makes a code and shows the installer and commands for each
  operating system with the code filled in, a ready macOS configuration profile, Intune, Group Policy, policy.json and
  Ansible snippets, and the machines arriving live with Approve and Decline.
• Codes for one machine or many. A code for one machine works once and approves it at once (4 hours by default).
  A code for many machines (MDM, images) has a use cap and leaves each machine waiting for approval unless you choose
  otherwise. Codes can be listed and revoked.
• Managed policy. A node that has not joined reads its code from a macOS configuration profile
  (dev.codonic.oarbank.agent), Windows policy (HKLM\SOFTWARE\Policies\Codonic\Oarbank\Agent, ADMX template in the
  release) or /etc/oarbank/policy.json. Linux packages read OARBANK_JOIN_CODE; MSIs keep JOINCODE/JOINCODEFILE.
• Device codes. Where you cannot paste, oarbank-node join --coordinator <url> shows the coordinator's fingerprint
  and an 8-letter code you approve on the Fleet page.
• Safer joining. Join codes (format OB2) now pin the coordinator's identity key as well as its certificate
  authority and carry their expiry; a node checks DNS, the port, the identity, the certificate authority and its clock
  before sending anything, and every failure has a stable code and a plain-language fix. A code that arrives by link
  is always confirmed first. An unreachable coordinator is retried until the code expires; installs never fail
  because the network is down.

Changed: OB1 join codes, /Library/Oarbank/etc/{join-code,coordinator,system} and /etc/oarbank/{join-code,coordinator}
are gone. Make new codes in the console.

Oarbank 2.7.0

Oarbank 2.7.0 adds native desktop access to the coordinator and improves first-run setup. The module SDK remains 1.5.0.

• A native menu bar app on macOS, notification-area app on Windows, and StatusNotifier tray app on Linux provide coordinator status, Open web app, Preferences…, and Quit. Linux desktops without a tray host have a GTK control window.
• Start automatically at sign-in is optional, per account, and off by default. Startup opens the companion quietly. Quitting the companion leaves coordinator services running.
• Authenticator enrollment now displays a QR generated locally from the standard otpauth URI. Manual entry remains available; enrollment secrets are never sent to an external QR service.
• Native installers include the official application icon. macOS packages are signed with Developer ID, notarized and stapled. Windows packages remain unsigned.
• Closing or refreshing setup no longer immediately closes its local server. Reopening unfinished setup preserves the saved address, administrator and keys and requests the original password. A disconnected page explains recovery instead of showing an empty new-setup form.
• The Windows tray and normal console login run without administrator rights. Setup and service recovery request elevation explicitly.

Install the new coordinator package, open Oarbank Coordinator, click its menu bar/tray icon and choose Open web app. Existing fleet data is retained. Follow the Get started guide for setup and the installation reference for service recovery and updates.

Coordinator requirements: macOS 15+ on Apple silicon; Linux with systemd and glibc 2.39+ (published builds use Ubuntu 24.04); Windows x64 10 1809+/Server 2019+, or ARM64 Windows 11 with bundled x64 Python under emulation. Node installers remain available for every supported processor. Every machine that runs jobs also needs its node package.

Oarbank 2.6.0 — native coordinator installers

Oarbank 2.6.0 adds native coordinator installers and guided first-run setup. Install the coordinator package, open its setup application, choose the address your nodes can reach, create your administrator account, verify your authenticator, and back up your owner signing key. Then create one join code per computer and install the agent on each node.

• macOS: Apple Silicon coordinator .pkg, Developer ID signed, notarized, and stapled. Open Oarbank Coordinator in Applications. Agent packages support Apple Silicon and Intel.
• Linux: coordinator .deb and .rpm for x86-64 and ARM64, requiring glibc 2.39 or newer (built and tested on Ubuntu 24.04). Open Oarbank Coordinator from the application menu or run oarbank-setup.
• Windows: coordinator .msi for x64 and ARM64. Open Oarbank coordinator setup in Start and accept elevation. ARM64 coordinator requires Windows 11 for its bundled x64 Python runtime.

Coordinator packages install software only. Services and fleet state are configured when you submit the wizard. Interrupted setup preserves existing accounts and signing keys; reopening resumes setup. Reopening completed setup opens the console, and upgrades refresh the installed service definitions. Native removal retains fleet data. Advanced coordinator archives remain available for signed moves and scripted deployment.

The Windows setup response path handles deliberately rejected requests without resetting the client's connection. Mac address discovery excludes broadcast addresses. Bundled runtimes remain relocatable; the Mac package preserves runtime symlinks and contains no AppleDouble metadata.

Core and agent: 2.6.0. Module SDK: 1.5.0, unchanged. Verify downloads against their matching SHA256SUMS files.

Follow Get started and installation details.

Oarbank 2.5.0

The first public release of Oarbank: a self-hosted job queue for the Macs, Linux machines and Windows PCs you already own. A coordinator hands batch jobs to a node on every computer, keeps each computer's own work first, and runs every job in the operating system's sandbox. Modules are built with the open-source module SDK 1.5.0 (Apache-2.0).

Get started: docs.codonic.dev/oarbank/get-started · Requirements · Install guide

Downloads

For	File
Mac node, Apple silicon	oarbank-agent-2.5.0-macos-arm64.pkg
Mac node, Intel	oarbank-agent-2.5.0-macos-x86_64.pkg
Linux node, Debian/Ubuntu	oarbank-agent_2.5.0_amd64.deb, oarbank-agent_2.5.0_arm64.deb
Linux node, Fedora/RHEL	oarbank-agent-2.5.0-1.x86_64.rpm, oarbank-agent-2.5.0-1.aarch64.rpm
Linux node, manual install	oarbank-agent-2.5.0-linux-amd64.tar.gz, oarbank-agent-2.5.0-linux-arm64.tar.gz
Windows node	oarbank-agent-2.5.0-windows-x64.msi, oarbank-agent-2.5.0-windows-arm64.msi
Coordinator	oarbank-coordinator-2.5.0-<platform>.tar.gz for darwin-arm64, linux-amd64, linux-arm64, windows-amd64, windows-arm64
Coordinator installer	install-oarbankd.sh (macOS, Linux), install-oarbankd.ps1 (Windows)

The oarbank-agent-2.5.0-<platform> binaries are for the coordinator's agent-update channel (oarbank agent upload). Every file has a SHA256SUMS-* file beside it.

Signing.

• The macOS packages and every binary in them are signed with Developer ID (Application and Installer) and notarized by Apple.
• The Windows MSIs are not code-signed yet: Windows SmartScreen may ask you to confirm before running one you downloaded with a browser.
• The Linux packages are unsigned; check them against their SHA256SUMS files.

What's in it

• One queue on every OS.
  • Nodes run on macOS 15+ (Apple silicon and Intel), Linux with systemd (x86_64, arm64) and Windows 10 1809+ / 11 (x64, ARM64).
  • The coordinator runs on a Mac with Apple silicon, on Linux, or on Windows (Windows services, with an admin API over a named pipe).
  • A job goes to a certified node with the CPU, memory, tools and GPU API it needs.
• The owner's work first.
  • On every OS: a memory guard, per-node caps, rules for named apps and processes, presence of someone at the computer, and battery back-off.
  • Heat back-off on macOS and Linux.
  • Rules that match code-signing identity on macOS.
• Every job sandboxed: Seatbelt on macOS, Landlock and seccomp on Linux, AppContainers and Job Objects on Windows.
  • Per-job network allowlists go through the agent's proxy.
  • Write-only secrets.
• Containers.
  • Signed container image sets.
  • Agent-owned Colima on macOS (krunkit for Vulkan on the Mac's GPU), rootless Podman or Docker on Linux, and WSL containers on Windows (WSL 2.9.3+).
  • GPU in containers is placed by GPU API (gpu_apis).
• Service endpoints: jobs reach warm per-node services, such as a loaded model server.
• Datasets in and out:
  • origins by URL and digest;
  • resumable uploads and downloads;
  • approved input and outbox folders;
  • media, gallery and compare components in module console pages;
  • checkpoints.
• Console and CLI parity: everything in the console is also in oarbank (node show|mode, job show|retry|cancel, protection …). Modules can add their own console pages (UI contract 1.2).
• Owner-signed operations: releases, agent updates and coordinator moves need the owner's signature, and every change is audited.
• Certification: nodes run each module's doctor and golden jobs before their results count.

Help wanted

Some hardware paths are verified only by people who have the machines. NVIDIA, AMD and Intel GPUs, and Windows with GPU containers, are tracked in the hardware compatibility table. Report your machine with the hardware report form.

Licence

The core is source-available under PolyForm Strict 1.0.0. The module SDK is Apache-2.0.