Skip to main content
For an enterprise that needs the strictest isolation — a separate control plane and network boundary, not just a private namespace — the dedicated-cluster tier gives you an entirely separate Kubernetes cluster. Your own VPC, EKS control plane, nodes, database, cache, keys, and app release. Nothing that carries your data or compute is shared with any other customer. We operate, patch, upgrade, and monitor all of it. You just use the app.

​
What you get

This is the top isolation tier. The only thing shared across customers is DNS metadata (a parent domain zone and a wildcard TLS certificate) — which holds no customer data.
There is no cross-tenant data path: no shared database, cache, object store, key, or network. Another customer’s workload cannot reach yours because there is nothing in common to reach it through.
Want isolation without a whole cluster, at a lower cost? The dedicated-namespace tier gives you a private namespace, node group, and database on a shared, fully-managed cluster. Same app, lower floor.

​
Runs in our cloud, managed by us

Your cluster runs in our cloud account — typically a dedicated sub-account just for you, which is both a hard security boundary and the basis for exact, at-cost billing. You don’t manage AWS, Kubernetes, upgrades, or patches; we do.
  • Provisioning & upgrades — your cluster, database, and app are defined as code and rolled out through our fleet automation (canary first, then a staged wave, with health gates and automatic rollback).
  • Patching — EKS versions, node OS/AMI, database minor versions, and the app image are all kept current on a managed cadence within your change windows.
  • Monitoring — every instance is watched centrally, so we see a problem before you report it. Your data stays in your instance; only health signals leave.

​
Logging in

Your instance lives at your own subdomain, e.g. your-company.aws.agentbees.ai.
  • Sign in with your own identity provider (SSO) — Google, Microsoft, Okta, or any OIDC IdP. We map your IdP groups to roles (admin / developer / viewer), so access is governed by your directory.
  • No separate passwords; offboarding a user in your IdP removes their access here too.

​
Monitoring your usage & cost

Every instance has a Billing & usage page (under Admin) showing only your own cloud cost — the exact pass-through figure your invoice is built from:
  • Monthly cost broken down by compute, storage, database, and network.
  • A running total per period.
  • Because your cluster runs in a dedicated cloud account, the numbers come straight from the cloud provider’s Cost & Usage Report for your account — they reconcile to the bill exactly, with no estimates or markups on the pass-through line.
You see only your own numbers. The page is scoped to your instance and enforced on the server — you can never see another customer’s cost, and they can never see yours.

​
Your invoice

The platform fee (a per-seat annual subscription) covers us running, patching, upgrading, and monitoring everything. The pass-through line is exactly what you see on the Billing & usage page — at cost, no markup. Because a dedicated cluster costs more to run than a namespace, that difference shows up in your (at-cost) pass-through, not in a higher fee.
Two views of the same data. Your team sees a single-tenant “Billing & usage” view (only you). Our platform operations team sees a cross-tenant aggregate to produce invoices and watch fleet health — never mixed, never visible to you.

​
Choosing between the two enterprise tiers

Both run in our cloud, are fully managed, and bill the same way — your cloud cost at cost, plus a platform fee.