CraftBot is an open-source agent. You can clone it and run it on your own machine today. craftbot.live exists for one reason: most people who want a 24/7 agent do not want to own a server, keep a process alive, and apply updates. So we run it for them.
This post explains how that actually works. Not the marketing version, the real one: what runs where, what we store, what we refuse to store, and the rules we wrote to keep your data private and your agent safe.
Two halves: a control plane and a box
craftbot.live is split into two systems that trust each other as little as possible.
The first is the dashboard: the website you log into, backed by an API and a Postgres database. It handles accounts, billing, instance lifecycle, and usage accounting. It does not run any agent code.
The second is the hosting platform: the machines where agents actually live. Every CraftBot instance is one Docker container. When you create an instance, the dashboard asks the platform for a container sized to your plan, records the container's id and URL, and does nothing further. A reverse proxy (Traefik) gives each container its own subdomain with its own TLS certificate, so your agent has a real, private address on the internet.
The container runs the exact same agent runtime as the open-source CraftBot repository. There is no hosted fork of the agent logic. The only addition is a small module called network_interface, which is the single door between your container and our dashboard. Everything it does is described below, and if you self-host, that module simply stays dormant.
Rule 1: the dashboard never stores your data or your agent's memory
This is the most important design rule in the system, and we enforce it structurally, not by promise.
Everything that makes your agent your agent lives inside your container: its memory (a local vector database), its task list, its event history, its files, its learned skills, its settings. None of that is written to our Postgres database. Our database stores exactly three kinds of things: who you are (profile and plan), which instances you own (name, region, status, container link), and usage records for accounting.
When the dashboard shows you what your agent is doing right now, it is not reading a database. It calls into your container over an authenticated endpoint and asks for the live state. The container answers from memory. When you close the page, that data is not stored anywhere.
There is one honest exception: the instance row caches a single word (idle, thinking, working, waiting, or error) so your dashboard's instance list can render without waking every container. That word is written by the container's heartbeat, which fires every 30 seconds. We deliberately do not persist things like uptime counters. Uptime is stale the moment you store it, so we compute it live or not at all.
The practical consequence that you have to bear: if you delete your instance (by accident or not), there is no shadow copy of your agent's memory sitting in our database, because it was never there. That cuts both ways, and we prefer it that way: a platform that cannot recover your data is also a platform that cannot read, mine, or train on it.
Rule 2: power off is a pause.
The dashboard has a power button, and it does what a laptop lid does, not what a demolition crew does.
Stop freezes the container's process. The container keeps its id, its URL, its environment, its resource allocation, and its entire disk. Memory files, workspace files, learned skills: all still there, just not executing.
Start resumes the same container. Nothing is re-provisioned, nothing is restored from backup, because nothing was destroyed. Your agent picks up with the same memory it had when it went to sleep.
Delete is the only destructive operation, and it is honest about it: the container and its workspace are destroyed on the platform, unrecoverable. On our side we keep a record marked as deleted (with the container link and secrets removed) so your past usage records stay attributable for billing. We tell you this in the confirmation dialog because there is no undo.
An instance moves through four platform states: provisioning, running, stopped, error. Note that these are separate from the agent-activity word above. The platform knows whether your container is executing; only the agent knows whether it is thinking.
Rule 3: isolation is per-container, with hard limits
Every instance is its own container with its own resource ceiling, set at creation from your plan: CPU cores, memory, and process count are enforced by the container runtime as hard limits, not suggestions. A runaway loop in someone else's agent cannot eat your CPU.
Auth is split into two completely separate trust paths:
- You authenticate to the dashboard with your account session. Every API query is scoped to your user id; there is no route that lists or touches another user's instances.
- Your container authenticates to the dashboard with its own per-instance secret, generated at creation, never returned by any API. That is all a container can do: report its own usage and heartbeat as itself. A container cannot read your account, your billing, or any other instance.
Opening your agent's UI crosses domains (the dashboard and your container live on different domains, so cookies do not carry over). The dashboard creates a short-lived signed token, valid for 12 hours, and the reverse proxy checks it on every single request to your container via forward-auth. Logging out updates a timestamp on your profile, and every token created before that timestamp becomes invalid immediately. There is no "old tab that still works" problem.
Rule 4: locks are soft, and they unlock themselves
Managed LLM usage has per-plan quotas. Here is what happens when you hit one, because this is where most platforms get user-hostile: your container does not stop. A usage lock pauses managed LLM calls only. Your agent keeps running, your session stays alive, your files and memory stay warm, and bring-your-own-key calls keep working because they never route through us in the first place.
Locks release themselves. As soon as you are back under your quota, the next enforcement pass clears the lock without a support ticket. Enforcement runs after every usage report and every heartbeat, one at a time per account, so concurrent reports cannot conflict.
Per-plan rate limits are sent to the container on every heartbeat and enforced inside the agent with a sliding window. If the dashboard is unreachable, the agent keeps working without limits instead of shutting down. An offline control plane should degrade accounting accuracy, never your agent.
Rule 5: the hosted agent must stay boring
Hosted CraftBot runs the same code as open-source CraftBot, plus one extra module and four small hooks. The hooks do three jobs: report LLM usage, send a heartbeat, and set default settings on first boot so a new container skips onboarding. We only set defaults. If you change a setting, we never overwrite it.
We keep this difference small on purpose. It means hosted and self-hosted agents are the same software, so skills, MCP servers, and Living UI behave identically in both. It means you can migrate in either direction without changing any configuration. And it means old container images keep working when we release new dashboard features: an agent that has never heard of rate limits simply ignores them and still honors usage locks.
What privacy, security, and safety mean here
These three words get thrown around loosely, so here is exactly what each one means in this system.
Privacy. Your agent's memory, files, chats, and learned skills exist in one place: your container. We do not copy them, index them, or mine them, and we cannot train on data we never hold. If you bring your own API key, those LLM calls never reach our servers at all: the filter runs inside your container, in the open-source network_interface module you can read, and only managed-provider calls are ever forwarded to us. And when you delete an instance, the workspace dies with it. There is nothing left over to leak.
Security. One container per agent with hard resource limits. A unique secret per container that no API ever returns, so a container can only authenticate as itself. TLS on every agent subdomain. Forward-auth on every single request into your container, short-lived access tokens, and instant revocation of all tokens the moment you log out. The dashboard-to-container proxy refuses to follow redirects, so even a compromised container cannot steer the dashboard into fetching internal endpoints. Trust boundaries are structural, not procedural.
Safety. Failure modes are chosen so that your agent survives ours. If the control plane goes down, your agent keeps working. If you hit a quota, the lock pauses managed LLM calls but never kills your container or your session. If an old container image meets a new dashboard feature, it ignores what it does not understand and keeps honoring what it does. And the agent's blast radius is its own sandbox: what you give it permission to touch is all it can touch.
Summary
The dashboard stores account data and usage records, nothing else. Each agent runs in its own container and keeps all of its data there. Stop pauses the container, start resumes it, delete destroys it. Calls made with your own API key never pass through our servers. Hitting a quota pauses managed LLM calls but never stops your agent. The hosted runtime is the same code as the open-source one.
If you want the always-on agent without the server, start free. If you want to run it yourself, the repository is open, and the comparison of both paths is here. Either way it is the same CraftBot.