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 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.
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.
Own deployment, volume, and network policy per instance.
Shared billing and capacity, separate logins.
We run this fleet in production today.
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.
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.
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.
Patching and base-runtime updates, health reconciliation, node pressure, stuck-pod recovery, and version reconciliation across the fleet.
The agents, workspaces, and model choices. Bring your own provider keys; export any time. Same open-source OpenClaw runtime.
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. |
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.
What a buying committee asks
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.
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.
No. Billing and capacity are shared, but instance visibility is creator-scoped — each member sees the instances they created.
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.
Where to go next
Give your team isolated agents, not a shared box.
Per-instance isolation, one account, and no one on call for the infra.