Run the agents yourself.
Manage them from anywhere.
Your bots run on your box, holding your credentials and writing to your disk. Klingbar is the management surface above them: it stores public keys only, relays sealed credentials it cannot open, and renders what your runner 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 control plane and a self-hosted agent are not a contradiction.
There are four surfaces a hosted 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.
Runner on your machine, control plane in the browser
The runner is a daemon on your box. It holds the engine accounts, runs the bots, owns the working directories, and dials out to Klingbar — Klingbar never dials in, so nothing has to be exposed to the internet to make this work.
Klingbar holds the account, the organization's rendered state, the command queue, and the approval trail. It is the place a human reads what is happening and decides what should happen next. It is not a place your work lives.
Every request between the two is authenticated by an Ed25519 signature over the method, path, and body, inside a five-minute window. Klingbar stores only the public half, so a database leak forges nothing.
Revoking a runner is deleting a public key. Nothing about that operation needs a secret.
What crosses, and what never does
Commands, signed. A verb from a closed list of thirty-six, with its parameters. The browser never composes a command line; the runner builds the argument list itself from the verb it recognises.
Snapshots, scrubbed. The runner pushes the state it chooses to publish, carrying handles and short references rather than secrets. A tripwire on the ingest path drops anything that looks like key material rather than storing it.
Sealed envelopes. A credential you paste is encrypted in the browser to your runner's published key before it leaves the page, using an X25519 and AES-GCM construction shared byte-for-byte with the runner's own implementation. Klingbar carries the ciphertext as an opaque parameter. There is no plaintext fallback: if the browser cannot seal, it says so and refuses.
What never crosses: private keys, plaintext secrets, and any credential-shaped value as a command flag. That last one is a property of the vocabulary itself — no verb has a slot to put a key in.
One command, and no service manager
Pairing is one copyable line: fetch the installer, verify it against a published checksum and signature, and hand it the pairing code from the page. The page then waits for the runner to check in, and shows waiting, claimed, or expired — never a green state it invented.
The runner is a single self-contained binary. A watchdog parent supervises a worker child, restart and backoff are an ordinary state machine, and on-disk state makes a crash history readable with no journal to consult. There is nothing to install underneath it.
Boot glue is optional and thin. If you set it up, the command it runs at boot is byte-identical to the one you would type by hand, so a machine started at boot and a machine started by you are the same machine. If you skip it, the runner simply does not come back after a reboot — which Klingbar states as a configuration fact rather than colouring as a warning.
curl -fsSL https://klingbar.com/install.sh \
| sh -s -- --pair KB-XXXX-XXXXChecksum always, signature when a fingerprint is published. Nothing published means the endpoint answers with a script that exits, never a broken install.
The box wins
A remote control plane that cannot be overruled is a single point of failure wearing a convenience costume. Klingbar is built the other way round: an operator at the runner's own command line can clear a waiting command or veto it outright, including commands that rewrite the organization's chart and the command that would replace the runner binary itself.
There is deliberately no wire verb for starting the daemon, because a console cannot start a process on a machine whose process is not running. Starting and stopping are things you do at the box, by derivation rather than by policy.
The same principle governs what the console displays. A snapshot that has gone stale reads as stale; a document the runner never sent reads as not reported rather than as zero; a version it cannot compare never reads as 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 runner | Fully local | |
|---|---|---|---|
| Prompts and context | The vendor's servers | Your machine | Your machine |
| Credentials | The vendor's vault | Your machine, sealed in transit | Your machine |
| Outputs and files | The vendor's storage | Your disk | Your disk |
| Who can make it act | The vendor's console | You, 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 bots keep running; the console 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 runner 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: an org chart written as code for how a runner's organizations are declared, and human approval workflows for what a person is asked to sign.
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, the scrubbed snapshots your runner chooses to push, the commands you issue, and the approval trail. It stores no private keys, and it cannot open the sealed credentials it relays.
How does a credential reach the runner?
Your browser seals it to the runner's published public key before it leaves the page. Klingbar carries the resulting envelope as an opaque command parameter, and only the runner holds the private half needed to open it.
Do I need Docker or a service manager?
No. The runner is one binary that supervises itself: a watchdog parent, a worker child, and on-disk state that makes a crash history readable without a journal. Boot glue is optional, and when you use it the box starts with the same command you would type by hand.
What if the control plane is wrong about my box?
The box wins. Its own command line can clear or veto the gated commands, and Klingbar renders a state it cannot verify as unknown or stale rather than green.
Keep the work. Share the view.
Klingbar is in early access. Join the waitlist and we'll reach out as capacity opens.
Join waitlist