How partner workloads ship onto a Datab Node. The platform supports three deployment shapes; partners pick whichever matches their operational reality.

Shape 1 — container image

The partner publishes a container image (OCI / Docker). Operators pull it onto the node and run it via the snap-local docker socket. Most partner workloads use this shape.

• Image binds 127.0.0.1 inside the node. The backend at port 8080 is the only LAN-reachable surface.
• Partner picks a free port in 11000–11999 for their service if needed (Orula and Gu reserve 11434, 11444, 11445).
• Partner reads + writes via the institution backend at http://localhost:8080 with a JWT.

Shape 2 — snap part

The partner contributes a snap part — a directory of binaries + services that's stacked into the datab-app snap at build time. Heavier integration; tighter packaging.

• Coordinated release cadence with the datab-app snap.
• Suitable for workloads that need privileged plugs (e.g. hardware-observe, network-control).
• Goes through Datab's snap-publish process.

Shape 3 — static asset bundle

Web assets (HTML/CSS/JS) served by the backend's static-resources handler. Suitable for partner-app frontends that don't need a separate runtime.

• Drop bundle under the backend's classpath:public/ or via the static-resources mapping.
• No new process, no new port.

Required commitments from partners

• Atlas identity gate. Don't bypass the identity layer; always use the issued JWT.
• Bounded agency. Don't call Orula or Gu in a way that circumvents the approval queue.
• Audit integration. Disruptive partner actions write to the institution audit log.
• No phone-home. No silent telemetry to partner-controlled servers.

Partner onboarding starts via databsystems.com/partners.