Self-Hosted vs Hosted AI Agent: Complete Responsibility Matrix

A self-hosted AI agent gives you control of the runtime, files, models, tools, and data. It also gives you every operational job required to keep that agent useful. A hosted AI agent moves much of that work to a service operator. The real choice is not open source versus convenience. It is which parts of the system you want to own after the first successful demo.

Hermes Agent supports the self-hosted path on a laptop, dedicated computer, Docker host, or VPS. FlyHermes is the managed path for people who want a hosted Hermes workspace, supported model access, tools, core channels, and an always-available browser experience without assembling that stack themselves.

The four realistic ways to run an AI agent#

Most buyers are choosing among four operating models, not two.

1. Personal laptop: fastest way to test Hermes. It can use local files and local models, but sleep, shutdowns, network changes, and travel interrupt background work.
2. Dedicated computer: a Mac mini, spare laptop, or workstation can stay online and keep data close. You still own power, updates, remote access, backups, security, and hardware failures.
3. VPS or Docker server: a remote server gives better uptime and reach. You now own Linux, storage, firewall rules, secrets, containers or services, monitoring, upgrades, and recovery.
4. Managed cloud: FlyHermes operates the hosted runtime and packages supported model access, tooling infrastructure, core channels, and a usage allowance into the service. You trade some infrastructure control for less setup and incident work.

The Hermes Agent setup guide is the right laptop starting point. The VPS hosting guide and Docker Compose guide show what the self-hosted server path actually involves.

What “self-hosted” includes after installation#

Installing an agent is one task. Operating it is a recurring job. A durable self-hosted Hermes setup has at least these ownership areas:

• Runtime: keep the computer, container, or service alive and restart it safely after failure.
• Models: configure provider credentials or local model servers, watch credits and rate limits, and test fallbacks.
• State: protect profiles, memory, sessions, skills, cron definitions, and configuration files.
• Channels: keep Telegram, Discord, Slack, or other gateways connected and routed to the correct profile.
• Remote access: secure the dashboard, SSH, Tailscale, reverse proxy, TLS, and firewall rules.
• Updates: upgrade Hermes, containers, dependencies, and the operating system without breaking the live workflow.
• Recovery: back up state, restore it, rotate credentials, and prove the workflow still completes after an incident.

The backup and restore guide covers the state layer. The gateway troubleshooting runbook shows why “connected” is not the same as end-to-end delivery.

What managed hosting removes—and what it does not#

Managed hosting should remove operating work, not make magical claims. The current FlyHermes offer provides a hosted Hermes workspace, supported model API access, tooling infrastructure, core channels, persistent memory, scheduled jobs, and a monthly usage allowance. That means a buyer does not need to begin by purchasing a VPS, wiring separate model accounts, exposing a dashboard, or maintaining a gateway process.

It does not mean infinite model usage, zero policies, every possible custom integration, or immunity from provider and internet failures. Check the current plan limits and supported surfaces before buying. The useful distinction is accountability: FlyHermes owns the hosted operating layer; a self-hoster owns it directly.

The closed-laptop test#

Do not call an agent “24/7” because a dashboard loads. Prove it.

1. Create one harmless scheduled job for a known time.
2. Pin delivery to the exact chat, topic, channel, or file destination.
3. Record which machine, profile, provider, and gateway own the run.
4. Close Desktop and your terminal. If the runtime is on a laptop, test sleep explicitly.
5. Wait without opening a client to help the process.
6. Verify the real message or artifact arrived.
7. Inspect the cron result and gateway logs for that same run.
8. Reboot the host once and repeat the test.

Use the AI agent cron jobs guide for delivery mechanics and the 24/7 Hermes checklist for the full acceptance test. A green process, successful HTTP response, or visible dashboard is weaker evidence than the intended output arriving on time.

Who starts what?#

Startup ownership is where many “simple” self-hosted stacks become confusing.

• The host operating system starts Docker, launchd, systemd, or another supervisor.
• Docker or the service manager starts the Hermes runtime and restarts it under the policy you configured.
• Ollama or another local model server must start separately if Hermes depends on it.
• The Hermes gateway must run under the correct profile and credentials.
• Desktop and Web UI are control surfaces. Opening them does not necessarily start every remote backend component.
• Bot Mode organizes isolated profiles, chats, routines, groups, and connected machines. It does not supply a cloud computer or transfer uptime ownership.

For the interface boundary, read the Hermes Bot Mode guide and the Dashboard and Web UI guide. For a remote client, the Desktop remote backend guide explains which machine still owns tools, state, and channels.

Docker helps deployment, not operations#

Docker makes versions, dependencies, volumes, and restart policy more reproducible. It does not remove the need to manage:

• persistent volumes and backup coverage,
• image updates and rollback,
• host-to-container networking,
• dashboard authentication and network exposure,
• provider secrets and token rotation,
• gateway health and channel delivery,
• disk growth, logs, memory pressure, and host reboots.

A current support example makes the boundary concrete: Hermes in Docker on macOS may need to reach Ollama on the host through host.docker.internal:11434, while Ollama must listen on an address the container can reach. Solving that connection is normal self-hosted work, not an agent-feature failure. The Hermes Docker setup guide covers the reproducible path.

The seven-day operator log#

Do not compare only a VPS bill with a hosted subscription. For one week, record every minute spent on the system under these headings:

• initial setup and configuration,
• provider signup, credits, rate limits, and fallback tests,
• Docker, network, dashboard, or certificate work,
• updates and post-update acceptance tests,
• gateway reconnects and missed deliveries,
• backup and restore work,
• workflow failures that required manual repair.

Then calculate:

real monthly cost = infrastructure + model usage + paid tools + monitoring + operator hours + cost of missed work

Operator hours are not automatically waste. They can be worthwhile learning, security, or customization. The log simply prevents a cheap server price from hiding the rest of the decision. The Hermes cost calculator separates provider, VPS, tooling, and labor costs.

The complete responsibility matrix#

A useful self-hosted-versus-hosted comparison names the owner for every recurring job. Do not accept “managed” or “self-hosted” as a complete answer; ask who receives the alert and who performs the repair.

Runtime and uptime#

• Self-hosted: you keep the laptop, home server, VPS, service manager, or container online. You choose restart policy, inspect memory and disk pressure, and prove recovery after a reboot.
• Managed: the service operator keeps the hosted runtime available. You still decide which workflows may run and what they are allowed to access.
• Acceptance test: close the client, interrupt the runtime once, and verify one scheduled result still reaches its real destination after recovery.

Models, credits, and rate limits#

• Self-hosted: you configure OAuth or API keys, know which wallet pays for primary and auxiliary calls, set budget alerts, and repair 401, 402, 403, 429, timeout, and context-limit failures.
• Managed: supported model access and its usage allowance are packaged into the service. You still need to understand plan limits and approve unusually expensive work.
• Acceptance test: run one representative task three times and record accepted-result cost, retries, elapsed time, and failure behavior. The Hermes provider cost guide explains the error classes.

Secrets and permissions#

• Self-hosted: you store provider keys, bot tokens, OAuth grants, MCP credentials, and service passwords; restrict profile access; rotate compromised credentials; and audit who can invoke tools.
• Managed: the operator secures the hosting layer and supported credential store. You remain responsible for granting least-privilege access to Gmail, GitHub, Telegram, Discord, or any connected business system.
• Acceptance test: list every connected credential, its owner, its permitted actions, and its revocation path. Managed hosting does not turn a broad OAuth grant into a narrow one.

Remote access and dashboard security#

• Self-hosted: you own loopback binding, SSH or Tailscale access, dashboard authentication, TLS/reverse proxy choices, firewall rules, and public exposure checks.
• Managed: browser and mobile access are provided through the hosted product boundary.
• Acceptance test: verify the dashboard is unreachable without the intended authentication path and that the Hermes Web UI is controlling the expected machine and profile.

Messaging gateways and delivery#

• Self-hosted: you create platform credentials, run the gateway, configure allowlists and topics, resolve duplicate polling, and distinguish “connected” from a completed agent reply.
• Managed: supported channel connectivity and hosted gateway uptime move to the service operator. You still own recipient choice, permissions, and the content the agent may send.
• Acceptance test: send one inbound message and one scheduled outbound result through the exact production chat, topic, or channel—not a generic test room.

State, backups, and restore#

• Self-hosted: you protect profiles, config, sessions, memory, skills, cron definitions, plugins, and approved secrets. You choose backup frequency, encryption, retention, and off-machine storage.
• Managed: the hosted service owns its platform backup and recovery process. You should still know what can be exported and how business-critical artifacts leave the service.
• Acceptance test: restore into an isolated target and prove the agent can load the expected profile, memory, skills, and schedules. A backup file that has never been restored is not recovery evidence.

Updates and change control#

• Self-hosted: you update Hermes, Docker images or dependencies, operating-system packages, and local customizations; read migration notes; preserve state; and run post-update tests.
• Managed: the operator deploys supported platform updates. You still validate your own prompts, connected services, and business workflows after material product changes.
• Acceptance test: keep a small regression pack covering provider access, one tool call, one channel reply, one scheduled run, and one state read.

Monitoring and incident response#

• Self-hosted: you watch provider health, gateway state, cron runs, delivery errors, memory/disk pressure, logs, certificate expiry, and backup freshness. You decide who is on call.
• Managed: platform monitoring and hosted-runtime recovery move to the service operator. You still need an escalation path and an owner for incorrect business actions.
• Acceptance test: create one harmless failure, confirm the alert reaches the right person, and time the repair from symptom to verified outcome.

What both options still require from you#

Managed hosting removes infrastructure work; it does not remove judgment. In either model, the user or team still owns:

• which data and accounts the agent may access;
• whether a tool can read, write, publish, pay, delete, or message;
• approval rules for consequential actions;
• the quality standard for completed work;
• the recipient and retention policy for generated artifacts;
• the decision to expand from a safe pilot into unattended production.

This is the honest residual-responsibility boundary. A managed agent can own uptime and platform recovery while the customer continues to own business policy and connected-service permissions.

A 30-minute decision audit#

Use this before buying a VPS or choosing a hosted plan.

1. Name one real workflow. “An AI assistant” is not specific enough. Use “send a daily Telegram report,” “monitor leads,” or “research and publish one verified article.”
2. Mark its availability requirement. Decide whether it can stop when a laptop sleeps, whether it must survive a reboot, and how late a result may be.
3. List every dependency. Include model route, browser/search service, local files, gateway, destination, credentials, dashboard, and storage.
4. Assign an owner to each failure. If the answer is automatically “me,” the workflow is self-hosted even when one component is managed.
5. Price a month, not a demo. Add infrastructure, model usage, paid tools, monitoring, backups, operator hours, and missed-work cost with the Hermes cost calculator.
6. Run the closed-laptop test. Trigger the real workflow with the client closed, then repeat after a controlled restart.
7. Choose by responsibility. Keep self-hosting when control and customization justify the operator work. Choose FlyHermes when reliable browser/mobile and channel access matter more than maintaining that stack.

Self-hosted versus hosted by decision factor#

Choose self-hosted when#

• local or private-network data must stay under your control,
• you need unusual system packages, tools, models, or network access,
• you already operate servers and backups confidently,
• you want local models through Ollama, LM Studio, vLLM, or another endpoint,
• you need to inspect and change every layer,
• occasional maintenance is acceptable for the value of that control.

Choose hosted when#

• the agent must remain available without your laptop,
• browser and phone access matter more than server access,
• several channels need to work without separate gateway maintenance,
• you do not want separate model and tooling accounts,
• missed schedules or silent failures cost more than the subscription,
• nobody on the team wants to own Docker, Linux, TLS, backups, and incident response.

Use a hybrid when#

• sensitive or hardware-bound work must remain local,
• routine research, messaging, and scheduled operations should stay available in the cloud,
• you can define a clear boundary between the two systems,
• each side has separate credentials, state, and acceptance tests.

A hybrid design is useful only when the boundary is explicit. “Some things run somewhere” is not an architecture.

Security changes the cost comparison#

Self-hosting can improve control, but only if the deployment is actually secured. The operator owns secret storage, least-privilege tool access, dashboard authentication, network exposure, patches, audit logs, backups, and credential rotation. A dashboard bound to the public internet without the right authentication is not a convenience feature; it is an incident surface.

Prefer loopback access through SSH or a private network such as Tailscale. If the dashboard must bind beyond loopback, use the authentication and HTTPS controls documented for the current release. The Hermes security hardening guide provides the detailed checklist.

Managed hosting changes the trust model rather than eliminating it. Review the provider's data handling, supported integrations, account controls, plan limits, refund terms, and support boundaries. Choose the model whose trust and maintenance obligations you can explain clearly.

A practical decision path#

Use this order instead of choosing from a feature matrix:

1. Prove one workflow locally. Complete one provider turn, one tool action, and one inspectable result.
2. Decide whether it must survive laptop sleep. If not, local Hermes may be enough.
3. List required control. Local files, custom binaries, local models, private networks, and compliance can justify self-hosting.
4. Price the whole operating layer. Include model usage, tools, monitoring, backups, security, and time.
5. Run the closed-laptop and reboot tests. Do not assume uptime.
6. Choose the owner. Operate a dedicated machine/VPS yourself or use a managed service.
7. Revisit after seven days. If maintenance is crowding out the workflow, move the always-on portion to the hosted path.

Current demand behind this comparison#

The latest local content-intelligence refresh found the same operating question across multiple source classes:

• A current Hermes fundamentals video frames setup choice—dedicated machine, VPS, spare computer, or personal computer—as the difference between a sustainable system and a poor experience.
• Fresh Discord support includes Docker-to-host Ollama networking, remote backend roster behavior, gateway delivery, scheduled-output limits, provider changes that affected tools, and update-related UI fixes.
• Recent Reddit language describes the self-hosted stack as Docker, environment variables, bot configuration, Telegram, VPS debugging, restarts, and security—and asks when maintaining the agent becomes more work than using it.
• Search Console already shows demand around Hermes dashboards, Docker Compose, local models, and messaging gateways, so the useful page is an ownership guide rather than another broad “AI agent platform” list.

These sources describe pain and search intent; they do not prove that every self-hoster struggles or that hosted service is always better. Experienced operators can run Hermes efficiently. The page's job is to make the maintenance boundary visible before a buyer commits.

Final call#

Self-host Hermes when control is the product requirement and operating the stack is an acceptable part of the job. Use FlyHermes when the agent's availability and completed work matter more than owning the server, provider, gateway, dashboard, update, and recovery layers.

Start with the open-source install path if you want control. Compare FlyHermes pricing and the current managed offer if you want the hosted operating layer. Whichever route you choose, require one real scheduled delivery, one reboot test, and one recovery plan before calling the agent production-ready.

Authenticated browser maintenance belongs in the hosting decision#

Self-hosted browser work can include Chromium updates, CDP reachability, profile snapshots, OS-keychain compatibility, credential permissions, and identity verification. That control is valuable when local sessions are the requirement. If it is operational overhead, use the browser troubleshooting guide to price the real work, then compare it with FlyHermes pricing rather than counting only VPS and model tokens.

Telegram is an operations decision too#

A self-hosted Telegram agent means owning polling or signed webhooks, BotFather privacy, user/chat allowlists, topic routing, delivery recovery, logs, and host-visible attachment paths. Read the Hermes Telegram setup guide; choose managed hosting when the channel outcome matters more than maintaining that stack.

A saved schedule is not managed uptime#

Self-hosted cron depends on the host clock, gateway ticker, provider lane, scripts, delivery adapters, and restart recovery. A sleeping laptop or truly stopped server cannot execute the job. Use the cron operations checklist to price that responsibility; choose FlyHermes when the outcome must arrive without owning those layers.

A better dashboard does not erase infrastructure ownership#

The current Hermes Dashboard now gives self-hosters a much stronger control plane: embedded TUI Chat with approvals, profiles, sessions, analytics, logs, Kanban, cron, skills, MCP, channels, resource warnings, themes, and plugins. That reduces command-line friction. It still leaves the machine, private network or HTTPS, authentication, updates, backups, model accounts, gateways, and incident recovery with the operator. FlyHermes is the managed choice when those responsibilities—not the UI itself—are the pain.

Add browser recovery to the ownership decision#

For self-hosted browser work, the operator owns browser updates, profile storage, CDP routing, stale-daemon cleanup, anti-bot boundaries, and post-restart acceptance tests. The Hermes browser automation troubleshooting guide shows what that operational burden looks like before you compare it with a managed browser and mobile-access path.