Self-hosted AI agents
Self-hosted AI agents run on infrastructure you control. What that changes for data, credentials, and model choice, and what you take on when you run them.
Category
Self-hosted AI agents run on infrastructure you control rather than on a vendor’s multi-tenant service. The agent logic, the credentials it uses, the documents it retrieves from, and the record of what it did all stay inside your own network boundary, and you decide which model providers it is allowed to reach. What you gain is control over the data path and the deployment. What you take on is the operation of the runtime itself.
What self-hosting actually changes
Self-hosting is often discussed as a compliance checkbox, which undersells it and also oversells it. It is worth being precise about which properties change and which do not.
- The data path
- Workflow definitions, run history, retrieved documents, and trace payloads live in your own database. A prompt assembled from an internal document is written to storage you own, not to a vendor’s.
- Credential custody
- API keys for the systems an agent touches are stored encrypted in your instance. They are never held by a third party on your behalf, and an agent’s access is bounded by the credentials you chose to put there.
- Model choice and egress
- You decide which providers the runtime may reach, including a model you host yourself behind an OpenAI-compatible endpoint. That is a network decision you can enforce, rather than a setting you trust.
- What does not change
- Self-hosting does not make a model private by itself. If an agent calls a hosted provider, the prompt reaches that provider. The control self-hosting gives you is over which calls are allowed to leave at all.
What you take on
The honest cost of self-hosting is operational, and it is worth naming before a decision rather than after one.
You run the database and its backups. You apply upgrades on your own schedule, which is a benefit until it becomes a task nobody owns. You size the instances, and when volume grows you add capacity rather than buying it. You are also the first responder when a run fails at 3am, which is the strongest practical argument for choosing a runtime whose traces and alerts are good enough to answer that page quickly.
How Heym deploys
Heym is source-available under an MIT license with a Commons Clause condition, so you can read the execution semantics, patch what you need, and run the whole thing inside your own network.
- One command to start
- Docker Compose brings up PostgreSQL, the FastAPI backend, and the editor together. That is enough to run production workloads on a single server.
- Kubernetes for scale
- Multiple backend instances share workflow execution through weighted load balancing, with execution state in PostgreSQL so any instance can pick up a run.
- Deliberate placement
- Work that has to stay on one machine, such as a file drive or a coding-agent workspace resumed by a later run, is declared as such rather than left to chance, while CPU-heavy sandboxed work is free to move to any instance.
- Your identity provider
- Sign-in runs against any OpenID Connect provider you already operate, configured with an issuer URL and client credentials, with role-based team permissions on top.
- Vectors without another service
- Retrieval can use Postgres with pgvector in the database you are already running, so a RAG pipeline does not require standing up a second datastore. Qdrant is there when you want it.
Questions worth asking before you commit
These apply to any candidate, Heym included. They are the questions whose answers are hard to change later.
- 1
Is the source actually readable?
Being able to read the executor is what lets you answer "what exactly did it do" without filing a support ticket. Check the license terms for what you may do with it commercially.
- 2
Does self-hosting cost you features?
A self-hosted tier that omits single sign-on, audit logging, or scaling is a demo. Confirm which capabilities are in the version you can actually run.
- 3
Where does run state live?
If execution state is held in memory on one process, adding a second instance changes behavior. State in the database is what makes horizontal scaling boring.
- 4
How are credentials stored?
Look for encryption at rest and for scoping by team, not just a settings table.
- 5
Can you point it at your own model?
An OpenAI-compatible endpoint setting is the difference between "self-hosted platform" and "self-hosted platform that still has to call out for every token".
- 6
What is the upgrade path?
Ask how schema migrations run and whether you can stay on a version. Self-hosting means upgrades happen when you choose, which only helps if the mechanism is documented.
Frequently asked questions
What are self-hosted AI agents?
Self-hosted AI agents are AI agents that execute on infrastructure you operate rather than on a vendor’s hosted service. The workflow definitions, credentials, retrieved documents, and execution records stay inside your own environment, and you control which model providers the agents may reach.
Does self-hosting keep my data away from model providers?
Only for the calls you keep local. Self-hosting keeps the platform’s own data inside your boundary; a prompt sent to a hosted model still reaches that provider. What self-hosting gives you is the ability to decide which providers are reachable at all, including pointing the runtime at a model you host yourself.
What does it take to run Heym?
Docker Compose starts PostgreSQL, the backend, and the editor with one command, which is enough for a single-server deployment. For larger volumes, run several backend instances that share execution through weighted load balancing, with state in PostgreSQL.
Is Heym open source?
Heym is source-available under an MIT license with a Commons Clause condition. You can read, modify, and self-host it freely. The Commons Clause restricts selling the software itself, including paid hosting whose value derives substantially from Heym.
Keep reading
- AI agent runtime What a runtime has to do before you host one.
- AI agent governance Controls on what an agent may do unattended.
- Enterprise Single sign-on, scaling, audit, and support.
- Running and deployment Docker and Kubernetes deployment reference.
- Single sign-on Connecting your own OpenID Connect provider.
- Load distribution How instances share workflow execution.
Last reviewed September 13, 2026.