The same platform, wherever it has to run.

Managed by us, inside your own cloud account, in your data centre, in a sealed enclave, at a remote site, or in a six-litre micro server somebody carries in. It is the same platform in all of them, which is what makes leaving any one of them possible.

See the eight patterns Talk to us about a deployment

What never changes #

Choosing where to run Agentycs is a choice about operating model, not about capability. Every pattern below carries the whole platform, and because it is the same platform each time, moving between them is a change of declaration rather than a fresh purchase and a migration project.

Every capability, every time

Atom's lakehouse and hybrid search, Anima's model serving, the app runtime and its REST and MCP surfaces, durable workflows and the Agent² Software Factory. Deployment changes the address, not the feature set.

One declarative control plane

A single operator reconciles the platform instance, its tenants, its databases, its storage and its applications from custom resources. What you validated in one environment is what runs in the next.

The same interfaces everywhere

An OpenAI-compatible inference API, the PostgreSQL wire protocol and Arrow Flight SQL over the lakehouse, S3-compatible storage, MCP for tools, OIDC and SCIM for identity. Your clients cannot tell where they are.

A supply chain you own

Models are imported once into the private hub and served from storage you control. Application artefacts are content-addressed, signed and attested. Nothing in the serving path calls a vendor at runtime, so nobody upstream is in a position to reprice, deprecate or refuse your workload.

Isolation that is enforced, not promised

Tenant scope is derived server-side from validated session or token state on every request, with row filters and column masks applied on the one shared permission path every query gateway uses.

Observability as standard

Metrics, traces, dashboards and alerts ship with the platform, and every data access is recorded in an audit ledger correlated to the identity behind it.

Eight ways to run it #

They are ordered from the one we operate for you to the one that fits in a backpack. Most organisations end up combining two.

Managed sovereign cloud

We run the platform. You keep the authority over identity, keys and data.

Agentycs operates a platform instance for you on Apex accelerators, in the region you choose. You get the full surface — lakehouse, inference, app runtime, software factory — behind your own identity provider, your own key custody and your own tenant boundary.

Best for Teams that want the whole platform in weeks, without first building an infrastructure practice.

Read the pattern → 02

Private cloud

Your cloud account, your Kubernetes, our platform.

The platform installs into a Kubernetes cluster you own, as a set of declarative custom resources. Your account, your network policy, your storage, your registry. The operator does the rest and keeps doing it.

Best for Organisations with an established cloud footprint and a mandate to keep workloads inside it.

Read the pattern → 03

On-premises

The whole platform in your own data centre, on hardware you own.

Apex servers in your racks, an operator-managed cluster on top, and the full platform above that. Physical custody stays with you, and so does the choice of how much of the operating load you hand back to us.

Best for Organisations whose data cannot leave the building, and who would rather own the machines than rent them.

Read the pattern → 04

Air-gapped

A complete platform with no path to the outside world.

Everything the platform needs lives inside the boundary: the models, their weights, identity, secrets, name resolution, the registry and the build pipeline. Updates arrive as signed media through a transfer you govern.

Best for Classified, regulated and safety-critical environments where connectivity is the risk.

Read the pattern → 05

Edge and remote sites

Inference and apps that keep working when the link to the core does not.

An edge site hosts its own model workers and serves requests locally under the same tenant policy as the core. If the link drops it carries on with the models it has, then reconciles when the link returns.

Best for Ships, rigs, forward sites, factories and clinics — anywhere the network is a variable, not a given.

Read the pattern → 06

Hybrid

Put each workload where its rules say, and keep one control plane over all of it.

Some workloads belong in your data centre and some belong in a managed region. Hybrid places each where it should be and keeps one operating model, one identity, and one place to look when something breaks.

Best for Organisations where different data classes carry genuinely different obligations.

Read the pattern → 07

Multi-site

One platform instance, geo-distributed, able to lose a site.

A platform instance can span data centres. Storage replicates across the zones you nominate, routing sends users to the closest healthy site, and losing a site degrades capacity rather than service.

Best for Workloads where an outage in one location must not become an outage for anyone.

Read the pattern → 08

Agentycs-in-a-Box

Six litres, 400 watts, and the whole platform inside it.

A backpack-sized micro server holding a full-fat 96GB NVIDIA GPU and full server capability behind it. It runs a real Agentycs PlatformInstance, Atom and Anima included, on 400W, and it will run off a battery.

Best for Work that happens where there is nothing to install into, no dependable uplink, and nobody to build either.

Read the pattern →

Compare what actually differs #

Six dimensions separate the patterns. Everything else is common ground, which is why moving between them is a migration of responsibility rather than of software.

The real question is whose on-call rota gets the page at three in the morning.

Pattern	Who operates it Whose on-call rota gets the page at three in the morning.	Where data rests Which storage, in which building, under whose keys.	Connectivity assumed What the platform expects of the network, and what it does without it.	Hardware What the accelerators and nodes are, and who bought them.	How it scales What you add when you need more.	Recovery How the platform comes back, and who brings it back.
Managed sovereign cloud	Agentycs	Platform object storage in your region, or your own S3-compatible backend	Always connected	Apex accelerators we own and operate	Add capacity in the region, then add regions	Multi-zone replication and off-site backups we run and restore
Private cloud	You, with our platform operators alongside if you want them	Your cloud's storage, or your own S3-compatible backend	Connected, with egress under your policy	Your instances and accelerators	Your account's capacity, node pool by node pool	Your cloud's protection model, plus platform backups and restore
On-premises	Your team, or ours under a support agreement	Your racks, in your building	Connected, or deliberately restricted	Apex servers, your own hardware, or a virtualised estate	Add nodes and zones as you buy them	Local backups, spares and a rebuild path you hold
Air-gapped	Your cleared operators	Inside the boundary, and nowhere else	None. Updates arrive as signed media	Apex servers, including sealed and portable options	Add nodes inside the boundary	Local backups, local keys, rebuild from admitted media
Edge and remote sites	Your core team centrally, site staff locally	At the site, plus whatever it replicates back to the core	Intermittent by design	Compact Apex nodes, sized to the site	Add sites; each keeps serving on its own	Serve from the local mirror, then reconcile on reconnect
Hybrid	Split by environment, with one agreed incident path	Per class, in the environment you assigned it to	Authenticated wide-area links between environments	Mixed by design	Scale each side independently	Each environment recovers alone, then rejoins and reconciles
Multi-site	One operator across every site	Replicated across the zones you nominate	Site-to-site over the secure overlay	Consistent classes, sized per site role	Add a zone, then add a site	Lose a site and keep serving, then fail back deliberately
Agentycs-in-a-Box	Whoever is carrying it, with remote support only if you permit a link	In the box	None required. Connected, intermittent or sealed per unit	A six-litre Apex micro server with a 96GB GPU	Add boxes, or join them into one multi-site instance	Spares, local backups and a documented rebuild from carried media

Start from your constraint #

The right pattern is usually decided by one hard requirement rather than by a feature comparison. Find the requirement and the pattern follows. If two lines below both apply, that is the case for hybrid or multi-site, where the platform spans both and stays one thing to operate.

You want it running in weeks: Managed sovereign cloud
It has to stay inside your cloud account: Private cloud
It has to be in your building: On-premises
It cannot touch a network you do not own: Air-gapped
It has to keep working when the link drops: Edge and remote sites
Different workloads carry different rules: Hybrid
Losing a location cannot mean losing the service: Multi-site
Somebody has to be able to carry it in: Agentycs-in-a-Box

Describe your constraint

Where to go next #

Deployment is one of three decisions. The other two are where it runs and what it runs on.