Hermes Agent Backup and Restore: Move VPS Without Losing Memory

For a full Hermes Agent backup, use hermes backup. On the destination machine, use hermes import with the resulting archive. The part that needs care comes afterwards: checking that you restored the right memory, credentials and jobs, without leaving two machines running the same automation.

This guide covers a planned VPS move and a rehearsal for server failure. The commands below were checked against the official documentation on 6 September 2026. This is a documented procedure and a proposed acceptance checklist, not a claim that we have tested every provider or Hermes version.

Download the restore-drill checklist (CSV). Open it in your spreadsheet, assign an owner and record evidence for each check. Keep passwords, API keys and customer data out of that sheet.

Choose the backup that matches the job

Hermes has several operations that sound similar. They solve different problems.

The official backup and migration guidance describes a ZIP archive of the Hermes home, including memory, skills, sessions, configuration and profiles. It also includes API keys. The default destination is your home directory, with a timestamped hermes-backup- filename.

For a single profile, the profile command reference documents a separate export/import flow. Do not treat that archive as a substitute for a full machine migration.

Write down what a successful restore means

Before taking a backup, choose a handful of things you can recognise afterwards. “The agent starts” is too weak.

Use harmless examples: a known saved preference, a non-sensitive skill, the number of expected profiles and a scheduled job that you can keep disabled during the rehearsal. Record where tools read and write files. A path that exists on one server may be absent on the next.

Then list everything outside Hermes: attached volumes, an external database, a webhook URL, DNS, firewall rules, operating-system packages, provider accounts and service configuration. Decide how each will be recreated or deliberately left disconnected. This is an inventory exercise, not an invitation to export more secrets into a spreadsheet.

Agree two practical limits with whoever relies on the automation:

• How much recent work could you afford to lose? That determines the useful backup frequency.
• How long could the workflow be unavailable? That determines the recovery rehearsal you need.

A daily archive is not enough for a workflow that cannot lose a day's changes. An archive stored only on the failed VPS is not a recovery copy.

1. Create and protect the archive

Check that the commands exist in your installed version before starting:

bashhermes backup --help
hermes import --help

If either is unavailable, consult the documentation for your installed release and plan the upgrade separately. Do not start a hurried upgrade during an outage simply to make this guide fit.

Run the backup under the account and Hermes home you intend to preserve:

bashhermes backup

Use the exact archive path reported by the command. Record its timestamp and size, then keep a protected copy away from the source VPS. Transfer it over an authenticated, encrypted connection to a destination you control. The archive contains credentials, so do not attach it to a support ticket or upload it to a public repository.

Check that the destination received the same bytes. On Linux, sha256sum can calculate a digest of the archive on each machine; compare the results. Matching digests establish transfer integrity. They do not prove the contents will restore or that the source was trustworthy.

2. Prepare a quiet destination

Install Hermes using the official installation instructions. Record the installed version and any differences from the source. For a planned move, avoid combining migration with an unrelated model, tool or operating-system change: each extra change makes failures harder to trace.

Use a fresh destination account or isolated test environment. Do not import over an existing working Hermes home without separately protecting it and checking the import behaviour for your release.

Before restoring, make sure the destination cannot process real incoming messages or run production jobs. That may mean keeping its gateway stopped, withholding network access to production integrations, or using test accounts. Choose controls that actually cover your tools. A disconnected chat channel does not stop a separately scheduled job from contacting an API.

3. Import, then inspect

Replace the example path below with your actual archive path:

bashhermes import ~/hermes-backup-EXACT-TIMESTAMP.zip
hermes setup

The official FAQ uses hermes import for full restoration and hermes setup to verify configuration afterwards. Review provider credentials, model settings and paths before reconnecting the agent to anything live.

Work through the checklist while the destination remains isolated:

Do not “test” the restore by sending a real customer campaign or changing production records. Use a controlled recipient and a reversible test task. Check the outcome in the receiving system, not just the agent's description of what happened.

4. Cut over once, with a way back

For a planned move, choose a quiet window. Pause the source workflow, account for work already in progress and take a final backup if state has changed since the rehearsal. Restore that final state and repeat the checks that protect against duplicate actions.

Only then enable the destination's production gateway and jobs. Keep the source stopped. Verify one controlled incoming request and its downstream result before declaring the move complete.

The gateway documentation distinguishes foreground operation, user services and Linux system services. Check which service scope and profile you actually installed. Inspecting a user service does not prove that a separately installed system service is stopped.

If cutover fails, stop the destination before restarting the source. First reconcile any actions the destination already completed. Otherwise a rollback can replay work as easily as a migration can.

For fault diagnosis, use our Hermes monitoring, logs and recovery guide. It covers the difference between a dead service and a running agent whose provider or tools have failed.

Backups before updates need a separate decision

The current update documentation distinguishes the normal pre-update snapshot from a full backup. Its quick snapshot skips individual files larger than 1 GiB. Use the documented full-backup option when that boundary does not meet your recovery needs:

bashhermes update --backup

That command also performs an update. It is not the command to run when you only want a standalone archive. Use hermes backup for that.

Keep a record of the code version and dependencies alongside the recovery record. Restoring agent data alone does not establish that an older application version, system package or external integration has been restored with it.

Turn one successful restore into a routine

Record the date of the last completed rehearsal, the backup used, the person who performed it, the time until the harmless workflow succeeded and any missing dependency. Leave failed checks visible until resolved.

Repeat after material changes to the agent's tools, storage or deployment. Someone other than the person who built the system should be able to follow the instructions. If they need to ask where an undocumented token or script lives, you have found a recovery gap before the outage.

For the wider setup, start with the Hermes deployment guide. If you are deciding whether Oracle suits the workload, read the Oracle Cloud deployment guide and its hosting limits before committing.

A business automation needs an owner, a useful outcome and a recovery route. To discuss that wider system, see AI automation or Get unstuck.