Skip to main content

​
What is AgentBees, in one sentence?

An enterprise-safe workspace for running many coding agents in parallel — on your cloud, under your policy, billed by what you actually use. See Why AgentBees for the long form.

​
Why not just use Claude Code (or Cursor / Copilot) locally?

Because one laptop runs one agent. AgentBees runs N in parallel, in isolated sandboxes on your cloud, with team-wide review, audit, and billing. Every diff, every token, every gate — visible to reviewers, tied to a real branch, and merged only on human approval.

​
Who owns the model keys?

You do. Bring your own provider keys (Anthropic, OpenAI, Google, xAI, Kiro) or route every call through your own internal LLM gateway with guardrails. Model traffic never leaves your gateway. AgentBees never holds a provider key on your behalf unless you paste one into Admin → Agent LLM; even then it’s encrypted at rest with a per-org KMS-wrapped DEK.

​
What is a “workspace”?

A locked-down Kubernetes pod created per task. One container per agent, one git worktree, per-task filesystem, per-task egress rules. Destroyed on task-close — the pod is gone, nothing persists on disk.

​
What is the pod boundary — container or microVM?

  • Default: plain Kubernetes container (shares the host kernel).
  • Optional: gVisor sandbox (user-space kernel) if the cluster is provisioned with the runsc RuntimeClass.
  • Optional: Kata Containers microVM for true VM-grade isolation.
Flip via a single env var on the orchestrator (K8S_RUNTIME_CLASS=gvisor or K8S_RUNTIME_CLASS=kata-qemu). We ship container-by-default so a fresh install works on any cluster; production tenants that want a hardened sandbox turn one on.

​
Is egress default-deny?

Egress is default-deny to cluster-internal ranges + allow-list to public internet. Every workspace pod has a Kubernetes NetworkPolicy (enforced by Calico or Cilium) with:
  • Allowed: DNS (UDP/TCP 53), the orchestrator pod (scoped by pod label), and 0.0.0.0/0 minus all RFC1918 ranges (10/8, 172.16/12, 192.168/16, 169.254/16) on ports 443 / 80 / 22 only.
  • Blocked: the app’s Postgres, Redis, Temporal, kube-apiserver, and every other tenant pod. All cluster-internal by definition of the private ranges above.
  • Ingress: deliberately unrestricted — kubelet health probes and the orchestrator’s IDE proxy need to reach the pod.
If your tenant runs an in-cluster LLM gateway (RFC1918 address), the operator adds that CIDR as an extra egress rule on the tenant values file (externalEgressCidrs).

​
Where do repo credentials live while a pod is running?

  • Mint: at pipeline (or task) dispatch, the api mints a fresh GitHub App installation token scoped to just this repo, with permissions contents:write, pull_requests:write, metadata:read, statuses:write.
  • Lifetime: GitHub caps installation tokens at 60 minutes.
  • Delivery: env vars only — PC_GIT_TOKEN, GH_TOKEN, GITHUB_TOKEN. Never written to disk (no ~/.git-credentials, no ~/.netrc).
  • git clone / git push: an inline shell credential helper reads PC_GIT_TOKEN at call time and streams username=x-access-token \n password=<token> to git on stdin — zero on-disk artifact.
  • Destruction: pod destroyed → token gone from memory. Nothing to revoke.
Known gap: pipelines that take > 60 minutes end-to-end will hit HTTPS token invalid or expired on later stages. A mid-flight token refresh is spec’d and not yet built. Most pipelines finish inside the hour; long ones may need the fix.
PAT credentials (if your org configured a PAT instead of the GitHub App) have no natural expiry — they live as long as the PAT is valid in repo_connections.

​
What is the tenancy model?

Three deployment SKUs: Row-level (Shared pool) is the default. Dedicated namespace and cluster SKUs add per-tenant secrets, egress CIDR carveouts, and cost attribution.

​
How is compute isolated between tenants?

  • Row-level Postgres RLS on every app table — every query is org-scoped by a session GUC (app.current_org), enforced by PostgreSQL policies.
  • Per-workspace K8s pod in either the shared workspaces namespace or a per-tenant namespace (SKU-dependent).
  • NetworkPolicy on every workspace pod (as above).
  • Optional sandbox class (gVisor / Kata) on top of the container boundary.

​
What runs on your own cloud vs ours?

  • AWS EKS today — you own the cluster; the AgentBees control plane runs in your namespace under your billing.
  • GCP + Azure on the roadmap.
  • BYO-compute runner on the backlog for orgs that want the agent pods inside their own VPC even if the control plane runs elsewhere.
Model traffic can be routed through your own gateway so tokens and prompts never leave your perimeter.

​
What’s the pricing model?

Three modes, all coexisting per-org:
  • Flat monthly plans — Free (no pipelines), Pro (10 pipelines/day), Team (20 pipelines/day). Concurrency caps + IDE workspace caps per plan.
  • Pay-per-use metered (Enterprise) — a prepaid wallet in cents; every pipeline stage burns wallet tokens at the model’s list rate.
  • Add-ons — purchase extra vCPU / RAM per-task (per-day or per-month) on top of a flat plan; the extra capacity is drawn from an org-wide pool.
See Billing overview for the pricing table + wallet mechanics.

​
Can I self-host?

Yes — the full stack ships as a Helm chart (infra/helm/code-parallel/). Values files for values-microk8s.yaml, values-dev.yaml, values-prod.yaml cover the standard modes; per-tenant values (infra/helm/tenants/, infra/helm/pool-tenants/) show the dedicated-namespace and dedicated-cluster SKUs. Terraform modules for AWS EKS (with GCP / Azure sibling directories staged) provision the underlying cluster.

​
What happens on cancel / discard?

  • Cancel a running task — pod destroyed immediately, worktree discarded, git branch left in place (no auto-push of half-baked code).
  • Discard a pipeline — pipeline marked terminal, all pending stages become no-ops, task rows kept for audit (no longer count against workspace slot or plan quota).
Nothing lands on your default branch without an explicit human approval step.

​
Where does audit live?

Every pipeline run captures a per-stage transcript (turns, tokens, tool calls, MCP servers) and a raw console replay. Both live in Postgres, scoped to the org by RLS, viewable at Admin → Agent runs (or /pipelines/<id> for a single run). See Flow for the list view and how to jump to a specific stage’s audit panel.

​
Comparison — where does AgentBees fit?

​
More?

Why AgentBees

The pitch and the five differentiators.

Onboarding

Sign in, connect a repo, run your first agent.