Run the agents yourself.
Manage them from anywhere.
Your personas run on your box, under your own engine logins, holding your secrets and writing to your disk. klingbar.com is the management surface above them: it stores public keys only, relays sealed credentials it cannot open, and shows what your box reports rather than what it wishes were true.
What self-hosted means for agents
Self-hosted means the process that runs the model, holds the credentials, and writes the output runs on hardware you control. It is a claim about where the work sits, not about where the buttons are, which is why a browser-based management surface and a self-hosted agent are not a contradiction.
There are four surfaces an agent platform can leak through, and they are worth separating because a vendor can be clean on one and not the others.
Prompts. What you asked the agent to do, including the internal context it needed to do it. Credentials. The tokens and keys the agent uses on your behalf. Outputs. The work it produced and the files it touched. Control. Who can make it act — and, when the platform and the machine disagree, which one wins.
Ask about each one separately. "Self-hosted" on its own answers none of them.
The box on your machine, the record in the browser
The box is a Linux machine you control — a small server, a VM, or a spare computer — running one small daemon that serves every crew on it. The daemon holds the engine logins, runs the personas, owns their working directories, and dials out to klingbar.com over HTTPS, which carries its Slack messages too. Nothing dials in, so nothing has to be exposed to the internet.
klingbar.com holds your account, each crew's configuration, prompts, and standing rules, the queue of commands for the box, and the record of what the crew did. It is where a person reads what happened and decides what happens next. It is not where the work runs, and the only credential it can open is each Slack workspace's bot token, which it keeps encrypted.
Every request from the box is signed with the box's own Ed25519 key over the method, the path, a timestamp, and a hash of the body; a timestamp more than five minutes off is refused. klingbar.com stores only the public half, so a database leak forges nothing.
Revoking a box needs no secret: klingbar.com simply stops accepting its key.
What crosses, and what never does
Commands, from a closed list. klingbar.com can send a box one of 17 verbs — run a task, pause or resume a persona, decide a card, answer a question, move a crew to another box, upgrade, and a few more — each with a closed set of parameters. The browser never composes a command line; the box builds the argument list itself from a verb it recognizes.
The record, which the box sends. Run records with their verdicts and spend, cards, questions, learnings, digests, health checks, box health, and each run's transcript — the prompt it was given and what it printed — plus, for a crew's marketing persona, focus-group transcripts, syntheses, and experiment snapshots. A transcript is exactly what the run printed, so keep secrets out of a persona's output as you would out of any log.
Sealed envelopes. A secret you enter on klingbar.com is encrypted in your browser to your box's own public key before it leaves the page — X25519, HKDF-SHA256, and AES-256-GCM, the same construction byte for byte as the box's. The field holding the value has no name, so a browser that cannot seal sends nothing at all. klingbar.com relays the ciphertext and deletes it once the box confirms.
Slack, sealed to the box. Klingbar's Slack app receives your workspace's messages and button taps on klingbar.com, which seals each one to the box it is for and deletes it once the box collects it, or after 24 hours if it never does. The box's replies go back the same way: klingbar.com posts them with the workspace's bot token, which it keeps encrypted, and lets each crew post only in its own channels. The box holds no Slack token and still only dials out. A crew still on its own Slack app keeps its Socket Mode connection and its two tokens, sealed to the box like any other secret.
What never crosses: private keys, the secrets the box has opened, and your engine logins. No verb has a slot to put a key in.
One command, no Docker, no sudo
Pairing is one line you copy from klingbar.com. The installer checks what it downloads against the published checksums, and against their signature when klingbar.com publishes a signing fingerprint and ssh-keygen is installed, then sets up the daemon — a Python 3.12 package in its own virtualenv — and pairs it with the code from the page. The page waits for the box to check in and says waiting, claimed, or expired.
Where systemd --user exists, the installer adds a user unit with a watchdog that restarts the daemon if it stops. Where it does not, you run crew daemon in the foreground, and nothing restarts it if it stops. A Mac can run the daemon in the foreground for a trial, without the service that keeps it running. After that, what you type on the box is usually each engine's own login. A persona that works in your code repository also needs one crew workspaces --crew <slug> and read access to the repository, and a tool it reads through a command-line login, such as gcloud or the aws CLI, is signed in on the box.
$ curl -fsSL https://klingbar.com/install.sh \
| sh -s -- --pair KB-XXXX-XXXX
If no release is published, the endpoint answers with a one-line script that exits and says so, never a broken install.
It upgrades itself, after a wait you can refuse
A box takes new daemon releases on its own, once a signed release has been advertised for 30 minutes — a window in which a bad one can still be pulled. The new version is downloaded, verified, and self-checked while the old one keeps running; only then does the box switch over.
To hold a box where it is, set auto_upgrade = false under [box] in its box.toml, and upgrade it from its page on klingbar.com when you choose. A release that changes the daemon's dependencies is never taken automatically; it waits for that one upgrade from you.
- signed
- klingbar.com checks the release signature before it offers a release at all.
- digest
- The box checks the download against the release's checksum before unpacking it.
- 30 minutes
- The release must be advertised that long first.
- checked
- The new tree runs its own self-check while the old one serves.
- pinned
auto_upgrade = falseholds the box until you upgrade it.
Some things only the machine does
There is no wire verb for starting or stopping the daemon. A web page cannot start a process on a machine whose process is not running, and it has no business stopping one that is; starting and stopping happen at the box. So does the final say on configuration: the daemon's own loader checks every version klingbar.com sends, and a version it rejects is reported back with the error while the last good one keeps running.
The web shows the same restraint. A box that stops checking in reads stale after five minutes, anything the box did not send reads "not reported" rather than zero, and a version the web cannot compare never reads up to date.
If you can reach the box, you can always take it back.
Three ways to run an agent
| Fully hosted | Self-hosted box | Fully local | |
|---|---|---|---|
| Prompts and context | The vendor's servers | Written on klingbar.com, run on your machine | Your machine |
| Credentials | The vendor's vault | Your machine, sealed in transit | Your machine |
| Outputs and files | The vendor's storage | Files on your disk; reports in Slack; transcripts on klingbar.com | Your disk |
| Who can make it act | The vendor's console | You and your approvers, in Slack, in a browser, or at the box | Whoever is at the terminal |
| Manage it from a phone | Yes | Yes | No |
| Survives the vendor going away | No | The personas keep running on their last configuration; the web does not | Yes |
| Approval trail across a team | Yes | Yes | Shell history, at best |
Fully local is the strongest privacy position and the weakest operational one: nothing is shared, and nothing is reviewable. Fully hosted inverts that. The self-hosted box exists because the two properties people actually want — the work stays here, and a colleague can see what happened — do not have to be traded against each other.
Related reading: how a credential is sealed to a box, what an approver is asked to decide, and running many crews on one box.
Frequently asked
What does self-hosted mean for AI agents?
It means the process that runs the model, holds the credentials, and writes the output runs on hardware you control. Management can still live in a browser — what makes it self-hosted is where the work and the secrets sit, not where the buttons are.
What does Klingbar store about my agents?
Public keys, each crew's configuration, prompts, and standing rules, and the record the box sends: runs with their transcripts, cards, questions, learnings, digests, and box health. It stores no private keys, and it cannot open the sealed credentials it relays. For Slack it keeps the workspace's bot token encrypted, and holds each Slack message only sealed to your box's key until the box collects it.
How does a credential reach the box?
Your browser seals it to the box's public key before it leaves the page. Klingbar relays the envelope as an opaque parameter, only the box holds the private half needed to open it, and the envelope is deleted once the box confirms it arrived.
Do I need Docker or a service manager?
No Docker and no sudo. The daemon is a Python 3.12 package in its own virtualenv, installed with one command. The box is a Linux machine: where systemd --user is available the installer adds a user unit with a watchdog, and elsewhere you run crew daemon in the foreground. A Mac can run the daemon in the foreground for a trial, without the service that keeps it running.
Does my Slack traffic go through Klingbar?
Yes. Klingbar's Slack app receives your workspace's messages and button taps, seals each one to the box it is for, and deletes it once that box collects it. The box's replies reach Slack through klingbar.com, which lets each crew post only in its own channels. The bot token is stored encrypted, and the box itself never holds a Slack token.
Keep the work. Share the view.
Klingbar is free during early access: you bring the machine and your own engine logins. What that means.
Request early access