Self-hosted

In a self-hosted deployment the application, databases, and queue run in your infrastructure. Data never leaves your control at any stage, and model and embedding provider configuration stays on your side too.

That can be decisive for organisations with strict data-residency requirements. In public sector, defence, healthcare, and some financial scenarios, keeping data inside national borders may be a contractual obligation.

Product behaviour does not change: the same assistant structure, the same scope separation, and the same role model apply. What changes is where the components run and who operates them.

The price of control is responsibility. Backup, version upgrades, capacity planning, monitoring, and security patching all move to your team in a self-hosted deployment.

Each item is small on its own but requires continuous maintenance. At SME scale there is no dedicated infrastructure team, so the load usually falls on one person — and the system can be orphaned when they leave.

When deciding, write that operating cost next to the licence cost. In most cases total cost of ownership exceeds a cloud deployment; a genuine residency requirement can still justify it.

A self-hosted decision is right when it is a requirement rather than a preference. If a contract, regulation, or customer demand forbids data leaving your premises, there is no alternative.

If the decision rests only on "it feels safer", it deserves a second look. A poorly operated self-hosted deployment is riskier than a well-operated cloud one; components that are never updated accumulate exposure.

There is also a middle path: if the residency requirement applies only to embedding, that step can run in your infrastructure while the remaining components stay in the cloud.