# Oarbank > Documentation for Oarbank: run jobs on a fleet of macOS, Linux and Windows computers, and build modules for it with the open SDK. Current release: Oarbank 2.11.1, module SDK 1.8.0. These docs describe that release only; for an older installation, read the docs in the repositories at its tag (https://github.com/roeehrl/oarbank/tree/v/docs). Load only what the task needs: one of the sets below, or single pages. Every page has a Markdown version at its URL plus `.md`; they are listed under Pages. A Markdown URL that returns a status other than 200 is not a page. ## Documentation Sets - [Abridged documentation](https://docs.codonic.dev/oarbank/llms-small.txt): a compact version of the documentation for Oarbank, with non-essential content removed - [Complete documentation](https://docs.codonic.dev/oarbank/llms-full.txt): the full documentation for Oarbank - [Operate](https://docs.codonic.dev/oarbank/_llms-txt/operate.txt): Install, run and maintain an Oarbank fleet. - [Build modules](https://docs.codonic.dev/oarbank/_llms-txt/build-modules.txt): Write, test and ship modules with the open SDK. - [Specification](https://docs.codonic.dev/oarbank/_llms-txt/specification.txt): The normative public contracts. ## Notes - The complete documentation includes all content from the official documentation - The content is automatically generated from the same source as the official documentation ## Optional - [Oarbank product page](https://codonic.dev/apps/oarbank) ## Pages - [Files, media and checkpoints](https://docs.codonic.dev/oarbank/build/files-media-checkpoints.md): Register datasets by URL, import uploads, use folders on the node, show media artifacts on module pages and keep portable checkpoints, with the reel example. - [Share a GPU with a protected program](https://docs.codonic.dev/oarbank/build/gpu-duty.md): Share a node’s GPU with a protected program: hold the agent’s GPU duty with the SDK’s duty governor, prove it with the conformance kit and run llmserve. - [Place work by GPU API](https://docs.codonic.dev/oarbank/build/gpu-placement.md): Place an Oarbank module’s work by GPU API: name the APIs a runner or service uses per platform, so its jobs run only on nodes that provide one. - [Ask for host tools](https://docs.codonic.dev/oarbank/build/host-tools.md): Ask for a JDK, Python or another host tool by id and version range in an Oarbank module, test the installation the node grants, and move off registry ids. - [Accept connections from the internet](https://docs.codonic.dev/oarbank/build/inbound-listeners.md): Accept internet connections in an Oarbank module: declare an inbound listener, serve it in an endpoint service, limit who may connect, and test it. - [Build your module's GUI](https://docs.codonic.dev/oarbank/build/module-gui.md): Pages and panels as data, the host queries that show what the core does for your module, buttons and typed links, and a sandboxed frame with a bridge client. - [Declare module settings](https://docs.codonic.dev/oarbank/build/module-settings.md): Declare a module’s settings as typed keys with a scope, read them on nodes and on the coordinator, let campaigns override them, and move a module from SDK 1.5. - [Use secrets and signed container images](https://docs.codonic.dev/oarbank/build/secrets-and-images.md): Give one stage an API key that nothing else sees, approve hundreds of container task images by their signing key, and give containers the GPU. - [Serve jobs from a warm service](https://docs.codonic.dev/oarbank/build/service-endpoints.md): Serve Oarbank jobs from a warm endpoint service: load a model once per node, let each job on the node send it work, and test it with the conformance kit. - [Build a module in a day](https://docs.codonic.dev/oarbank/build/tutorial.md): Build an Oarbank module in a day: primes counts primes on your nodes, from manifest, coordinator side and runner to goldens, conformance kit and bundle. - [Run a long-running workload](https://docs.codonic.dev/oarbank/build/workloads.md): Run a long-running workload in an Oarbank module: declare it, wrap a third-party daemon in the supervisor shim, answer status and pass the conformance kit. - [How Oarbank works](https://docs.codonic.dev/oarbank/concepts/how-oarbank-works.md): How Oarbank works: the coordinator, nodes and join codes, modules, workloads and campaigns, certification, sandboxing, host protection and signing. - [Get started](https://docs.codonic.dev/oarbank/get-started.md): Download Oarbank for macOS, Linux and Windows, set up a coordinator and its nodes, and install the open-source module SDK to build your own modules. - [Oarbank documentation](https://docs.codonic.dev/oarbank/index.md): Oarbank runs batch jobs on the macOS, Linux and Windows computers you own. Learn how it works, what each computer needs and how to build modules. - [Adding machines](https://docs.codonic.dev/oarbank/operate/adding-machines.md): Add machines to an Oarbank fleet with a join code on macOS, Linux and Windows: by hand, over SSH, by installer or MDM, and what each join error means. - [Hardware compatibility](https://docs.codonic.dev/oarbank/operate/compatibility.md): The machines Oarbank’s GPU detection, GPU containers and Windows container runtime have run on, with each run’s result and versions, and how to add yours. - [Containers on nodes](https://docs.codonic.dev/oarbank/operate/containers.md): Run container jobs on Oarbank nodes: what macOS (Colima), Linux (Podman or Docker) and Windows (WSL) need, what the node sets up and how to check it. - [The coordinator service](https://docs.codonic.dev/oarbank/operate/coordinator.md): The Oarbank coordinator service on macOS, Linux and Windows: where it runs and keeps state, who may use its CLI, the tray app, logs and restarts. - [Datasets, folders and downloads](https://docs.codonic.dev/oarbank/operate/datasets-and-folders.md): Upload folders as datasets, download datasets and campaign results, decide which hosts nodes may fetch from, and give modules folders on a node. - [Delegated processes](https://docs.codonic.dev/oarbank/operate/delegated-processes.md): Delegate a program you started outside Oarbank to host protection, so it is paused and lowered for your protected programs, with a delegate rule. - [Host protection](https://docs.codonic.dev/oarbank/operate/host-protection.md): Host protection keeps Oarbank fleet work from harming the people using a node: set its mode and protected-process rules, canary them and read what it did. - [Host tools](https://docs.codonic.dev/oarbank/operate/host-tools.md): How Oarbank nodes find the host tools modules need, such as a JDK or Python, what TOOL_NOT_FOUND means, and how to install, re-detect or pick one. - [Run language-model batches with llmserve](https://docs.codonic.dev/oarbank/operate/llmserve.md): Run language-model batches with llmserve: install it, give a node a backend and a model, queue prompts, and share the GPU only up to a certified duty. - [Make a node reachable](https://docs.codonic.dev/oarbank/operate/make-a-node-reachable.md): Make a node reachable from the internet: assign a module’s inbound listener, let the agent map the router port (PCP, NAT-PMP, UPnP) or forward it by hand. - [Running modules](https://docs.codonic.dev/oarbank/operate/modules.md): Run Oarbank modules: install, approve, enable and sign a release, follow its readiness checklist to running jobs, and see why a doctor check stops jobs. - [Prove co-tenancy is safe](https://docs.codonic.dev/oarbank/operate/prove-co-tenancy.md): Prove co-tenancy is safe: measure what fleet work costs a protected program with the paired on/off harness, earn a certificate, and run GPU work beside it. - [Requirements](https://docs.codonic.dev/oarbank/operate/requirements.md): What the coordinator and each node need on macOS, Linux and Windows, and what the network needs, before you install Oarbank. - [Settings](https://docs.codonic.dev/oarbank/operate/settings.md): Oarbank settings at fleet, group and node scope: node groups and labels, locks, bulk changes, canary then promote, campaign overrides and settings as code. - [Sites and shared internet lines](https://docs.codonic.dev/oarbank/operate/sites.md): Group nodes that share one internet line into a site, so network-heavy fleet work pauses while a protected program there uploads, within an uplink budget. - [Troubleshooting](https://docs.codonic.dev/oarbank/operate/troubleshooting.md): Troubleshoot Oarbank: why a job waits, a node takes no work or setup stalls, where each computer keeps its logs, and fixes for macOS, Linux and Windows. - [Updating and removing](https://docs.codonic.dev/oarbank/operate/update-and-remove.md): Update an Oarbank fleet with one rollout from the coordinator or by hand, move the coordinator to another computer, and remove nodes without losing keys. - [Upgrading](https://docs.codonic.dev/oarbank/operate/upgrading.md): Upgrade an Oarbank fleet to 2.11 on macOS, Linux and Windows from 2.10, 2.9 or 2.8: what changes, the one-time coordinator move and removed commands. - [Versions and compatibility](https://docs.codonic.dev/oarbank/operate/versions.md): Find the Oarbank core, agent and module SDK versions you have, the latest release, which SDK features need which core, and docs for older versions. - [Workloads](https://docs.codonic.dev/oarbank/operate/workloads.md): Run a module's long-running workload on Oarbank nodes: assign it, give each node its own secrets, read its state and see how host protection throttles it. - [Command-line reference](https://docs.codonic.dev/oarbank/reference/cli.md): Oarbank command-line reference: every command an operator or module author runs, what it does and where it is installed on macOS, Linux and Windows. - [Manifest fields](https://docs.codonic.dev/oarbank/reference/manifest.md): Every oarbank-module.toml key with its type, default and description, generated from the SDK’s manifest models. - [Reason codes and alerts](https://docs.codonic.dev/oarbank/reference/reason-codes.md): What each code from oarbank explain, a job's attempts, a node's protection log and an alert means, how severe it is and what to run to fix it. - [JSON Schemas](https://docs.codonic.dev/oarbank/reference/schemas.md): Every JSON Schema the Oarbank SDK publishes, generated from its typed Python models, with links to the raw files. - [Result envelope 1](https://docs.codonic.dev/oarbank/reference/schemas/result-envelope-1.md): The result envelope a runner writes for every job, field by field, rendered from result-envelope-1.schema.json. - [Specification](https://docs.codonic.dev/oarbank/spec.md): The versioned public contracts between Oarbank modules and the core, and which document is normative for each. - [Bundles and the module lifecycle](https://docs.codonic.dev/oarbank/spec/bundles.md): The .mfb bundle and its digest, dependencies, and the lifecycle from install and approval through canary, promote and rollback. - [The conformance kit](https://docs.codonic.dev/oarbank/spec/conformance.md): The checks oarbank-sdk conform runs on a module before a host relies on it, and what it does not cover. - [Envelopes (envelope 1)](https://docs.codonic.dev/oarbank/spec/envelopes.md): The spec and result envelopes every job travels in: what the core reads and what belongs to the module. - [Manifest (schema 1)](https://docs.codonic.dev/oarbank/spec/manifest.md): The oarbank-module.toml every bundle carries: identity, compatibility, entry points, stages, services, results, goldens, UI and the cross-field rules. - [Module protocol 1](https://docs.codonic.dev/oarbank/spec/module-protocol.md): How the coordinator talks to a module’s coordinator side: newline-delimited JSON-RPC 2.0 over stdio, its lifecycle, verbs, host callbacks, effects and errors. - [Platforms](https://docs.codonic.dev/oarbank/spec/platforms.md): Rules every Oarbank contract shares on macOS, Linux and Windows: platform tokens, portable paths, encodings, canonical JSON and per-platform declarations. - [Public surface](https://docs.codonic.dev/oarbank/spec/public-surface.md): Exactly what an Oarbank module may depend on, what stays internal to the core, and the guarantees the core gives every module. - [Runner protocol 1](https://docs.codonic.dev/oarbank/spec/runner-protocol.md): How the agent runs a module’s runner once per job attempt: argv, the fixed environment, the work directory, the control document, exit codes and doctor. - [Sandbox on Linux](https://docs.codonic.dev/oarbank/spec/sandbox-linux.md): How Linux nodes enforce the module sandbox contract with Landlock, seccomp and cgroup v2, and what each kernel version can enforce. - [Sandbox on macOS](https://docs.codonic.dev/oarbank/spec/sandbox-macos.md): How macOS nodes enforce the module sandbox contract with Seatbelt: profiles, launch, verification and the mapping. - [Sandbox on Windows](https://docs.codonic.dev/oarbank/spec/sandbox-windows.md): How Windows nodes enforce the module sandbox contract with AppContainers in Job Objects and the elevated helper for the egress allowlist. - [Module sandbox](https://docs.codonic.dev/oarbank/spec/sandbox.md): What every module process may and may not reach on every platform, the [sandbox] grants an operator approves, and the container broker. - [Service protocol 1](https://docs.codonic.dev/oarbank/spec/service-protocol.md): Long-lived node services and probes a module ships: the seven service operations, pools, ownership and probe fingerprints. - [UI contract 1](https://docs.codonic.dev/oarbank/spec/ui-contract.md): How a module defines console pages as data: placements, pages, data bindings, actions, forms, the sandboxed iframe and the tooling. - [Versioning and deprecation](https://docs.codonic.dev/oarbank/spec/versioning.md): How the public contracts are versioned and negotiated, what changes are additive, what the stability labels promise, and how deprecation and removal work. - [Workload protocol 1](https://docs.codonic.dev/oarbank/spec/workload-protocol.md): The workload protocol, how the Oarbank agent runs a long-running process that is the work itself: invocation, environment, events, health and the shim.