Hanzo Cloud
The AI‑native cloud.
Run models, agents, applications, data and infrastructure through one operating plane.
Kubernetes-native. Fully observable. Open source. Run it on Hanzo infrastructure or infrastructure you control.
GPUs · Functions · Containers · Databases · Observability · One API

One cloud for the whole AI application.
Not a model API beside a container host beside a database beside a tracing vendor. One system, with the parts already introduced to each other.
- ModelInference, embeddings, routing, fallbacks.
- AgentTools, memory, sandboxes, orchestration.
- ApplicationFunctions, containers, machines, endpoints.
- DataRelational, vector, objects, cache.
- InfrastructureClusters, networking, regions, capacity.
- OperationsIdentity, secrets, traces, billing.
Everything shares the same organization, project, identity, policy, usage and operational context.
One runtime for every kind of work.
The same plane, held for a millisecond or held for a month. What changes is how much of a machine the work needs, not what you have to learn.
Functions
Scale to zero between calls.
Containers
Your image, deployed and addressable.
Sandboxes
Isolated shells for agents and untrusted code.
Machines
A whole machine, by the second.
GPUs
Accelerators attached to any of them.
Kubernetes
The substrate all of it runs on.



The cloud is bigger than one provider.
One control plane, different infrastructure underneath it. The API, the console, the identities and the bill do not change when the machines do.
Hanzo Cloud
Capacity we operate and meter, provisioned by the call.
Your own cloud account
Your credentials, your machines, the same control plane over them.
Your own cluster
Attach Kubernetes you already run and address it like any other.
Machines, GPUs, clusters and Kubernetes are one surface whichever of those it lands on. Visor is the runtime underneath them, and it meters every provider against the org that asked.
Compute across your own accountsEvery model. One cloud interface.
Let Enso choose when you want the best answer for the job. Name a model when you want exactly that one, every time. Run open weights when you want to hold them yourself.
Whichever you pick, auth, budgets, routing, fallbacks, usage and observability stay in one system — so changing your mind about a model is a string, not a migration.
The data primitives AI applications actually use.
Not one database with an extension bolted on. Each primitive is the right shape for the job, and they share a project, a key and a bill.
Vector
Embeddings stored and searched where they are used.
SQL
Relational, per project and per tenant.
KV
Cache and queues at request latency.
Object Storage
Objects, signed URLs, lifecycle rules.
Datastore
Columnar analytics over everything you collected.
Base
An application backend — records, rules, realtime.
DocDB
Documents on the MongoDB wire protocol.
Memory
What an agent is allowed to remember between runs.
Everything connects without becoming your problem.
Services find each other. Traffic reaches them over TLS on a name you chose. The edges are closed until you open one.
The gateway fronts every API, DNS answers for your names, and routing between services is something the cloud does rather than something you write.
The networking planeSee the entire system, not separate products.
One request, from the edge through an agent, a model, a tool, a database and a function — and what every hop of it cost.
One trace. End to end.
Logs, metrics, traces, evaluations and spend are read from the same request, so “why was that answer slow” and “why was that answer expensive” are the same question with the same answer.
Security is part of the cloud.
Every person, agent and workload has an identity. Permissions follow the resource rather than the caller. Secrets stay scoped to the environment that needs them. Actions stay attributable to whoever took them.
None of that is a product you add afterwards — an agent gets an identity because it runs here, and the trail is written because the call went through the same door as everything else.
How identity, keys and audit workOne API. Every capability.
- api.hanzo.ai/v1/models
- api.hanzo.ai/v1/agents
- api.hanzo.ai/v1/functions
- api.hanzo.ai/v1/sql
- api.hanzo.ai/v1/vector
- api.hanzo.ai/v1/s3
- api.hanzo.ai/v1/…
Same key. Same organization. Same project. Same policy model. Same usage ledger.
The interface changes. The system doesn’t.
Twelve operations, one key, no glue. Each is checked against the published OpenAPI document on every build, and a beat the document does not carry is dropped rather than drawn.
One org, one afternoon: a spaceship shop that did not exist this morning.
GET /v1/modelsReturns the list of available models from the routing table.
Push code. Get a production system.
No separate build service to wire up. No container registry to stand up. No secret product to buy. No logging to set up afterwards.
What comes back is a running system with an address, a certificate, its secrets, its metrics, its logs and its share of the bill — because those were never separate purchases.
Your cloud shouldn’t be a one-way door.
The platform is open source, and the image we operate is the image you can pull. Same API, same console, same data — on your cluster, in your network, or on a laptop on a plane.
Pay for what runs.
Nothing is billed for existing. A function that was not called and a machine that was not running cost what they did — nothing.
Models
by usage
Compute
by execution
Storage
by consumption
Managed services
by usage
One organization balance and one usage ledger behind all of it, so every line traces back to a request somebody made.
Every plan and every rateBuild on a cloud designed for AI.
Models. Agents. Compute. Data. Security. Observability.
One API from prototype to production.
Or run Hanzo Cloud on infrastructure you control.