Configuration and governance
Tenant metadata, published policy and capability versions, deployment registry, connector installation status, and operational control.
Customer-controlled deployment
Put sensitive execution where it belongs.
Onterix’s target architecture separates governance from sensitive execution and uses one runtime contract across managed, dedicated, customer-data-plane, and fully self-hosted modes.
ClaudeChatGPTCodexCLIInternal agents
ONTERIX RUNTIMEOne governed execution path
IdentityData policyApprovalEvidence
Company systemsKnowledgeModelsWorkflows
Target deployment architecture
Same boundary. Different ownership.
Deployment changes placement, tenancy, providers, and operational ownership—not the meaning of identity, policy, protection, approval, or evidence.
| Mode | Control plane | Sensitive execution | Content locality | Best fit |
|---|---|---|---|---|
| Managed shared Planned launch path | Onterix shared | Onterix regional shared cell | Managed data plane | Evaluation and standard workloads |
| Managed dedicated Target architecture | Onterix shared or dedicated | Tenant-dedicated Onterix cell | Dedicated environment | Isolation, scale, and region requirements |
| Customer data plane Target architecture | Onterix shared or dedicated | Customer VPC or cluster | Customer-local | Local credentials, content, indexes, and workflows |
| Fully self-hosted Target architecture | Customer | Customer environment | Customer-local | Disconnected or maximum-control environments |
Stable plane boundary
The control plane is not a hidden content proxy.
In strict customer-data-plane and self-hosted designs, the central service coordinates metadata and signed configuration while sensitive execution state remains with the active data plane.
Credentials and execution
Connector secrets, source content, indexes, tool execution, protection findings, quarantines, artifacts, and execution-local evidence.
Signed, outbound-friendly control
Customer runtimes pull immutable configuration and narrow control messages without exposing a broad inbound management plane.
Deployment invariants
Residency is a resolved execution property—not a hostname promise.
Tenant placement, regional cell, storage, model route, connector destination, workflow ownership, and failover policy must agree before content-bearing work begins.
Resolve before ingress
Customer content routes directly to its assigned cell or customer runtime. The central control plane is not on the payload path.
No silent region change
Unavailable placement follows explicit tenant policy. It never silently moves regulated work across regions.
Build once, configure per mode
The target uses the same signed runtime and worker artifacts across managed and customer-hosted deployments.
Bring enterprise infrastructure
Identity, KMS, object storage, search, model routing, audit sinks, and data-protection providers remain replaceable behind typed contracts.
STATUS
These are planned deployment models under active implementation. Managed AWS production, customer-hosted packaging, residency routing, and offline self-hosted verification are not yet presented as generally available.
Deployment architecture
Map the boundary before choosing the topology.
Tell us which content, credentials, indexes, workflows, model routes, evidence, and support operations must remain under customer control.