Self-Hosted Does Not Mean Local 🗺️

"Self-hosted" is a reassuring phrase. It suggests everything happens on hardware you control, that nothing leaves the box, that the privacy question is settled.

It is a genuine improvement — but that last part is not automatically true, and pretending otherwise does nobody any favours. This post is an honest map of where data actually travels when you run a private AI agent, and which parts you really do control.

---

🧩 Four Different Things Get Called "Self-Hosted"

Most products described as self-hosted AI — AgentAura included — are the second row. That is worth being precise about.

---

🔍 What the Second Row Actually Buys You

Quite a lot, as it happens:

• Execution is yours. Commands the agent runs, files it reads and writes, and tools it invokes all happen on your machine, under your account, subject to your firewall.
• Blast radius is contained. An agent that goes wrong damages a box you provisioned for that purpose — not the laptop holding your SSH keys, browser cookies and .env files.
• Your working data stays put. Files the agent operates on live on your server unless you send them somewhere.
• You can shut it down. It is your host. You reboot it, firewall it, and delete it on your schedule.

That is a real security boundary, and it is the main reason to do this at all.

---

📤 What Still Leaves the Box

Being equally clear about the other direction:

Model calls. Unless you are running a model on your own hardware, every prompt and response goes to whichever provider's key you configured. That provider bills the usage and processes the content under its own terms. Your server is the origin of the request, not the place the thinking happens.

Platform coordination. Account, installation and connection flows involve platform services. That is what makes guided setup and cross-device connection possible.

The connection path. Your clients have to reach the server somehow. Where a tunnel is used, the tunnel provider carries that traffic.

Anything you integrate. Every storage backend and third-party integration you enable is another party that sees what you send it.

None of this is unusual, and none of it is hidden — but "self-hosted" on its own does not tell you about any of it.

---

🔐 Getting the Boundary Right

Some practical habits that follow from the map above:

1. Use a server you created for this. Not one already running unrelated workloads. Isolation is the entire point, and it evaporates if the agent shares a host with your other services.
2. Grant the narrowest credentials that work. For model keys, for storage, for every integration. An agent with prompt-injection exposure is a good reason not to hand it permissions it never needs.
3. Know which model provider you configured, and read its terms. That is where your prompts go.
4. Remember the server bill is yours. Removing an agent from the app does not cancel or erase the host — that stays with your hosting provider until you delete it there.
5. Check that it survives a reboot. "Running" and "installed" are different states; restart the server and confirm it comes back without help.

---

🚪 Where AgentAura Fits

AgentAura guides installation of a supported agent runtime onto a Debian or Ubuntu server you provide and administer, then connects supported clients to it. You keep administrator access, the hosting account and the lifecycle. It does not buy, create, stop or destroy that server.

The honest summary: you get execution isolation and control of the host. You do not get a system where nothing leaves the machine — not unless you are also running the model yourself.

Knowing exactly which of those you are buying is the difference between a security decision and a comforting phrase.

---

Read more: server and deployment reference · why not your main machine