For engineering teams

Managed vs self-hosted AI agent infrastructure for teams

For a team, the two questions that actually matter are tenant isolation and who's on call when the infra breaks.

In one line

Each Lobsterland agent runs as its own isolated Kubernetes instance — dedicated ReadWriteOnce volume, per-instance network policy, encrypted credentials, no public IP — and a business account shares billing and capacity across your team without sharing logins.

Isolated

Own deployment, volume, and network policy per instance.

One account

Shared billing and capacity, separate logins.

In production

We run this fleet in production today.

The buyer question: isolation

Hard tenant isolation, by default

  • Own deployment + volume: each instance is its own Kubernetes deployment with a dedicated ReadWriteOnce PVC — state is not shared between instances.
  • Per-instance network policy: pod-to-pod and private-network access is blocked except explicitly allowed same-owner paths.
  • Dedicated namespace and resource limits: per-tier CPU and memory limits keep one instance from starving another.
  • Encrypted at rest: provider keys and channel tokens are AES-256-GCM encrypted, kept off the runtime.
  • No public IP: instances aren't reachable from the public internet; browser access (CDP/VNC) is gated behind the backend auth proxy.
The honest framing

A poorly isolated self-hosted agent — several agents sharing one box with no boundary — is a single shared blast radius. A managed platform with hard per-instance isolation removes that coupling, so one agent's bad day can't take the others down.

Read the security model →

Reliability you'd otherwise build

Who's on call for the agent fleet?

Self-hosting a fleet means owning the failure classes teams underestimate: node memory pressure, stuck pods, silent upgrades that drop scheduled jobs, and version drift. Managed hosting absorbs them with daily rollouts, health reconciliation, and patching — so nobody on your team wears the pager for agent infrastructure.

What we absorb

Patching and base-runtime updates, health reconciliation, node pressure, stuck-pod recovery, and version reconciliation across the fleet.

What your team keeps

The agents, workspaces, and model choices. Bring your own provider keys; export any time. Same open-source OpenClaw runtime.

One account for the whole team

Business accounts, without shared logins

Capability How it works
Invitations The owner invites members by email; each signs in with their own Google account — no shared password.
Shared capacity Purchased capacity belongs to the account and is counted across all members.
Billing Owner-managed. Members see billing as read-only and can't change capacity or add-ons.
Instance visibility Creator-scoped: members see the instances they created, not each other's.

More on business accounts →

Runtime choice

OpenClaw or Hermes — your team picks

Run the full OpenClaw runtime, or the Hermes runtime for browser chat, Telegram, Slack, logs, and bring-your-own model keys. The two have different surfaces — see the head-to-head before you choose.

Compare OpenClaw vs Hermes →

FAQ

What a buying committee asks

How are AI agent instances isolated from each other?

Each instance runs in its own Kubernetes deployment with a dedicated ReadWriteOnce volume, a per-instance network policy, and encrypted credentials — no shared runtime, no public IP.

Managed or self-hosted — which is more reliable for a team?

Managed removes the failure classes teams underestimate — node memory pressure, stuck pods, silent upgrades, version drift — by absorbing patching, health reconciliation, and rollouts, so no one on the team is on call for agent infra.

Can my whole team share and manage agents under one account?

Yes. A business account shares billing and purchased capacity across members who each sign in with their own Google account. Billing is owner-managed; members see it read-only.

Do members see each other's instances?

No. Billing and capacity are shared, but instance visibility is creator-scoped — each member sees the instances they created.

Is a managed AI agent platform secure enough for production?

Isolation (dedicated pod, RWO volume, and network policy per instance), AES-256-GCM encryption at rest, no public IP, and proxy-gated browser access are on by default.

Ready

Give your team isolated agents, not a shared box.

Per-instance isolation, one account, and no one on call for the infra.

Compare managed vs self-hosted Go to app login See pricing
Cookie preferences