Self-hosted AI agents run some part of their software in an environment your organization operates. That can give your team control over working files, credentials and the agent runtime, but it does not establish that prompts stay local. The answer depends on the model provider, chat platform, connected apps and backup design. Start an evaluation by drawing those paths, then decide which people may direct the agent and approve its actions.
This guide is for an operations owner choosing a team workflow and the technical colleague checking how it will run. It focuses on the operating questions that a product list rarely answers. If you already know the architecture and want installation steps, use the ChannelGate deployment guide instead.
What does self-hosted mean for an AI agent?
The term describes where a runtime is operated. It does not specify the model, the location of every copy of a file, or the conditions under which one colleague may access another's connected account. A team should ask which components it hosts and which services still participate in the work.
For example, ChannelGate runs on an operator's Linux host and uses rootless Podman containers for conversations. Its data-flow documentation says the selected AI provider can receive prompt and context, while enabled connectors send chosen requests to their external services. The chat platform also processes the conversation. The README puts the central caveat plainly: "Model providers still receive prompt/context."
That makes where does the agent run? and where does this request's information go? separate questions. Your security review needs both answers. So does your team: a person working in Slack should know which source the agent can read, which account an action will use, and whether the result is still a draft.
Which information stays on your host, and which requests leave it?
Use one real task to fill in this inventory. A generic promise about "data residency" cannot replace it.
| Component | Question to ask | ChannelGate example |
|---|---|---|
| Runtime and files | Who operates the process and stores working files? | The Linux deployment runs conversation containers; work folders can retain attachments and outputs. |
| Agent state | Where are settings, sessions and audit records kept? | Local SQLite and backups hold durable operational state. |
| Model call | Which prompt and context reach a provider? | The selected Claude Code or Codex setup can send relevant context to its configured provider. |
| Chat | Where do requests and replies appear? | Slack is the primary supported surface; Teams and Google Chat are Beta. |
| Connected app | Which account sends or receives a tool request? | An enabled connector calls the selected external service within its configured access. |
| Recovery copies | Who backs up, restores and deletes retained information? | The deployment operator sets the backup and retention policy. |
The ChannelGate privacy and data-flow document also explains a deletion trap: removing a chat message does not automatically erase provider logs, connector records, generated files or backups. A pilot needs a retention decision for each system, with an owner who can carry it out. If your organization has a geographic or contractual requirement, check the selected model and connector agreements for that particular route.
What does your team gain by operating the runtime?
Owning the deployment lets the organization inspect and maintain its working folders and operational state. A team can decide which files and connected accounts a workflow receives, and it can keep a repeatable procedure with the work instead of rebuilding context in one person's private session. ChannelGate's README describes its conversation workspace, permissions, memory, skills and audit history. The collaboration page shows how colleagues steer a request in one thread.
That control becomes useful when work needs a handoff. Suppose an operations team asks for a Monday review of open deals. One colleague can identify the records to check, another can correct a missing source, and the agent can return a list with the evidence it used. A proposed CRM update or customer email is a separate action, using the intended connected account and the approval rules set for that channel. The team can inspect the result where the request began. This is an illustrative workflow, not a published customer result.
The value is the ability to define and review this work in a shared place. It still takes an operator to provision the host, a process owner to define what a good result looks like, and a reviewer to check consequential actions.
What work does self-hosting add?
A self-hosted deployment creates operational duties. Someone must maintain the Linux host and runtime, apply updates, monitor available disk and service health, protect credentials, and test backup recovery. ChannelGate's operations documentation assigns those responsibilities to the operator. Model subscriptions, connected-service charges and hosting are separate from the product license.
It also creates decisions that a vendor-managed workspace often makes for you. Set a retention period for conversation records and files. Decide who can administer channels and which app connections can be used for shared work. Define what happens when a model provider is unavailable or an approver does not respond. Then rehearse the recovery path before the team relies on a scheduled task.
For a team without a suitable operator, a managed service can be the better fit. If a particular workflow only needs one person's drafting help, an approved personal account may be simpler. The shadow AI decision guide starts with that choice before considering a shared agent.
Do self-hosted products solve the same problem?
Products in this category differ in what they host and who they are designed for. A short product list can hide those differences.
| Approach | What to inspect first | Example |
|---|---|---|
| Personal agent gateway | Whether sessions, tools and sandboxes are safe for the intended users | OpenClaw documents its sandbox choices and says sandboxing is off by default. |
| Coding agent environment | Which parts are open source and which team deployment needs a separate license | OpenHands core and the self-hosted OpenHands Cloud package have different licenses. |
| Shared team operating layer | How chat identity, connected accounts, approvals and workspaces are governed | ChannelGate runs Claude Code and Codex in configured team conversations. |
These are different starting points, not a ranking. OpenClaw's documented sandbox settings may suit an operator willing to design the trust boundary. OpenHands is centered on software-development work. ChannelGate is a fit when colleagues need to direct agent work together in chat and the operator wants control over each conversation's access. Read each product's current documentation for the edition and deployment mode you would use.
In particular, check the license for the team edition rather than inferring it from the core repository. The OpenHands Cloud repository describes a self-hosted package with a time-limited trial license, while pointing separately to its MIT-licensed core. "Source available," "self-hosted" and "open source" answer different questions.
How should you evaluate one team workflow?
Begin with a task that has an owner and a result people can check. A weekly sales review, a project handover or a document comparison works better than an open-ended instruction to "help the team." Agree on the inputs, the output and the actions that require a person.
- Name the source systems. List the files, chat history and connected apps the agent needs. Remove any source that is only convenient rather than necessary.
- Trace each data path. Record where the working copy, model request, connector call, output and backup go. Use the inventory above with your own provider and region choices.
- Assign identities. Decide who may ask for work and which account will be used for a connected action. Personal and shared connections have different owners.
- Set the review boundary. Separate a draft recommendation from changing a record or contacting someone. Configure permissions and approvals for the chosen workflow.
- Run a small pilot. Ask the team to check the first result against the source, record corrections, and repeat the task after the procedure changes.
The project handover walkthrough follows one request from its sources through a draft and human review. Its example can help you test whether the access and review points you chose work in a real conversation.
Frequently asked questions
Does self-hosted mean the model runs on our server?
No. A self-hosted agent runtime can call an external model. ChannelGate's documented data flow says the selected AI provider can receive prompt and context. Confirm the provider route for the engine and account you plan to use.
Can we keep all information in one country?
That depends on the chat platform, selected model provider, connectors and backup locations, as well as the runtime host. Write down each route and check the provider's contractual and regional terms. Hosting the runtime in one country does not determine where those other services process data.
Who is responsible for updates and recovery?
The deployment operator maintains the host, credentials and backups. ChannelGate's deployment page explains the operating boundary. Assign a named owner and test a restore before depending on a recurring workflow.
Is an open-source repository the same as a self-hosted team edition?
No. A product can have an open-source core and a separately licensed team package. The OpenHands repositories and OpenHands Cloud license illustrate why the edition and its terms need separate checks.
When is a shared agent useful?
Choose one when several colleagues need to supply context, review the same work or reuse a procedure. Start with a bounded task and a result the team can verify. The Slack workflow guide offers examples of that pilot shape.