Octonode Playbook

Local and cloud capability contract

Canonical Octonode repository documentation.

Local and cloud capability contract

GET /api/capabilities is the authority for deployment mode and feature availability. Studio, CLI, MCP, and tests consume this typed document; clients must not infer mode from a hostname, deployment global, or a deliberately failing operation.

The modes are:

  • trusted-local: a local server with no configured cloud control plane.
  • configured-local-cloud: a local server authenticated to cloud workspace services.
  • hosted: the production server running inside the hosted workspace Sandbox.

Unavailable capabilities use stable reasons: not_implemented, requires_cloud_configuration, requires_hosted_runtime, provider_not_configured, disabled_by_policy, missing_entitlement, or missing_permission.

Conformance matrix

yes means the capability is implemented in that mode today. Other cells contain the reason returned by the contract.

CapabilityTrusted localConfigured local-cloudHostedOwning authority
workspace_identityyesyesyesLocal server identity or authenticated cloud principal
workspace_socialrequires_cloud_configurationyesyesCloudflare workspace Durable Objects
task_managementrequires_cloud_configurationyesyesCloudflare workspace Durable Object task tables
workspace_adminrequires_cloud_configurationyesyesCloudflare D1 membership and policy records
workflow_executionyesyesyesCurrent workspace server and canonical project source
billingrequires_cloud_configurationyesyesStripe authority with Cloudflare D1 projections and usage stop-loss limits
design_reviewnot_implementednot_implementednot_implementedPlanned shared review service
design_previewnot_implementednot_implementednot_implementedPlanned isolated preview runtime
architectureyesyesyesRead-only projection derived from project and capability authorities
githubrequires_cloud_configurationyesyesGitHub App plus cloud installation records
slackrequires_cloud_configurationyesyesSlack OAuth v2, explicit channel bindings, signed Events API, and durable chat outbox
googlenot_implementednot_implementednot_implementedProduct decision pending; provider authority follows approval
metanot_implementednot_implementednot_implementedProduct decision pending; provider authority follows approval
qwennot_implementednot_implementednot_implementedPlanned Qwen provider connection
workflow_agentsrequires_cloud_configurationprovider_not_configuredprovider_not_configuredPrivate chat service plus existing workflow, social, and evaluation authorities
cloud_terminalnot_implementednot_implementednot_implementedPlanned dedicated terminal Sandbox
mcp_catalognot_implementednot_implementednot_implementedPlanned generated MCP and skill descriptors
monitoringyesyesyesOpenTelemetry-compatible monitoring pipeline
agent_monitoringnot_implementednot_implementednot_implementedPlanned content-free correlated trace records
backup_restoreyesyesyesMode-selected filesystem or cloud recovery authority
write_authorityyesyesyesCanonical source/store locally; workspace cloud stores remotely
community_readrequires_cloud_configurationrolloutrolloutMarketplace D1, publication API, and immutable community R2 revisions
community_authoringrequires_cloud_configurationrolloutrolloutPersonal Design Docs copied through the publication API
community_publishingrequires_cloud_configurationrolloutrolloutModeration policy and append-only audit records
workflow_templatesrequires_cloud_configurationrolloutrolloutModerated immutable public workflow snapshots

Community rollout uses OCTONODE_COMMUNITY_ROLLOUT=off|read|submit|publish|all; omitted values fail closed to read. The Worker uses the matching COMMUNITY_ROLLOUT stage. Enable reading first, then submissions, and only then moderator publishing and workflow templates.

Capability parity is not state synchronization

Conformance means the same supported operation has the same contract and observable result in each mode unless the matrix declares a difference. It does not make local and cloud stores replicas.

Backup, restore, import, and export are explicit point-in-time transfer or recovery operations. They do not continuously synchronize state. Each record remains owned by the persistence authority defined in ADR-001, and restore still follows the validation and empty-target rules in Backup and restore.

On this page