Deployment options
Not an on-premises connector to a cloud platform. A platform that runs inside your environment.
Nexus is self-hosted. The engine, the connectors, the code runtimes, the models and the audit record all run inside the estate you control, from a customer data center to a fully disconnected network.
Inside the boundary
- Workflow execution and code runtimes
- Connector and protocol calls to your systems
- Model endpoints and knowledge indexes
- Credentials resolved from your secret store
- Execution history and approval records
Nothing in that list requires a call to a vendor tenant for the platform to function.
- inside your estate
- Self-hostedinside your estate
- vendor-neutral packaging
- Kubernetesvendor-neutral packaging
- deployment supported
- Air-gappeddeployment supported
- and your secret store
- Your identityand your secret store
The starting point
Self-hosted is the default, not an enterprise upgrade path.
Many platforms offer an on-premises component that still depends on a vendor-operated control plane. Nexus is built the other way around: the whole platform is deployed into your environment and operated by you.
Common arrangement
A local agent, a remote brain
- Definitions and scheduling held by the vendor
- Outbound connectivity required for work to run
- Execution metadata leaves the environment
- Disconnected operation is not possible
- Availability depends on a service you do not run
Nexus
The platform is the deployment
- Definitions, scheduling and history stay local
- No external call is required to execute a workflow
- Models and knowledge are hosted in the same estate
- Disconnected deployment is a supported model
- Operational control sits with your teams
Deployment models
Five ways organizations run Nexus.
The choice is usually driven by regulation, network design and who is permitted to administer the environment.
Customer data center
The platform runs on infrastructure you own and operate, inside your own network zones. Suitable where physical control of the hardware is part of the requirement.
- Your hardware and network
- Your identity and secret store
- Your backup and retention
Private cloud
Deployment into a private or hosted cloud environment dedicated to your organization, using your existing platform and network controls.
- Dedicated tenancy
- Existing landing zone
- Your change process
Sovereign cloud
Deployment into a cloud region or provider operating under a specific jurisdiction and operating model, where both location and operator matter.
- Jurisdictional control
- Local operator
- Defined access boundaries
Managed Kubernetes
Deployment onto a managed cluster service in an account or subscription you control, keeping data and execution inside your cloud estate.
- Your cloud account
- Your cluster policy
- Your network boundary
Air-gapped and disconnected
Deployment into an environment with no route to the public internet, including classified and operational technology networks where all artifacts arrive through a controlled process.
- No external calls
- Local registries
- Offline model hosting
Kubernetes
Vendor-neutral by design.
Nexus is packaged for standard Kubernetes rather than for one provider's control plane, which is what allows the same deployment model to move between a data center and a sovereign region.
Vanilla Kubernetes
Self-managed clusters in your own data center or private cloud.
OpenShift
Enterprise distributions where platform policy and security context are already defined.
Amazon EKS
Managed clusters inside your own AWS account and network design.
Azure AKS
Managed clusters inside your own Azure subscription and landing zone.
Google GKE
Managed clusters inside your own Google Cloud project structure.
Support is confirmed against specific versions and configurations during deployment planning. Kubernetes environments differ in storage classes, ingress, network policy and security context, so we validate a target environment rather than claiming that every version and configuration behaves identically.
Planning
Deployment considerations.
These are the decisions that shape a deployment. Settling them early is what turns an installation into an environment your operations and security teams can accept.
Identity integration
Confirm which identity provider and directory the platform will authenticate against, how groups map to roles, and where multi-factor requirements are enforced. This is usually the first item to settle because access design depends on it.
Secrets
Decide which secret store holds connection credentials, service accounts, certificates and keys, and how rotation is performed. The platform references secrets rather than storing them in workflow definitions.
Storage
Plan persistent storage for workflow definitions, execution history, artifacts and knowledge indexes, together with the backup and retention policy those records fall under.
Model hosting
Where sovereign AI is used, plan where model endpoints run, how model artifacts are brought into the environment and which teams may register or publish a model.
Network boundaries
Map which systems the platform must reach, which inbound event sources need exposure, and how egress is restricted. In segmented estates this often drives where execution runs.
Registries
Container images and platform artifacts are pulled from a registry. In restricted and disconnected environments that means mirroring into an internal registry under your scanning and approval process.
Observability
Decide where platform metrics, logs and execution events are forwarded, so operations teams see platform behaviour in the same tooling they already use.
Upgrades
Agree how new versions are validated and promoted, particularly where change windows are formal and where the environment receives artifacts through a controlled transfer.
Environment separation
Development, test and production should be separate deployments or separate workspaces with their own credentials, connections and permissions, so promotion is deliberate.
Disconnected environments
Air-gapped deployment is a first-class model.
Where there is no route to the public internet, the platform still has to do the whole job: integrate, execute code, run models, collect approvals and retain evidence.
No external dependency at run time
Workflows, code nodes and model inference execute against systems inside the network. There is no requirement to call a vendor service for the platform to operate.
Artifacts arrive through your process
Images, platform releases, connector packages and model artifacts are brought in through the transfer and approval process the environment already defines.
Local model hosting
Sovereign AI runs against endpoints hosted in the same environment, so classification, extraction and retrieval work without any data egress.
Evidence stays inside
Execution history, approval records and model inputs and outputs are retained locally and exported only to systems inside the boundary.
Decision guide
Choosing a deployment model in a regulated environment.
Start from the constraint that cannot be negotiated, then work outwards. In most regulated buying processes one of these six lines decides the answer.
If
Regulation names a jurisdiction for the data
Then consider
Sovereign cloud or customer data center
Why
Where law or contract fixes the location of processing and storage, the deployment location becomes the primary constraint. Confirm both the region and the operator.
If
Operator access must be excluded
Then consider
Customer data center or air-gapped
Why
Where the requirement is that no external party can reach the running system, control of administrative access matters more than location alone.
If
The network has no internet route
Then consider
Air-gapped deployment
Why
Plan for internal registries, offline artifact transfer and local model hosting from the start. This shapes upgrade and support processes more than day-to-day operation.
If
A cloud landing zone is already mandated
Then consider
Managed Kubernetes or private cloud
Why
Deploy into the existing account structure and network design so the platform inherits controls that have already been approved.
If
Business units need separation
Then consider
Workspace separation, or separate deployments
Why
Where isolation is organizational rather than jurisdictional, workspaces are often sufficient. Where it is legal or contractual, separate deployments are the safer answer.
If
Sensitive systems sit in a segmented zone
Then consider
Deployment aligned to the zone
Why
Place execution where the target systems are reachable under existing policy rather than opening new paths across a boundary that was designed to stay closed.
Definitions
Data residency and operational sovereignty are different questions.
They are often treated as one requirement, which is how organizations end up with data in the right country and administrative control in the wrong place.
Data residency
Where the data sits
A statement about physical or regional location: data is stored and processed in a named jurisdiction. It answers a question about geography.
Residency on its own does not say who can access the system, who operates it, or whether it continues to work if an external service becomes unavailable.
Operational sovereignty
Who controls the operation
A statement about control: who administers the platform, who holds the credentials, who can change what runs, and whether the system functions without an external dependency.
Self-hosting is what makes operational sovereignty achievable, because the control plane, the execution and the evidence are all inside the boundary you administer.
Boundaries
Operating responsibilities.
Plan capacity, availability and Kubernetes configuration around the workloads your team will operate.
Workload-based sizing
Hardware and cluster sizing depend on workload profile, concurrency and whether model inference runs locally. Capacity planning uses your workload and deployment requirements.
Availability and support
In a self-hosted deployment, availability is a property of the environment you operate. Commercial support arrangements are agreed contractually.
Kubernetes configuration
Kubernetes distributions vary. Deployment planning accounts for the versions and configurations your team intends to operate.
Deployment planning
Bring your environment, and we will map the deployment to it.
Identity provider, secret store, Kubernetes distribution, network zones and connectivity model. A short session is usually enough to establish which deployment model fits and what has to be prepared.