← Back to home
Reference

What are self-hosted AI agents?

A self-hosted AI agent runs inside infrastructure you control. The container host is yours, the database holding its state is yours, the repository it commits to is yours, and the model account it calls is billed to you. The vendor ships software and a license. You run the software.

Self-hosting answers one question, and it answers it completely: where the software runs. It does not, on its own, answer whether the vendor holds a copy of what the agent saw, or whether a shared service exists that could carry one customer’s data toward another. Those are separate questions, and they are the ones worth asking.

The range

Deployment is a range, not a switch.

The words move around. Self-hosted, private, on-premises, sovereign and air-gapped get used interchangeably in the same conversation, and they describe different postures with different consequences. This is the range, from the shape that moves least to the shape that moves everything.

01
Shared multi-tenant service
One system, many customers, isolation maintained in software. Fastest to adopt and the only shape where another customer is inside the same blast radius as you.
02
Single-tenant, vendor-operated
Your own instance, still run by the vendor, still reachable by their operators. Isolation from other customers is real. Custody has not moved.
03
Inside your cloud account
The software runs in your account, on your network, under your identity provider. Who can reach the machine is now your question to answer, and the vendor still ships the images.
04
On hardware you own
The same as above with the physical layer moved too. Relevant when a regulator cares where the disk is, and identical in every other respect.
05
Air-gapped
No outbound path at all, which forces every dependency to resolve offline, including the license check. It is the strictest posture and the one that exposes any undeclared call home.

Which row you need is a risk decision before it is a technology one, and the row you can defend to your own auditor is the right one.

The open questions

Three things self-hosting does not settle.

Ask these of any vendor, including this one. They are answerable in a sentence each, and a vendor who needs a paragraph is telling you something.

Question one

Custody

Does the vendor’s own system hold your operational data at any point, for any duration, for any purpose? Telemetry, support tooling, and a hosted control surface are all custody, whatever the deployment diagram says.

Question two

Blast radius

Is there a shared component where one customer’s failure or breach could reach another customer’s data? Software isolation is a control someone has to operate correctly. An architecture with nothing shared has no such control to get wrong.

Question three

Egress

What leaves the perimeter, who initiates it, and can you switch it off and still have a working system? The answer to the last clause is the one that matters, because a dependency you cannot disable is not optional.

In practice

How SpeyAI answers them.

SpeyAI is installed, not subscribed to. It stands up on a container host you run, against a database you own, using the version control and model accounts you already have.

Custody
There is no hosted SpeyAI to opt out of
We do not operate an instance holding your operational data, which means cross-customer leakage is not a control we run well. It is a path that does not exist in the architecture. That is the claim, and it is narrower and more durable than a claim about deployment topology.
State
Your Postgres, reached with a credential you rotate
State lives in your own managed Postgres, and the connection string is exactly what it looks like: a credential you own and rotate on your own schedule. When the organization runs inside AWS, Azure, or Google Cloud, it can sign in with that cloud’s own managed identity instead, with no stored database password. Which of the two is in force is a line of configuration your reviewer reads.
Egress
It runs with no outbound access at all
The license verifies offline against a signing key built into the images, so an air-gapped install needs no call home to start or to keep running. Optional liveness reporting is a small health block, never code and never repository content; it ships enabled in a downloaded install kit, and clearing one value ends it.
Upgrade
Additive migrations, so a rolling upgrade is safe
Schema changes ship as new tables and new nullable columns, never a drop, a rename, or a type change on a live table. You pull the new image tag, re-run the schema apply, and recreate the services. The apply is idempotent and only runs what your database is missing.
The trade

What self-hosting costs you.

Say it plainly, because the alternative is a procurement process that finds out in month three. Running the software yourself means the operational work is yours.

What you take on

Standing up Postgres with pgvector available, applying the schema before first use and again before each upgrade, holding the secrets, patching the host, and watching the health endpoints. None of it is exotic, and all of it is real work that a hosted product would absorb.

What you get for it

Your data never enters a system you cannot inspect, your model spend sits on your own provider account under your own limits, and the agents commit to a repository your engineers already review. The security conversation becomes a review of code and configuration rather than a review of a vendor’s promises.

Questions

Asked most often.

What does self-hosted mean for AI agents?

That the agent runtime executes on infrastructure you control. The container host is yours, the database holding the agents’ state is yours, the repository they commit to is yours, and the model account they call is billed to you. The vendor ships software and a license; you run the software.

Is self-hosting the same as private or on-premises?

Not quite, and the words are used loosely. Deployment sits on a range: a shared multi-tenant service, a single-tenant instance the vendor still operates, an instance inside your own cloud account, an instance on hardware you own, and an air-gapped instance with no outbound path at all. Self-hosted usually means one of the last three. Each answers where the software runs, and none of them by itself answers who holds your data.

Does self-hosting mean the vendor cannot see our data?

Not on its own, and this is the question worth pressing. A product built as a hosted service with a self-hosted option still has a hosted service, and the answer depends on what that service holds and what the deployment reports back to it. Ask what leaves the perimeter, on whose initiative, and whether you can turn it off. SpeyAI has no hosted product to opt out of, so there is no shared service holding customer data and no cross-customer path to defend.

What do we have to run ourselves?

A Postgres database, version 14 or newer, with the pgvector extension available. A container host, or any runtime that runs OCI images. An account with your model provider. A version-control token scoped to the repository the organization opens pull requests against. You apply the schema once, you hold the secrets, and you patch the host. That is the trade self-hosting makes, and it is a real one.

Can it run with no outbound network access?

Yes. The license verifies offline against a signing key built into the images, so the organization runs with no outbound access at all. Optional liveness reporting is a small health block that never carries code or repository content; it ships enabled in a downloaded install kit and is turned off by clearing one value.

Read on

Where this goes deeper.