Split deployment modes

All deployments support standalone execution and assigned server/client runners with Docker or Kubernetes. See tenant-aware execution for runtime restrictions, authority and migration.

The ADP can run as one execution plane or as a server/client pair. In both cases the use-case application owns participant coordination and the control plane drives dataflow lifecycle signaling.

Standalone mode

Standalone runs dataflow signaling, job execution, event delivery, and the operator API in one process. Use it for local experiments or when the workload and dataspace-facing network can share an environment.

split:
  mode: standalone

Server mode

The server runs in the network that can reach the control plane and other participants. It receives execution submissions and dataflow callbacks, maintains the execution metadata, and bridges job-control messages to the paired client. It does not initialize a local job runtime. Any orchestration configuration on the server is unused; configure Docker or Kubernetes on the assigned runners.

split:
  mode: server

Client mode

The client runs where the data and workload must remain. It receives an algorithm instance and its data-source bindings over the bridge, starts the local job, and sends status and event messages back to the server. It has no direct DSP registration or transfer-management surface.

split:
  mode: client
  bridgePeerWsUrl: https://server.example.com

The client does not upload files or negotiate transfers. The use-case application establishes the dataflows at the server side and the server relays only the execution metadata required by the client.

Bridge messages

Server to client:

• algorithm instance created, updated, or deleted;
• local start request;
• remote algorithm event metadata and payloads.

Client to server:

• local job status;
• locally created event metadata and payloads;
• large event data chunks when the payload is too large for one WebSocket message.

Configuration

Every split deployment requires explicit runner identities and ownership assignments on both sides. Configure the server's normal OAuth validation with the bridge's expected audience and trusted issuer. Configure the client's normal OAuth client credentials to obtain that audience through split.bridgeAudience.

Server:

controlPlane:
  controlplaneId: shared-control-plane
  dataplaneId: shared-analytics
  executionScopes:
    - issuer: https://identity.example
      controlPlaneId: shared-control-plane
      tenantId: 11111111-1111-4111-8111-111111111111
split:
  mode: server
  runners:
    - id: alice-runner
      issuer: https://identity.example
      subject: alice-runner-service
      clientId: alice-runner-service
      executionScopes:
        - issuer: https://identity.example
          controlPlaneId: shared-control-plane
          tenantId: 11111111-1111-4111-8111-111111111111

Runner:

controlPlane:
  controlplaneId: shared-control-plane
  dataplaneId: shared-analytics
split:
  mode: client
  runnerId: alice-runner
  executionScopes:
    - issuer: https://identity.example
      controlPlaneId: shared-control-plane
      tenantId: 11111111-1111-4111-8111-111111111111
  bridgePeerWsUrl: https://server.example.com
  bridgeAudience: analytics-runner-bridge
  bridgeChunkSize: 524288
  maxPayloadBytes: 67108864

Runner identity and source ownership are separate from a flow's requesting counterparty. A scope is assigned exclusively to one runner; one runner may have several scopes. Both sides use persistent databases. The client also needs an owner-bound source registry and the Docker or Kubernetes runtime configuration from tenant-aware execution. The server needs neither local dataset credentials nor a job runtime.

Use the HTTPS Socket.IO server base URL, including any configured application prefix. allowInsecureBridge: true permits HTTP only for an explicitly trusted local test network. The client readiness endpoint is /health and does not depend on a participant registration.

The bridge uses expiring authenticated sessions, immutable runner assignments, increasing execution revisions and persisted revocation fences. Reconnect renews the current session and authority; it does not restore an expired job UUID. Restarted runners fence old runtime work and require a new local job submission. Keep the authority ledger when pruning or migrating the runner database.

Parameter	Type	Description	Default
mode	string	standalone, client, or server	standalone
bridgePeerWsUrl	string	Server Socket.IO base URL (HTTPS) for a client runner	—
bridgeChunkSize	number	Maximum event-data chunk size in bytes	524288
runners	array	Server: exact OAuth principals, runner IDs and exclusive owner assignments	[]
runnerId	string	Client: immutable runner identity	—
executionScopes	array	Client: exact allowed execution owners	[]
bridgeAudience	string	Client: requested OAuth service-token audience	—
allowInsecureBridge	boolean	Permit HTTP for an explicitly trusted local test network	false
maxPayloadBytes	number	Split payload limit before buffering	67108864