DEV Community

Cover image for How I run an AI agent 24/7 on a Raspberry Pi (and don't lose its memory)
Jimmy Huang
Jimmy Huang

Posted on

How I run an AI agent 24/7 on a Raspberry Pi (and don't lose its memory)

#ai #raspberrypi #selfhosted #tutorial

AI agents finally got useful this year. The problem I kept hitting wasn't the agent — it was that it had nowhere good to live.

My laptop sleeps. A cheap VPS gets its datacenter IP blocked by half the web. And I didn't love the idea of an agent with a real browser session running on my daily-driver machine, next to everything else.

So I gave it its own computer: a Raspberry Pi that runs Hermes around the clock. This post is how I set it up — focused on the two things that actually separate a demo from something you rely on: staying up, and not losing state.

A small dedicated computer running an AI agent around the clock

Everything here works on any always-on Linux box (a mini PC, a NUC, an old laptop). I'll use a Pi 5 as the concrete example.

Why dedicated, always-on hardware?

You can run an agent on your laptop or a $5 VPS. Both work. A dedicated box earns its place when you hit one of these:

  • Your laptop sleeps. An agent that checks something twice a day or replies to your inbox needs to be awake at 3am. A closed lid isn't.
  • Datacenter IPs get blocked. Lots of the web (retail, banking, social, ticketing) treats VPS IP ranges as bots. A machine on your home connection browses from a residential IP, signed in where you're signed in.
  • You want the memory local. Hermes keeps what it learns about you as files. On your own box, those files stay on your desk — you can read, edit, back them up, and move them.

Honest tradeoff: a small box is not a workstation. It's sized for an agent that works in short bursts around the clock, not for heavy parallel jobs or local model inference. That's the right tradeoff for this job — just know it going in.

1. Baseline

  • A Raspberry Pi 5 (8 GB) with an NVMe SSD, running 64-bit Raspberry Pi OS (or any Debian/Ubuntu box).
  • Install Hermes with the official installer: 
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash
Enter fullscreen mode Exit fullscreen mode
  • Run hermes setup once and pick your model provider with hermes model — a ChatGPT plan, OpenRouter, any API key, or a local endpoint. Hermes is provider-agnostic, so nothing here assumes one.

On Linux/macOS, Hermes stores its state in ~/.hermes by default (memory, skills, config, chat history). I'll refer to it as $HERMES_HOME — confirm the path on your own install:

export HERMES_HOME="$HOME/.hermes"
Enter fullscreen mode Exit fullscreen mode

2. Keep it running with systemd

Run the agent as a service so it starts on boot and restarts if it dies:

# /etc/systemd/system/hermes.service
[Unit]
Description=Hermes Agent
After=network-online.target
Wants=network-online.target
# don't hammer restarts if it's crash-looping
StartLimitIntervalSec=300
StartLimitBurst=5

[Service]
Type=simple
User=hermes
WorkingDirectory=%h
# `hermes gateway` runs the always-on messaging gateway (Telegram, Discord, etc.)
# Use the absolute path from `which hermes` — usually ~/.local/bin.
ExecStart=%h/.local/bin/hermes gateway
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target
Enter fullscreen mode Exit fullscreen mode 
sudo systemctl daemon-reload
sudo systemctl enable --now hermes
systemctl status hermes
Enter fullscreen mode Exit fullscreen mode

3. Survive a power cut

An always-on box will lose power eventually. Make sure it comes back on its own:

  • Auto power-on after an outage. On a mini PC/NUC, enable "Restore on AC Power Loss" in the BIOS. A Pi powers on whenever it gets power, so just make sure its circuit does.
  • Boot straight into the service. systemctl enable (above) already handles that.
  • Optional hardware watchdog. Many boards (the Pi included) expose a watchdog that reboots the machine if the kernel hangs — enable it via RuntimeWatchdogSec in /etc/systemd/system.conf for an extra safety net.
  • Use a journaling filesystem (ext4/xfs — the default) so an abrupt power loss doesn't corrupt state mid-write.

The always-on box running headless after a reboot

4. Back up what matters

The whole point of a persistent agent is that it remembers. So the thing you must protect is $HERMES_HOME. Back it up encrypted, on a schedule, and off the box.

I use age for encryption because it's tiny and transparent, and I packaged the whole backup/verify/restore/health flow into a small open skill so I'm not copy-pasting shell each time: hermes-backup-recovery.

The core of backup.sh is just:

# encrypted, timestamped, with retention
tar -C "$(dirname "$HERMES_HOME")" -czf - "$(basename "$HERMES_HOME")" \
  | age -r "$AGE_RECIPIENT" -o "$BACKUP_DIR/hermes-$(date -u +%Y%m%dT%H%M%SZ).tar.gz.age"
Enter fullscreen mode Exit fullscreen mode

Run it nightly with a systemd timer, and keep at least one copy off the box — another machine, a NAS, or object storage. A backup that lives on the same SSD as the original doesn't survive that SSD dying. Keep the age private key off the box too, or a thief/failure takes both.

Encrypted backups of the agent's state stored off the device

5. Prove you can restore

A backup you've never restored is a guess, not a backup. Once a month I run a restore drill into a scratch directory and confirm the files come back:

# from the hermes-backup-recovery skill
BACKUP_DIR=/backups AGE_IDENTITY=~/age/keys.txt ./scripts/verify.sh
RESTORE_TARGET=/tmp/restore-drill ./scripts/restore.sh --apply /backups/hermes-<timestamp>.tar.gz.age
Enter fullscreen mode Exit fullscreen mode

verify.sh checks the checksum and test-decrypts the archive; restore.sh is dry-run by default and only writes with --apply.

6. Health checks

Catch problems before they're outages. A one-shot check (service up, disk not full, last backup recent) on a timer, exiting non-zero when something needs attention, wired to whatever notification you already read:

./scripts/healthcheck.sh   # exit 0 = healthy, 1 = look at me
Enter fullscreen mode Exit fullscreen mode

7. Security basics

  • Keep it on your LAN. You don't need to expose the agent to the public internet. Reach it over your home network or a private tunnel (Tailscale/WireGuard). Don't port-forward it.
  • Secrets in root-only files (chmod 600), never committed anywhere.
  • Run it as its own unix user, not root, so a bad browsing session can't touch the rest of the box.

The agent kept on a private LAN rather than exposed to the internet

Wrapping up

Two repos with everything above, both MIT:

I got tired of wiring this up by hand on every box, so I ended up packaging it into a small always-on computer that ships with Hermes, the dashboard, and backups/recovery preconfigured — MangoTart. That part's optional; the guides above stand on their own on hardware you already have.

If you're running an agent 24/7 on something, I'd love to hear what board and what breaks for you — that's half the reason I wrote this down.

Top comments (0)