Key takeaways: For most teams, Bob's managed cloud is the right answer. For teams with a real residency or architecture gate, Bob's Enterprise deployment runs the application and data plane inside your VPC. It is a guided deployment today, not a self-serve download button, and third-party model and connector traffic still has to be accounted for honestly.
The receipt under every finished run, copied verbatim from a production run. Ask “what ran this week” and Bob adds them up.
The conversation that ends most AI evaluations
It usually happens in the third meeting. Security asks: "Where does our data go?" And for nearly every AI teammate on the market the honest answer is "to us, and to our model provider, and here's our SOC 2." Sometimes that's enough. In healthcare, finance, legal, government, and increasingly in any European procurement process, it often isn't, and no feature list changes that. The product is disqualified on architecture.
We built for that conversation. Bob's core application components are containerized and can run inside your VPC with a database and disks you operate. It is the same product shape as our cloud, including Slack, memory, schedules, approvals, receipts, and isolated task execution. We deliver and validate the Enterprise deployment with your team today; the polished self-serve installer and image-distribution channel are still being finished.
What can still leave your network
A VPC is a boundary, not a magic trick. Bob's own application data stays in infrastructure you operate, but an honest architecture review should account for three outbound paths:
- License usage. A daily report identifies the license, month, run count, credit total, and seat count. It contains no prompts, connector data, or task output.
- Model calls. If your chosen model endpoint is outside the VPC, prompts and responses reach that provider under your key and agreement. A private model endpoint keeps that path private.
- Connected apps. OAuth and API traffic reaches the apps you choose and, for catalog connections, the connector service used to broker that access. A deployment review maps those subprocessors instead of hiding them behind the word "self-hosted."
What does not come back to HeyBob is message content, prompts, connector payloads, memory, artifacts, or run output. The license payload is deliberately boring because "trust us" is not a compliance posture.
What you give up (honesty section)
Self-hosting is a real operational commitment, and pretending otherwise would be marketing. You run the infrastructure, backups, network policy, and upgrades with our support. You bring the relevant model and connector accounts. If you don't have an ops team or a contractual reason to own the boundary, the answer is our cloud, and that's most teams. It's why we run one.
Who this is for
Teams with data-residency requirements. Regulated industries with an architecture-review gate. Companies whose own customers contractually demand in-tenancy processing. And, frankly, anyone who wants leverage in a vendor negotiation: a product you could take in-house is a product that has to keep earning your renewal.
FAQ
Is self-hosted Bob feature-complete?
The core agent, Slack surface, approvals, run history, schedules, memory, and admin UI use the same code. Connection coverage depends on the provider accounts and network paths your security team allows, so we map the exact workflow during the deployment rather than promise every cloud integration unchanged.
What happens if we cancel?
Your instance keeps booting and your data stays fully readable. New work pauses until the license renews. Nothing bricks, nothing is deleted. It's your infrastructure; we just stop selling you updates.
What are the prerequisites?
Container infrastructure, Postgres with the required extensions, a Slack app, model access, outbound access to any approved connector providers, and an HTTPS-reachable Slack endpoint. Today this is a guided Enterprise rollout, not a self-serve afternoon install.