Hermes Agent 24/7 Setup for Teams and Multiple Users

Searchers asking for a 24/7 AI agent usually do not want another chatbot tab. They want an agent that can keep running, respond from a phone, remember the ongoing project, recover from provider failures, and send useful updates without someone babysitting the terminal. Hermes Agent is built for that pattern, but the setup choice matters: self-hosting gives you control, while FlyHermes removes most of the server and gateway chores. The Hermes Agent Dashboard helps a self-hosted operator see what is running; it does not replace the operator who handles updates, backups, provider incidents, and failed channel delivery.

A disconnected control screen is a separate recovery case#

An always-on agent can be healthy yet unable to continue a browser task because a human still owns its remote screen. Current Bot Screen documentation distinguishes closing the pane normally from losing the connection during takeover: a dropped connection preserves the human's control lease. That protects a login or payment step interrupted by Wi-Fi loss.

Add a no-side-effect handoff test before relying on remote screen work:

1. Use a harmless page, take control and check the visible owner indicator.
2. Reconnect after a brief client disconnect and inspect who still holds control.
3. Explicitly hand control back when finished, then ask the agent to continue the harmless task.
4. Verify the resulting page or artifact, not just the service's uptime badge.

A human_has_control refusal is not automatically a dead gateway or exhausted model quota. Do not force-release another operator's active session to make monitoring green. Agree who can take over and who can authorize recovery. The lease is a tool-level control, not OS isolation between untrusted users.

This is relevant only when the deployment actually uses Bot Screen; ordinary scheduled text reports do not need it. The self-hosted versus hosted responsibility guide helps define the operating owner without promising that any managed plan supports every optional screen feature.

Test the worker, not only the always-on host#

A machine staying online does not prove an active scheduled worker survives a gateway restart. On systemd hosts, current Hermes uses user scopes for restart-safe dispatch. Without the required user session, it can degrade to a separate process that a gateway restart may kill; operators requiring fail-closed behavior should review cron.require_restart_safe_scope in the official documentation.

Use a harmless, non-publishing acceptance job for a planned restart test. Compare its attempt history with the actual output afterward. An unknown attempt needs reconciliation, not an automatic retry. The cron recovery checklist covers this boundary. Include ownership of interrupted work in a 24/7 operating agreement rather than equating server uptime with completed customer tasks.

Source: official Hermes scheduled-task documentation.

Prove the workflow before making it 24/7#

Complete the first useful Hermes setup workflow locally before adding a service manager, VPS, gateway, or schedule. A passing local provider turn and verified artifact isolates the base agent from the uptime layer. Then test the always-on version after the laptop sleeps: confirm the runtime, provider, exact delivery target, logs, and retry behavior rather than trusting a connected status alone.

What “24/7 AI agent” means in practice#

Fresh social demand around browser-based coding agents and Hermes Web UI walkthroughs points to a simple desire: people want the agent reachable from a phone or browser while work continues in the background. Self-hosting can deliver that, but only if you also maintain the runtime, provider lane, dashboard, gateway, and restart loop. For teams that want the outcome without the operational surface area, route the decision through self-hosted vs hosted AI agent and FlyHermes pricing.

A real always-on agent is not just a long-running process. It needs five layers to stay useful:

1. Runtime: a laptop, mini PC, VPS, or hosted environment that stays online.
2. Model lane: provider credentials, rate-limit strategy, and fallback behavior.
3. Control surface: CLI for setup, dashboard for status, and messaging for phone access.
4. Operating context: memory, profiles, skills, and session history so repeated work improves.
5. Reliability loop: logs, health checks, cron delivery, and a restart procedure.

Hermes Agent covers the agent side of that stack: terminal tools, browser automation, files, memory, skills, MCP tools, profiles, cron, and gateways. Self-hosting means you still own the machine and its uptime. FlyHermes exists for users who want the Hermes outcome but not the infrastructure burden.

Self-hosted setup path#

Use this path when you want maximum control and are comfortable operating a small server.

1. Choose where the agent runs#

For testing, a local machine is enough. For true 24/7 operation, use a VPS or always-on home server. The VPS hosting guide covers the server path, and the Docker install guide is useful if you prefer containerized state and service restarts.

Keep one rule: the machine running the gateway is the machine responsible for responding. If it sleeps, loses network, or has a stale process, Telegram or Discord will look broken even when the bot token is fine.

2. Install Hermes and verify the CLI first#

Do not start with the gateway. First prove Hermes can answer from the command line:

hermes doctor
hermes chat -q "Reply with one sentence if the provider works."

If install or update fails, use the install and update troubleshooting guide before changing unrelated settings. Community support data shows install/update/Docker/Windows issues are one of the highest-volume Hermes support clusters, so isolating this layer saves time.

3. Pick a provider stack that can survive background work#

A 24/7 agent will hit provider limits faster than an occasional CLI chat. Use the provider costs and rate limits guide to decide which model handles important work, which cheaper model handles routine tasks, and whether a local Ollama lane belongs in your setup.

For production-like automations, also read the provider fallbacks guide. A cron job or gateway reply can fail because an auxiliary compression or search model ran out of credits, not because Telegram itself broke.

4. Connect one messaging platform first#

Start with one channel. Telegram is common because it gives you phone access fast; Discord is better for team/community workflows. Use one guide, verify it end-to-end, then add the next platform later:

• Hermes Agent Telegram setup
• Hermes Agent Discord setup
• Gateway troubleshooting for Telegram, Discord, topics, and restarts

A good first test is a private DM or one controlled channel. Only after that should you add groups, topics, mentions, voice messages, or cron delivery into a forum thread.

5. Turn on memory, skills, and profiles deliberately#

Always-on agents need boundaries. Use Hermes profiles when personal, work, and bot contexts should not share secrets or memories. Use the memory system for durable facts, and skills for repeatable workflows.

For a bot that runs all day, profile isolation is not cosmetic. If a secret is available to a profile, that profile can use it wherever the gateway runs. Put only the credentials needed for that bot into that profile.

Add cron jobs after the live agent works#

Cron is what turns a reachable assistant into an operator: daily checks, weekly reports, monitoring, backups, reminders, publishing, or support triage. But cron should come after the basics work.

Use the Hermes Agent cron jobs guide for the workflow. For a first production cron, keep the prompt narrow, set explicit delivery, and verify last_status, last_delivery_error, and the next run time. If the job is script-only and does not need the LLM, use a script-only cron so provider limits do not block deterministic checks.

When FlyHermes is the better 24/7 setup#

Self-hosting is powerful, but many people searching for a 24/7 AI agent are actually buying an outcome: phone access, browser chat, connected channels, memory, and reliable uptime. They do not necessarily want to maintain a VPS, configure Docker, debug provider credits, secure a dashboard, or restart gateway services.

Use FlyHermes when you want the Hermes experience with managed cloud access and less operational work. Use self-hosted Hermes when local control, custom tools, local models, and full infrastructure ownership are worth the maintenance.

Always-on Hermes for a team or multiple users#

A team deployment is not one personal bot with more people added. Give every durable agent role its own Hermes profile, because a profile is the boundary for configuration, API keys, memory, sessions, skills, cron jobs, and gateway state. Never point two writing agent processes at the same HERMES_HOME; their memory and state writes can collide or contaminate each other.

Use this operating pattern:

1. Create one profile per durable role. Run hermes profile create support --description "Handles customer support triage", then configure that profile explicitly with hermes -p support setup.
2. Give each bot one channel owner. Profile cloning intentionally excludes messaging credentials by default. Do not copy one Telegram or Discord token into two independent gateways: duplicate polling and conflicting replies are the predictable result.
3. Separate people inside shared channels. Keep per-user group sessions enabled where supported, restrict allowed users, roles, and channels, and test the exact private thread, forum post, or topic that the team will use.
4. Separate control from delivery. The machine-level Hermes Dashboard can switch between profiles for configuration and chat, but each profile still owns its session database, cron work, and gateway state. A green dashboard is not proof that a teammate received a reply.
5. Bound concurrency and spend. Run representative simultaneous turns, watch model and auxiliary-model quotas, and decide what should queue rather than allowing every user and cron job to compete without limits. Use the provider cost and rate-limit guide before opening access broadly.
6. Prove recovery as a team. Restart the supervised runtime, verify the intended profiles and schedules, then require one real reply from every production channel. Use the gateway recovery runbook when process health and channel delivery disagree.

Team acceptance test#

Do not call the deployment multi-user-ready until all six checks pass:

• two teammates can send simultaneous requests without inheriting each other's conversation context;
• each role sees only its intended skills, secrets, files, and memory;
• scheduled work is attached to the intended profile and exact delivery target;
• a provider limit produces a visible failure or safe fallback instead of silent loss;
• a host reboot restores every required profile and gateway without duplicate pollers;
• one operator can identify who owns runtime, provider, channel, backup, and incident recovery.

If the team wants shared browser/mobile access and connected-channel uptime but does not want one person to own these controls, compare the managed FlyHermes route. Managed hosting reduces infrastructure work; it does not remove the need for least-privilege channel access and clear workflow ownership.

FAQ#

Can I run Hermes Agent 24/7 on my laptop?#

Yes, but it is only 24/7 while the laptop is awake and online. For a real always-on bot, use a VPS, mini PC, or hosted path.

Do I need Docker for a 24/7 Hermes setup?#

No. Docker can make service state and restarts cleaner, but Hermes can run locally too. The important part is that the gateway process, provider credentials, profiles, logs, and backups are predictable.

Is Telegram required for a 24/7 AI agent?#

No. Telegram is a convenient phone control surface, but Hermes also supports Discord, Slack, WhatsApp, Signal, email, Matrix, webhooks, and more. Pick one platform first and verify it before adding others.

What is the fastest path if I do not want server maintenance?#

Use FlyHermes. The self-hosted path is best for control; FlyHermes is better when you want managed browser chat, mobile access, connected channels, and uptime without owning the server layer.

Always-on gateway proof#

For a 24/7 agent, uptime means the real channel answers — not just that a process exists. Pair the Hermes Dashboard / Web UI with the gateway troubleshooting checklist, then verify one Telegram or Discord reply after every update, provider change, Docker rebuild, or service restart.

Provider-cost note#

For a 24/7 agent, provider quota is uptime infrastructure: choose reliable primary, cheap background, and fallback lanes before leaving it unattended. See the Hermes Agent provider cost and rate-limit guide before scaling the workflow.

Reboot proof is part of 24/7 proof#

An always-on setup is not proven until it survives one host reboot or container recreation. After the restart, confirm the intended profile, run hermes gateway status --deep --full, check that no legacy duplicate service started, and send one real Telegram or Discord message. The gateway troubleshooting runbook provides the incident sequence; the Dashboard remains a checkpoint rather than delivery proof.

Run the closed-laptop acceptance test#

Do not call the setup 24/7 because the dashboard loads once. Close Desktop, let the client laptop sleep, trigger a known scheduled job on the actual runtime, and verify the artifact or channel message arrives without manual help. Then reboot the runtime and repeat. Use the self-hosted vs hosted AI agent guide to decide whether you want to own that uptime loop or move it to FlyHermes.

Add resource-pressure evidence to the 24/7 acceptance test#

A process can stay nominally online while the host is nearly out of memory or disk. Check the Hermes Web UI Status page for resource-pressure or suspected OOM-restart warnings, then correlate them with gateway logs and the real missed delivery. Repeat the scheduled-job test after freeing resources. Use FlyHermes managed hosting when owning host capacity, alerting, and recovery is the burden you want to remove.

24/7 Telegram reliability checklist#

For an always-on host, default polling is usually simplest. Sleep-capable cloud platforms can use a signed webhook. In both cases, pin cron reports to the exact Telegram topic and test restart recovery. The Telegram setup guide provides the current commands and failure boundaries.

Prove scheduled work through a restart#

After installing the gateway service, create a harmless recurring test, confirm next_run_at in the host's local timezone, reboot, inspect hermes cron runs, and verify the real destination. Unknown attempts are audit records, not automatic retries. The AI agent cron recovery guide provides the safe pause, reconcile, test, and resume sequence.

24/7 is an ownership claim#

An always-on process is not the same as an always-delivered outcome. Name who handles host failure, provider exhaustion, gateway disconnects, missed schedules, backup restore, and credential rotation. The self-hosted versus hosted AI agent matrix turns 24/7 into a responsibility and recovery decision instead of a dashboard status.

A 24/7 browser agent must survive Chrome replacement#

Process uptime is insufficient when the browser harness still points to a dead Chrome endpoint. Add a controlled browser restart to the acceptance test, fail before the global timeout, and require a real artifact plus exact channel delivery. The browser automation recovery guide supplies the test sequence.

Docker is packaging, not uptime#

A restart policy helps only while the host is available and the state mount is correct. Compare native, whole-agent Docker, and native-plus-Docker-backend designs in the Docker vs native install guide, then test the real gateway and scheduled delivery after a controlled restart.

A dashboard page load is not uptime proof#

For an always-on deployment, include the dashboard localhost recovery ladder in the operator runbook: process, port, assets, profile, auth, and WebSocket. Then close the dashboard and prove the scheduled job or channel still delivers. FlyHermes is the managed route when nobody should own that recovery loop.

Add release-skew detection to operations#

An always-on agent can keep an old dashboard backend alive after the CLI updates. Include the Agent versus Dashboard version check in the maintenance runbook, then verify one real channel or scheduled delivery. FlyHermes is the managed path when nobody should own this update reconciliation.