Managed hosting for an AI assistant that is free to download and expensive to keep upright
OpenClaw is open source, so getting one running is a weekend. Keeping one running is the actual product — and the reason this exists.
- Product
- OpenClaw Direct
- Sector
- Agentic AI infrastructure
- Running since
- 2026 — present
- Stack
- Ruby on Rails and PostgreSQL for the control plane; each instance runs as its own Kubernetes workload
- Our role
- Built it, run it
The problem
OpenClaw is free to download, and that is exactly what makes it expensive. What separates an assistant running on a laptop from one a business can depend on is not features. It is patching, monitoring, credential rotation, upgrade paths that do not lose state, and somebody awake when it stops at three in the morning.
None of that appears during the evaluation. A team picks the assistant on the strength of a demo and finds out afterwards that it has taken on a second job, usually assigned to whoever set it up first.
What we built
A private instance per customer, isolated rather than a tenant on somebody else's, reachable from Telegram, Slack, WhatsApp or Discord. Most deployments finish in two to five minutes. Monitoring, patching and updates are ours.
The customer brings their own Anthropic API key. That keeps the relationship with the model provider theirs, and it means usage arrives on a bill they can read instead of a line item they have to take our word for. It is the first question a serious buyer asks, so it is settled before they have to raise it.
The second question decides whether an agent deployment survives contact with a real company: where the instance's knowledge lives, and whether the customer's own people can read it.
An instance's state belongs to that instance. It is not a row in a shared table with a tenant column beside it, which is what a careful buyer is really asking about. It is backed up on a schedule, on demand when somebody wants a copy before trying something, and automatically before an instance is torn down — that last one being the case that matters, because it is the one nobody thinks to ask for until it is too late to ask.
The API key is the deliberate exception. We hold a digest of it, not the key itself, so we cannot show it back to you and neither can anyone who reaches the database. The copy you paste in stays the only copy you have.
What it takes off you
The work does not disappear. It moves. Patching, monitoring, credential rotation and the upgrade that must not lose state are ours; what is left on the customer's side is a signup and a key they were already paying for.
The claims worth holding us to are the ones above — a private instance, a backup taken before anything destructive happens, a key we cannot read back. Each of those can be checked. An uptime percentage from a product this young could not be, which is why there isn't one here.
Operating it since 2026
This one is new. The first commit is February 2026, so the operating record here is months, not years. What stands behind it is the record on the older products, not its own runtime.
That is worth saying plainly rather than dressing up. Managed hosting for someone else's open-source project is a promise about the years after the sale, and this product has not had years yet. The other two studies have had eight years and three, and they are the ones to read if the question is whether we are still here when the upstream project changes something it should not have.