Reference

Compatibility

Deployment options, platform requirements and integration maturity.

For: people choosing a deployment or integration.

Use this reference to check whether a platform or integration fits your deployment. Read the linked setup guide for its requirements and Known issues for current operational problems.

Public availability

Orchestrator Zero is pre-release. These docs are available ahead of source downloads, release binaries and container images, which are coming soon. The quickstart and build instructions currently require access to the private repository.

oz0 Hub at hub.oz0.ai (coming soon) is not open for public browsing or submissions. The hub: install syntax can use an index you operate; it does not mean the public Hub is available.

Server and node platforms

The oz0 server runs management, edge and embedded Temporal together by default. You can run selected roles separately with the same binary. Nodes use the separate oz0-node binary. See Architecture.

Platform or deployment	Requirements and setup
Linux nodes	Use bubblewrap 0.12.0 or later for tier 1 and protected paths. Alpine's musl runtime is unsupported. Install, sandbox tiers.
macOS nodes	Seatbelt provides tier 1; the current profile needs native validation. Memory, process and CPU limits are unavailable. macOS sandbox.
Windows nodes	No local tier-1 sandbox. Use a Linux node for work that requires one. Windows sandbox.
Node services	Windows service and launchd lifecycle checks passed on hosted runners; user-machine validation remains. Services.
Containers and Kubernetes	Isolation depends on the host and pod settings. Docker, Kubernetes.
Separate management and edge sites	WAN behaviour has been simulated, but not validated between two real sites. Management over a WAN.

Temporal backends

Backend	Validation, limits and setup
Embedded Temporal	Default backend; shared-pool fair dispatch has been measured here. Temporal.
External Temporal	Configure the external cluster for fairness before relying on fair dispatch between plugins. That configuration has not been exercised. Backends, shared pools.
Temporal Cloud	Integration has automated coverage against a service stand-in; live-service validation remains. Published stand-in measurements are not Cloud performance figures. Backends.

Without fair dispatch, a shared pool still runs, but one plugin's backlog can delay others.

Integrations awaiting live validation

The integrations below are implemented and have automated coverage against service stand-ins or scripted agents. They have not been verified against the actual services or clients named here. Plan a deployment check before relying on one; this list does not claim vendor certification.

Integration	Details to check before use
GitHub, Slack, Discord and web search plugins	Plugin configuration and requirements
Microsoft Teams	Cards have not been rendered in a real Teams client, nor an app package uploaded to a real tenant. Setup and limits.
Atlassian Cloud and Data Center	Rovo tool descriptions and schemas are project-supplied until a live listing is captured. Atlassian limits.
Claude Managed Agents and ACP agents	Coverage uses scripted APIs or agents, including stand-ins for codex-acp, OpenCode and goose. Remote agents.
AgentCore and Foundry A2A	AgentCore SigV4 authentication is unsupported. A2A setup.
E2B and compatible remote sandboxes	Cloud and self-hosted deployments need live validation. Remote sandboxes.
Vertex AI, Azure OpenAI and Bedrock authentication	Provider token endpoints and signed requests have stand-in coverage only. Model authentication.
OIDC identity and cloud federation	External verifiers and AWS, Google and Microsoft token services need live validation. Identity, federation.
MCP client OAuth	Claude Code, Cursor and Visual Studio Code have not been connected; public client-metadata retrieval needs validation. Client OAuth.
Remote MCP OAuth and tasks	Vendor-server interoperability and progress-resumption conventions need validation. Connections, call lifecycle.

Cloud federation has additional compatibility limits: the issuer signs with ES256, while Entra federation expects RS256. The agent runtime does not speak Bedrock's request format, so a federated Bedrock call has not run as an agent job. Credentials accepted by the cloud remain bearer credentials for their lifetime; node binding inside the cluster does not change that boundary.

Model behaviour and extended integrations

Starter-agent evals use recorded answers. Published live results cover a local 3B CPU model on 12 of 21 cases; there are no published hosted Claude or OpenAI results. See Measured results. The demos likewise do not establish behaviour against live GitHub or Claude services.

Scheduled evals and model canaries have not established the normal variation of hosted-model answers. Prompt-cache lifetime, billing and re-warming also need live validation. Claude on Bedrock, Vertex and AI Foundry currently uses plain cache marks without the longer lifetime or re-warming. See model canaries and prompt caching.

Identity integration has been checked with Keycloak; Entra ID and Okta validation remains. Cloud services, directories, HSMs and external secret stores used by the extended integrations have stand-in coverage only. Use the relevant sign-in, key-command and secret-store guides to assess your environment.

For security assurance and reporting, see Security assurance.

Previous section links

Implemented capabilities: Read the current guidance.

Servers: Read the current guidance.

Regions: Read the current guidance.

Nodes: Read the current guidance.

Tenants: Read the current guidance.

Plugins: Read the current guidance.

Agents: Read the current guidance.

Jobs: Read the current guidance.

Routines: Read the current guidance.

Models and cost: Read the current guidance.