How to keep Hermes Agent running on a server around the clock

After installing Hermes Agent on a laptop, a question comes up: who will answer on Telegram and put together the morning roundups when the laptop is closed? At your desk, the agent lives only as long as the computer is on. To keep the bot online all the time and have scheduled tasks run by themselves, you need to move the agent to a server.

Below is how to install Hermes on a regular Linux server, turn the gateway into a continuously running service that starts automatically after a reboot, and restrict access so strangers cannot get into the terminal. This guide draws on the official documentation.

If you haven't installed Hermes at all yet, start with the separate overview of what this agent is and how to install it. This guide assumes you already have it running on your own machine and covers only moving it to a server.

Information about working with Ailoot is available in the documentation.

Why move Hermes Agent from a laptop to a server?#

On a laptop, Hermes works only while the lid is open and you're nearby. Close it, and the bot goes quiet; the morning roundup never arrives. That's no good for a task like “answer people in a messenger and take care of things on a schedule.”

That's what makes a server different: it never sleeps and doesn't depend on anything else. You install the very same Hermes on it, and it runs without you: answering on Telegram at three in the morning, gathering news on your topics every morning, and keeping sessions between runs.

Moving it makes sense when you have an ongoing task for the agent: a bot for yourself or your team, morning roundups, automatic replies, or regular work with documents. If you're just trying Hermes out for a specific project and sitting nearby, you don't need a server yet; it's an extra step.

What should you prepare before installing Hermes on a VPS?#

Gather three things before installing.

The server. An ordinary Linux VPS will do. The documentation's first-tier support is Linux and WSL2, and testing is done on the latest Ubuntu. If the system has glibc, systemd, and a familiar directory layout, Hermes will install properly. This matters on a server because all the automatic startup steps below rely on systemd, which comes out of the box on Ubuntu and Debian.

SSH access. You connect to the server through a terminal over SSH; you won't be using a mouse there. All the commands below run in this SSH session. If you vibe-code and aren't comfortable with the terminal yet, don't worry: there are only a few commands, and you can copy each one in full.

A selected model. The agent doesn't think on its own; it calls a model. For a server that works without you, it's important that access to the model doesn't expire. The simplest option is a Nous Portal subscription via hermes setup --portal: sign-in uses OAuth, and the token refreshes automatically. Your own API keys work too, but then make sure there's money in the account—a headless agent with an empty balance will simply go quiet. The model must have a context window of at least 64,000 tokens, or Hermes will refuse to start with it. All the cloud models on the list meet this requirement.

How do you install Hermes Agent on a server with one command?#

Installing on a server is almost the same as on a laptop, with one difference: the agent usually doesn't need a browser there. Browser automation also brings in heavyweight Chromium. That's why you use the --skip-browser flag.

1. Connect to the server over SSH

   ssh root@your-server-address
   

   Run all the following commands inside this session, on the server itself.

2. Run the installer without the browser

   curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash -s -- --skip-browser
   

   The script downloads the required environment and installs the hermes command. The --skip-browser flag skips browser automation installation; on a server without a graphical interface, it would only take up space. If you need a browser later, you can install it separately.

3. Restart the shell and choose a model

   source ~/.bashrc
   hermes setup --portal
   

   The first line picks up the new PATH so the hermes command can be found. The second opens the Nous Portal sign-in: confirm the sign-in, and the agent gets a model and services without separate keys for each one.

4. Check the installation

   hermes doctor
   

   The command shows what's installed, what's missing, and how to fix it. Green marks mean everything is in place.

Before adding a bot and schedule, get one clean conversation working directly on the server: run hermes and give it a simple task with a verifiable answer. The documentation explicitly advises against piling on features before an ordinary conversation works—a sound recommendation.

How do you keep Hermes running around the clock?#

The gateway is a single background Hermes process that maintains connections to all messengers, manages sessions, and runs scheduled tasks. All around-the-clock operation revolves around it. The goal is to make this process start by itself and stay running.

First configure the gateway and connect a messenger:

hermes gateway setup

The setup wizard walks you through the platforms and helps you enter the bot token and access list. The steps for connecting Telegram (creating a bot with BotFather, finding out your ID, and entering the token) are covered in the main installation guide; I won't repeat them here.

Next comes the trap people most often forget about. If you simply run hermes gateway, the process will live only as long as the SSH session stays open. Close the terminal, and the gateway stops. To keep it running continuously, you need to put it under the system's control. There's one command for that:

hermes gateway install

It installs the gateway as a service: on Linux, a user systemd service; on macOS, through launchd. The system monitors the process and brings it back up if it crashes.

On a server, you'll more often need the second option: a system service that starts when the machine boots, before any user signs in:

sudo hermes gateway install --system

That's exactly what you need for a VPS: the server reboots, the service starts by itself, and the bot is online again. Manage it with these straightforward commands:

hermes gateway start     # start
hermes gateway stop      # stop
hermes gateway status    # check status

For a system service, add sudo and the --system flag to these commands. Without them, the commands will target the user service instead of the one that starts at boot:

sudo hermes gateway start --system
sudo hermes gateway stop --system
sudo hermes gateway status --system

Why is linger needed, and what breaks without it?#

This is the most common stumbling block: you installed the service, but the bot still goes quiet at night. The reason is how Linux user services work.

A user systemd service is tied to your session by default. You connect over SSH, and your user manager starts; the service runs. You log out, and the system considers the user inactive, so it shuts down that user's services along with your gateway. For a server you log in to and out of, this is a failure: the bot is online only while you're in SSH.

You can fix this with linger mode, which lets the system keep the user manager running even when that user isn't logged in:

sudo loginctl enable-linger username

After this command, the user service runs on its own and starts when the server boots, without waiting for you to log in. Without linger, things revert to the original behavior: the gateway shuts down when you leave SSH and doesn't start at boot. The documentation states this explicitly.

How do you run Hermes on a server in Docker with automatic restarts?#

Docker is another working way to keep the agent on a server, especially if you're already used to containers or want to isolate the agent from the main system. Configure it once with docker run ... setup, then start the container in the background:

docker run -d \
  --name hermes \
  --restart unless-stopped \
  -v ~/.hermes:/opt/data \
  -p 8642:8642 \
  nousresearch/hermes-agent gateway run

Here's what the lines responsible for around-the-clock operation do:

• -d — the container runs in the background and doesn't hold your terminal open.
• --restart unless-stopped — Docker brings the container back after a server reboot or a crash. It won't restart it only if you stopped it manually.
• -v ~/.hermes:/opt/data — settings, keys, sessions, and memory live on the server, outside the container, and survive recreating it.

The image adds another safeguard: the gateway process runs under the s6 supervisor. If the gateway crashes, it is restarted within a couple of seconds without losing the container itself. That's double protection: Docker keeps the container running from the outside, while s6 monitors the process inside.

Remember one difference with the Docker approach: these installations don't update with the hermes update command. To update in Docker, replace the image with a new one—download the latest and recreate the container.

How do you check that everything works and will survive a reboot?#

For a user service, check its status and logs like this:

hermes gateway status
journalctl --user -u hermes-gateway -f

For the system service recommended for a VPS, use the system scope instead:

sudo hermes gateway status --system
sudo journalctl -u hermes-gateway -f

The first command checks the selected service; the second follows that scope’s log. These unit names apply to the default ~/.hermes installation. Other Hermes homes can have a suffixed unit name: inspect the status output and use that exact unit. Do not monitor a user unit while testing a system installation. Hermes logs are in ~/.hermes/logs/, and secrets are automatically redacted from them, so it's safe to send them to support.

Now reboot the server and make sure the agent comes back by itself. This is the main server test, and it's usually the one people forget:

sudo reboot

After the server is reachable again, reconnect over SSH. For the system installation, check sudo hermes gateway status --system and its system journal; for the user installation with linger, check hermes gateway status and its user journal. Then message the bot on Telegram. If it answers without your involvement, automatic startup is configured correctly. That's what this was all for.

There's no need to worry about losing your conversation. Hermes writes sessions to disk, and they survive a gateway restart. What's more, if the gateway crashes just as it sends a response, it will deliver that response after recovery instead of running the task again. This matters for a round-the-clock bot: an unexpected restart won't break the conversation.

How do you secure an agent with terminal access on a server?#

An agent on a server is a program with terminal access that runs without your supervision. Check these three settings first.

Closed bot access. By default, the gateway responds only to people on the access list or those who have completed code-based linking in a direct message. That's the right behavior for a bot with terminal access: a random person who messages the bot can't do anything. The list is set using numeric IDs, for example, for Telegram:

TELEGRAM_ALLOWED_USERS=123456789,987654321

Confirmation for dangerous commands. Before doing anything destructive, the agent asks your permission. There's a YOLO mode that disables confirmations; it's best not to enable it on a server running without you. Confirmations are there precisely to prevent anything irreversible from happening without your knowledge.

A sandbox for full isolation. If you want the agent to be physically unable to see the server's main system, run its commands in a Docker container:

hermes config set terminal.backend docker

Then everything the agent does in the terminal happens inside an isolated sandbox and can't reach the live server. That's a sensible safeguard when you give the agent freedom to act on its own.

What should you do if the bot is silent or the gateway crashes?#

When the bot stops responding, follow this order. First check the scope you installed: sudo hermes gateway status --system and the system journal for a system service, or hermes gateway status and the user journal for a user service. If the gateway is running but messages aren't getting through, it's almost always a platform configuration issue: the bot token is wrong or the person isn't on the access list. Run hermes gateway setup again in the same Hermes home, then inspect the selected service with hermes gateway status --system for system or hermes gateway status for user. A successful setup is not proof that the correct gateway is running.

If the model returns empty or strange responses, check it with hermes model and confirm the provider and sign-in. The general recovery sequence that gets you from “everything is broken” back to working order is: hermes doctor, hermes model, hermes setup, followed by hermes gateway status --system for a system installation or hermes gateway status for a user installation.

One more thing for the rare but unpleasant case when the whole process freezes without actually crashing. A systemd service has a watchdog timer: add this line to ~/.hermes/config.yaml and reinstall the service.

gateway:
  systemd_watchdog_seconds: 120

# For the VPS system service (same Hermes home as the original install):
sudo hermes gateway install --system --force
sudo hermes gateway status --system

For a user service instead, regenerate only that scope with hermes gateway install --force and check hermes gateway status. Choose one scope; do not install both to repair a single gateway.

After that, the gateway regularly signals to the system, “I'm alive,” and if the signals stop, systemd restarts the process automatically. This works only on Linux with systemd, and only for process freezes. The watchdog timer won't affect an ordinary network interruption between the server and the messenger.

What else do people ask about Hermes Agent on a server?#

Get to know Ailoot.