There has been a sharp rise in interest in running AI assistants on your own hardware rather than inside somebody else's platform. The appeal is obvious: stored state and credentials stay on your hardware, there is no per-seat pricing, and you are not one policy change away from losing a workflow you depend on. One qualification worth making early, because it is widely overstated: self-hosted does not mean offline. Unless you are running a local model, prompts still go to a provider, and anything reached through a chat platform still travels through it.
The part that gets undersold is that most of the difficulty is not AI at all. It is ordinary infrastructure work wearing an interesting costume.
The install is the easy part
You can usually get an agent running in an evening. Whether it is still running in three months depends on decisions that have nothing to do with models.
Where it lives. A laptop is not a host. An agent on a machine that sleeps is an agent that silently stops doing scheduled work, and you will not find out from an error: you will find out when you notice something did not happen. A small always-on server is the usual answer, and you should size it for sustained memory rather than peak CPU.
What it can reach. This is the one that matters most, and it is the one people rush. An agent holding credentials is a credential store with opinions. Every integration should get its own key, scoped to the narrowest permission set that makes the workflow function. The temptation to connect one admin-level token because it is faster is very strong and very expensive.
What survives a restart. Find out which directories hold configuration, history, and credentials, and put them on persistent, backed-up storage before you need them. Losing the container should not mean losing the assistant.
Start it read-only. Actually do this.
The instinct is to grant broad capability and see what happens. That is precisely backwards.
Run the agent with read access only for a meaningful period first, and watch what it would have done. Almost all of the useful calibration happens here, and it costs nothing when the agent is wrong, which it will be, in ways you did not anticipate, on inputs you did not think to test.
Then widen in order:
- Read-only, observed
- Reversible actions, unattended
- Irreversible actions, behind an approval gate
Sending, publishing, paying, and deleting stay in category three far longer than feels necessary. Weeks, not hours.
Bound it with permissions, not instructions
A prompt telling an agent not to do something is a preference, not a control. If the credential can perform the action, assume it eventually will, through a misread instruction, an unusual input, or a retry loop nobody predicted.
Real controls look like:
- An explicit allowlist of permitted actions, with everything else denied
- Credentials scoped to exactly those actions
- A spend limit, because an agent looping on a failure can spend a startling amount overnight
- A defined stop condition: on uncertainty or repeated error, halt and escalate to a named human
That last one matters more than it sounds. An agent with no defined failure path retries. An agent that retries against a broken dependency is just an expensive way to generate load.
Log the reasoning, not only the result
When an agent does something unexpected, the output tells you what happened. Only the trace tells you why. Retain enough to reconstruct a decision after the fact, because the alternative is shrugging and hoping it does not recur.
Monitor it like a service, because it is one
Uptime checks, log retention, an update cadence, and an alert when it stops responding.
An agent that quietly died is worse than no agent at all, because you carry on assuming the work is happening. This is the single most common way self-hosted setups fail, not dramatically, just silently, until someone asks why nothing has been processed since the 14th.
Is it worth it?
If data residency matters, if you want independence from a vendor's roadmap, or if volume makes per-seat pricing painful, then yes, clearly.
If the motivation is mostly curiosity, use a hosted service until a real constraint shows up. Self-hosting is a genuine operational commitment, and the honest version of this advice is that the commitment, not the setup, is what you are deciding on.
Detailed setup guides for OpenClaw, Hermes agents, and the VPS underneath them. Or have it set up and managed for you.