Self-hosted AI agents:
no server, no container, nothing exposed
People self-host for three reasons — data not leaving, cost not scaling, not depending on a vendor — and almost always end up standing up a container, a database and a domain. There is a shorter route: have the agent run on the machine you already have.
A distinction almost nobody makes
Local model and local execution are not the same thing
This is the confusion that makes people try the wrong tool, so it goes first. When someone says "I want to run an agent locally" they can mean two very different things, and usually only one of them is what they need.
Local model means the model weights live on your machine and inference happens there: Ollama, llama.cpp, vLLM. No token goes out to the internet. It is the only configuration with an absolute guarantee, and it is paid for in quality: the models that fit on a desktop machine are still behind the best API models, and on long tasks the gap compounds.
Local execution means the agent — the loop that reads files, runs commands and decides — runs on your machine, even if the reasoning is done by a remote model. Your files, your paths, your credentials and your results are not uploaded to any service; the inference call goes out and nothing else.
Lienox is the second, and supports the first if you point an agent at a local model. For most compliance cases, local execution already solves the problem: the worry is rarely that a model sees a fragment of text, but that a third-party platform stores your repositories and your results.
When this need shows up
Six scenarios where self-hosting stops being optional
If you recognise yourself in none of them, a managed service is probably the better deal and this page is not for you.
The repo cannot leave
Client contracts, code under NDA, or simply an internal policy. The agent has to read the files without the files being uploaded anywhere.
Third-party personal data
When the agent touches customer data, every intermediate platform is one more processor to document and audit. Not having one is cheaper than managing it.
No internet egress
Industrial environments, segmented networks, field machines. Only the full combination works here: local agent and local model.
The meter ate the savings
Automations that started cheap and now cost more than they save, because pricing is tied to executions or burnable credits.
The work is on your machine
Dev servers, local databases, internal tools that only answer on the office network. A remote sandbox simply cannot reach them.
Not depending on a plan that changes
If your process lives in a service, a pricing or policy change is your problem. If it lives on your machine, the worst that happens is that you stop updating.
Auditable, not reassuring
What leaves your machine and what does not
If you are going to trust this page for a compliance decision, do not trust the table: check the traffic yourself. Any vendor that objects to you doing that is telling you something.
| What | Does it leave your machine? | Detail |
|---|---|---|
| The contents of your files | No | The agent reads them on disk; they are not uploaded to any Lienox service |
| Prompts and responses | Only to the AI provider you choose | With your own key, straight to their endpoint. With a local model, they do not leave at all |
| File paths and project names | No | Explicitly excluded from telemetry |
| Agent results | No | They stay in local state, on your disk |
| Your API keys | No | They only travel to the provider they belong to, inside the call itself |
| Anonymous usage events | Yes, by allowlist | Which features are used and how often. Never content. This is the only telemetry |
| Licence validation | Yes | A plan check against the licence service. It carries nothing from your work |
Check it yourself
Five steps to verify instead of trusting
Look at where the state lives
Everything Lienox produces is stored on your disk. If a local directory holds the complete state, there is no copy on a server: those two things cannot both be true.
Watch the traffic during a real task
Run an agent over an actual project with a traffic capture in front of it. You will see the AI provider call, licence validation and telemetry. Anything else is a legitimate question.
Point it at a local model
Bring up Ollama or llama.cpp and configure the agent against that endpoint. If the task still works, you have just removed the last outbound path carrying anything of yours.
Disconnect the network and try again
With a local model, an agent should keep working with no internet. It is the definitive test and it takes two minutes: whatever works offline was not depending on anybody.
Check what has to stay powered on
The honest trade-off of local execution: scheduled tasks run on your machine. If you need 24/7 execution, either you leave a machine on or that specific piece needs a managed service.
Real requirements
What hardware it actually takes
With an API model, very little. The agent coordinates, reads files and runs commands; the heavy lifting happens at the provider. Any machine that can run a browser and a modern dev environment will do. RAM goes to the agent browser, not to the reasoning.
With a local model, that changes. GPU memory and model size dominate. A small quantised model runs on recent laptops; a large one wants a dedicated GPU with plenty of VRAM. Measure with your real task, not a synthetic benchmark: agentic tasks chain many passes and long context penalises far more than a demo suggests.
The cost nobody counts: maintaining the install. With a desktop app it is updates and little else. With a full self-hosted stack — container, database, TLS, backups — it is somebody's time every month, and it is the line item that decides whether the project is still alive in six months.
Frequently asked questions
Self-hosted AI agents
How do I run AI agents locally?
There are two layers and it helps to decide each separately. Running the agent locally is solved by a desktop app like Lienox or by self-hostable projects like OpenHands. Running inference locally is a separate matter, solved with Ollama, llama.cpp or vLLM serving an open-weight model. You can have the first without the second, and for most compliance requirements the first is enough.
Does self-hosted mean I need a server?
With the classic tools, yes: container, database and usually a domain to receive webhooks. With a desktop app, no: it installs and runs on the machine you already use, with no open ports and no public surface. What you give up is permanent availability, because if the machine is off nothing is running.
Does a local agent work without internet?
Only if the model is local too. With a local agent and an API model you still need internet egress for inference, even though your files never move. With Ollama or llama.cpp serving the model on the same machine, the whole thing works offline — and pulling the network cable is the best way to confirm it.
What hardware do I need?
If the model is remote, any machine that handles a browser and a modern dev environment. If the model is local, VRAM is what matters: a small quantised model runs on recent laptops, a large one wants a dedicated GPU. Measure with your real task, because agentic work chains many passes with long context and that weighs far more than a short benchmark.
Is self-hosting cheaper?
In licence, yes; in total, it depends. The platform subscription goes away but inference does not — it moves to the provider if you use an API, or turns into hardware and electricity if you use a local model. And you have to add the time to maintain the install, which is exactly the line item missing from every comparison and usually the one that decides the outcome.
What exactly does Lienox send over the network?
Three things and nothing more: the inference call to the provider you configure with your own key, validation of your licence, and anonymous usage events on an allowlist — which features are used and how often. Never file contents, paths, prompts or results. And you do not have to take our word for it: watch it with a traffic capture during a real task.
Can I schedule tasks if everything runs locally?
Yes, agent cron jobs fire at whatever time you set, with the obvious limitation that they need the machine powered on. For a morning report or an overnight review with the machine awake, it works. For something that must answer at three in the morning no matter what, either you leave a dedicated machine on or that specific piece calls for a managed service.
Self-host without setting anything up
It installs on your machine and runs there. No container, no database, nothing exposed to the internet.