How to Migrate Hermes Agent to a New Cloud Server

A Hermes Agent migration involves transferring your existing AI agent to another cloud server while preserving its configuration, persistent memory, session history, skills, and scheduled tasks. A successful migration allows you to continue your automation workflows without losing saved information or interrupting essential services.

Moving an existing Hermes setup requires more planning than a fresh installation. You need to protect API keys, transfer application data, restore integrations, and verify scheduled work. Running both server instances simultaneously also risks duplicate task execution.

This tutorial explains how to migrate Hermes Agent between two Ubuntu 24.04 cloud servers using its built-in backup and restoration commands.

How To Migrate Hermes Agent To A New Cloud Server

To migrate Hermes Agent to a new server, pause scheduled work and stop the gateway on your old server. Create a complete backup using hermes backup, transfer the archive securely with SCP, and restore your data using hermes import. Verify your memory, credentials, sessions, and cron jobs before starting production automation on the new VPS.

The following commands summarize the process.

On your old cloud server, pause the agent and stop its messaging gateway.

hermes pause
hermes gateway stop

Create a complete Hermes backup.

hermes backup -o ~/hermes-migration.zip

Transfer the backup to your new server.

scp ~/hermes-migration.zip hermesops@NEW_SERVER_IP:~/

On the new server, install Hermes Agent using its Linux installer, then restore the backup.

hermes import ~/hermes-migration.zip

Run diagnostics and verify your saved information.

hermes doctor
hermes sessions list
hermes skills list
hermes cron list

After checking the restored environment, start the destination gateway and resume scheduled work.

hermes gateway start
hermes resume

Keep the old gateway stopped during the cutover. The detailed procedure below explains each stage, including backup verification, installation requirements, and protection against duplicate scheduled jobs.

Hermes Agent Migration Workflow

The migration follows six stages, from reviewing your existing configuration to activating the new production environment.

Old Cloud Server

1. Review configuration, API keys, memory, and cron jobs
2. Pause Hermes Agent and stop the gateway
3. Create and verify the full backup
4. Transfer the ZIP archive securely over SSH
5. Install Hermes and restore data on the new cloud server
6. Validate memory, sessions, skills, and scheduled jobs
7. Start the new gateway and resume automation

The old server must remain inactive while the new production scheduler runs. This prevents duplicate messages, repeated API requests, and conflicting automation tasks.

Why Move Hermes Agent To Another VPS?

Hermes Agent is an open-source AI assistant developed by Nous Research. Its key features include persistent memory, terminal commands, web search, code execution, image generation, and recurring tasks. Hermes also supports multi-platform messaging through Telegram, Discord, Slack, Signal, and other integrations.

Several situations might require moving an existing Hermes instance.

• Server upgrades: Move to a VPS with more RAM, CPU resources, or storage.
• Provider changes: Switch cloud providers for pricing, reliability, or geographic requirements.
• Infrastructure changes: Move from a local machine to an always-on hosted agent.
• Security improvements: Replace an outdated server or isolate automation workloads.
• Performance requirements: Allocate dedicated resources to demanding AI automation.

Self-hosting Hermes Agent on your own VPS provides control over the operating system, installed tools, and application data. You also select the LLM provider and manage your own keys.

Hosting expenses include VPS resources, LLM API calls, and any additional paid services. External AI providers still receive prompts and context sent through their APIs.

For more information about persistent automation, see Hermes Agent Hosting for Always-On AI Work.

What Happens To Existing Hermes Agent Data?

Hermes stores most application data under the following directory:

~/.hermes/

The directory contains several files essential for migration:

• config.yaml: Agent configuration, model settings, tools, and gateway options.
• .env: API keys, bot tokens, and other environment variables.
• state.db: Persistent state and session information.
• skills/: Installed and user-defined skills.
• cron/jobs.json: Scheduled job definitions.
• cron/output/: Output from previous scheduled executions.
• logs/: Agent, gateway, and error logs.

Additional files store authentication information, memory, user context, and platform connections.

Hermes also supports separate profiles. Each profile stores its own settings and associated data.

A full backup preserves supported Hermes application data. External project files, SSH keys, Docker volumes, and directories outside the Hermes home require separate handling.

Plan Your Hermes Agent Migration

Before changing servers, review your existing environment and define a migration plan.

Your new instance should use the same configuration, memory, skills, and scheduled jobs unless you intentionally modify them.

Review The Existing Hermes Setup

Connect to your old server through SSH.

ssh USERNAME@OLD_SERVER_IP

Replace USERNAME and OLD_SERVER_IP with your existing SSH account and server address.

Check the installed Hermes Agent version.

hermes --version

Next, inspect the current model configuration, available providers, gateway connections, and scheduled jobs.

hermes status --full
hermes gateway status
hermes cron list
hermes cron status

The status output shows your default Hermes model, configured providers, active messaging platforms, and scheduled automation.

Run the diagnostic tool to identify configuration problems before migration.

hermes doctor

Record the installed version, LLM provider, enabled skills, bot token configuration, and external service dependencies.

Also review custom terminal backends, Docker containers, cloud browser connections, voice services, and other integrations.

Define Migration Success Criteria

A successful migration should meet the following requirements:

• Configuration, persistent memory, skills, and session history remain available.
• Existing cron jobs retain their schedules and delivery destinations.
• Model authentication and messaging connections work.
• External scripts and workspace directories remain accessible.
• Only one production instance executes scheduled automation.

Choose a maintenance window with minimal scheduled activity. Check for tasks involving database updates, notifications, file changes, or Home Assistant integrations.

Keep the old VPS available until the new server passes validation.

Back Up Hermes Agent Configuration, Memory, And Cron Jobs

Hermes includes backup functionality to export application data.

For an existing installation, the fastest way to transfer supported Hermes data without manually rebuilding the configuration is to use the built-in Hermes backup and Hermes import commands.

Pause Scheduled Tasks And Stop The Gateway

Before generating the final backup, pause your agent.

hermes pause

This command prevents new scheduled fires, gateway turns, and supported background dispatches from starting.

Existing tasks continue until completion. Review active operations before proceeding.

Stop the messaging gateway.

hermes gateway stop

Confirm the gateway status.

hermes gateway status

The gateway should report a stopped state.

If your infrastructure uses additional schedulers, systemd services, or external automation tools, stop those separately.

Freezing the source environment prevents new session changes during the final migration process.

Create A Complete Hermes Agent Backup

Set restrictive default permissions before creating the archive.

umask 077

Create a complete Hermes Agent backup with one command.

hermes backup -o ~/hermes-migration.zip

Hermes creates a ZIP archive containing supported configuration, authentication, session data, skills, and scheduled work.

The backup process uses SQLite’s backup mechanism to create consistent database copies.

Verify the generated archive using the following commands.

cd ~
ls -lh hermes-migration.zip
unzip -tq hermes-migration.zip

The first command displays the archive size—the second tests ZIP integrity.

The following terminal output was reproduced using the Linux unzip utility against a sample ZIP archive. This success message indicates the archive passed the integrity check.

No errors detected in compressed data of hermes-migration.zip.

This confirms ZIP integrity, not the completeness of your Hermes data. Also check the exit status of the original Hermes backup command. Hermes reports exit code 0 only when every selected file is saved.

For smaller snapshots, Hermes also provides:

hermes backup --quick

This option saves critical configuration, credentials, database state, and cron definitions. A full backup is preferable for server migration because quick mode excludes other application content.

Full backups also exclude regenerated runtime downloads, selected caches, SQLite journal files, browser login profiles, and the Hermes application code.

Copy required external project files separately.

Protect API Keys And Sensitive Configuration

Your backup might contain OpenAI, Anthropic, OpenRouter, or Nous Portal authentication details.

Messaging credentials, SSH references, and other secrets also require protection.

Restrict archive access.

chmod 600 ~/hermes-migration.zip

Verify the file permissions.

stat -c '%a %n' ~/hermes-migration.zip

A mode of 600 confirms read and write access for the file owner only.

Avoid transferring backups through public file-sharing services. Use encrypted storage and authenticated SSH connections.

Rotate sensitive credentials when exposure is suspected. Review environment-specific secrets after restoration.

Prepare The New Cloud Server for the Hermes Agent

Provision a new Ubuntu 24.04 VPS before transferring your data.

For example, you can create an Atlantic.Net Cloud Server and select a suitable instance size and deployment location.

Atlantic.Net also provides a Hermes Marketplace application for simplified installation.

Check The Destination Server Requirements

Verify the operating system, CPU, RAM, available disk space, and SSH connectivity.

For cloud deployments using external LLM providers, 2 GB RAM is a reasonable starting point. Browser automation, Docker workloads, concurrent tasks, and local AI models need additional resources.

Hermes also requires an AI model with at least 64,000 tokens of context for tool-based agent workflows. This refers to the model’s context window, not server RAM.

Check the destination resources.

free -h
df -h
nproc

These commands display available memory, disk capacity, and CPU cores.

Confirm outbound HTTPS access and install only the network services required by your deployment.

Create A Non-Root User And Install Hermes Agent

Create a dedicated account for your agent.

sudo adduser --disabled-password --gecos "" hermesops

Configure SSH public-key access for this account before transferring files.

Switch to the new user.

sudo -iu hermesops

Install Hermes Agent using the Linux installation command.

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

The installer downloads Hermes and its dependencies. The Hermes setup wizard offers three modes: Quick Setup, Full Setup, and Blank Slate. Select the appropriate option before restoring your existing configuration.

Reload your shell configuration.

source ~/.bashrc

Verify the installation.

hermes --version

Compare the installed version with the source server. Prefer a compatible release before restoring an older configuration.

Windows installations use a separate PowerShell installer:

iex (irm https://hermes-agent.nousresearch.com/install.ps1)

For detailed Ubuntu installation instructions, see How to Set Up Hermes Agent on an Atlantic.Net Cloud Server.

Check Hermes Before Restoring Data

Run preliminary diagnostics.

hermes doctor
hermes gateway status

Missing provider credentials are expected before importing your existing configuration.

Stop the destination gateway if the installer started a service.

hermes gateway stop

Keep scheduled production work disabled until restoration and validation finish.

Transfer And Restore Hermes Agent To The New Server

After preparing the new server, transfer your archive through SSH.

Transfer The Hermes Backup Using SCP

On the old server, generate a SHA-256 checksum for your backup.

cd ~
sha256sum hermes-migration.zip > hermes-migration.sha256

Transfer the archive and checksum file to your destination account.

scp ~/hermes-migration.zip ~/hermes-migration.sha256 hermesops@NEW_SERVER_IP:~/

Replace NEW_SERVER_IP with the destination server address.

Connect to the new VPS.

ssh hermesops@NEW_SERVER_IP

Verify the transferred archive.

cd ~
sha256sum -c hermes-migration.sha256

A matching checksum produces the following output. This result was reproduced with the Linux sha256sum utility using a sample archive.

hermes-migration.zip: OK

If the output reports FAILED, repeat the transfer and investigate the mismatch before importing.

Test the archive again.

unzip -tq hermes-migration.zip

Successful checksum and archive checks confirm transfer integrity. They do not verify the completeness of application data.

Restore Hermes Configuration And Memory

Restore the existing Hermes setup using the import command.

hermes import ~/hermes-migration.zip

Hermes extracts the archive into the active Hermes home directory.

When an existing installation is detected, the import process requests confirmation before overwriting its files.

The restored data includes supported configuration, credentials, sessions, memory, skills, and cron definitions.

Check for skipped files or restoration errors. Incomplete imports return a nonzero exit status.

Avoid running the gateway during restoration. Active database connections and file operations might interfere with imported state.

After restoration, confirm the configuration.

hermes config check
hermes status --full
hermes cron list

Review custom filesystem paths, working directories, and other settings tied to the previous server.

If your installation uses external databases or mounted storage, restore those dependencies separately.

Restore AI Models, API Keys, And Integrations

Check the selected Hermes model.

hermes model

Confirm the configured provider and default AI model.

Run the setup wizard to verify provider authentication and restored credentials.

hermes setup

Hermes supports several AI model providers, including OpenAI, Anthropic, OpenRouter, and Nous Research. Review the supported providers and confirm your existing configuration after migration.

Nous Portal provides access to supported AI models and Tool Gateway services through one subscription, with applicable usage charges. Alternatively, you can configure individual providers using your own API keys.

You can switch providers using the Hermes model command after migration, although moving Hermes Agent to another server does not require changing your existing LLM provider.

Review messaging settings, bot credentials, web search integrations, image generation, voice services, and Docker execution environments.

Tools using local paths or server-specific IP addresses require configuration changes.

Verify Hermes Agent After Migration

Don’t treat a successful import as proof of a complete migration.

Verify configuration, memory retention, session history, scheduled jobs, and external service connections before activating production work.

Run Hermes Diagnostics On The New VPS

Start with the following commands.

hermes doctor
hermes config check
hermes status --full

These checks help identify missing dependencies, invalid configuration values, and provider authentication issues.

Check the restored gateway configuration.

hermes gateway status

A stopped gateway is expected before production activation.

Verify Persistent Memory, Sessions, And Skills

Inspect the restored session history.

hermes sessions list

Compare available sessions with your source inventory.

Review the installed skills.

hermes skills list

After the production cutover, resume a previous conversation to confirm access to saved context.

hermes --resume latest

Ask about a harmless fact recorded before migration. Confirm the answer matches the saved information.

Also test safe code execution, such as checking the operating system version through an approved terminal tool.

If your workflows use external scripts, verify file permissions and executable paths.

Validate Cron Jobs And Messaging Connections

Inspect the scheduler configuration.

hermes cron list
hermes cron status
hermes cron doctor

Hermes stores scheduled job definitions in cron/jobs.json and execution output under cron/output/.

Check each job’s schedule, time zone, model selection, working directory, and delivery destination.

For example, a daily Telegram status report should retain its schedule and target chat after migration.

Review Telegram, Discord, Slack, and Signal connections where configured. Test actual message delivery after the old production gateway is disabled.

Inspect gateway logs for connection or authentication errors.

hermes logs gateway -n 100

Switch Servers Without Running Duplicate Cron Jobs

The most important part of a Hermes Agent migration is controlling scheduled work during cutover.

Running two copies with identical cron jobs creates duplicate executions.

For example, two active instances might send the same Telegram notification, update a database twice, execute duplicate shell commands, or repeat external API requests.

Hermes uses scheduler locking and execution records within its own environment. Separate servers do not automatically share those controls.

Activate Only One Production Scheduler

Leave the old gateway stopped after creating the final backup.

On the new server, pause production automation before starting its gateway.

hermes pause

Review the imported jobs and their next execution times.

Hermes normally attempts to recover missed recurring schedules after a gateway restart.

For a planned scheduler migration, you can disable catch-up of sufficiently overdue recurring jobs.

hermes config set cron.catch_up_missed false

This setting skips overdue jobs outside their grace windows. Jobs still inside the grace window and manual executions follow separate rules.

After confirming the source gateway remains stopped, start the destination gateway.

hermes gateway start

Check service status.

hermes gateway status

Confirm restored messaging connections and scheduler readiness.

Resume the new instance when the cutover is approved.

hermes resume

Monitor the first scheduled execution.

hermes cron list
hermes logs gateway -n 100

Check the task output, execution status, and delivery result.

Keep the old instance disabled until the new environment operates successfully.

Roll Back A Failed Hermes Agent Migration

If validation fails, pause the destination agent and stop its gateway.

hermes pause
hermes gateway stop

Investigate the problem before reactivating the source server.

Review session changes, completed jobs, and external operations performed since the original backup. Avoid repeating irreversible tasks.

When rollback is approved, resume the original agent.

hermes gateway start
hermes resume

Confirm the new server remains inactive.

Preserve migration backups and execution logs until the rollback period ends.

Best Practices For Future Hermes Agent Migrations

Create scheduled backups of your Hermes environment. Store backup archives outside your production VPS and restrict access to authorized administrators.

Test restoration periodically using an isolated environment without active production cron jobs or messaging gateways.

Maintain a record of installed versions, external dependencies, server settings, and custom automation scripts.

Use Linux firewall rules and appropriate cloud security controls to protect your instance. Hermes provides separate application-level protections, including configurable tool permissions and outbound credential controls.

Hosting-provider DDoS protection is an infrastructure service, not an automatic Hermes feature.

Monitor agent logs for unusual activity, failed tasks, and authentication problems.

For large migrations, incremental file transfers might reduce transfer time for external workspaces. Always create a consistent final Hermes backup before switching production workloads.

Conclusion

Moving Hermes Agent to a new cloud server requires careful planning to preserve your existing configuration, persistent memory, session history, and scheduled automation.

Begin by reviewing your current Hermes setup. Record the installed version, selected AI models, active messaging platforms, configured skills, and recurring tasks. Identify external files or services requiring separate migration.

Next, pause the source agent, stop its gateway, and generate a complete backup using the built-in Hermes backup command. Securely transfer the archive to your destination VPS, then restore the environment with hermes import.

After restoring your data, run Hermes diagnostics and review the configuration. Check provider credentials, saved sessions, memory, installed skills, cron jobs, and messaging integrations. Update server-specific paths and external dependencies where necessary.

The final migration stage requires special attention. Keep the old gateway disabled before activating the new production scheduler. This prevents duplicate notifications, repeated commands, and conflicting automation tasks.

Atlantic.Net offers cloud servers and a Hermes Marketplace deployment option for running a persistent AI agent. Choose resources according to your workload and infrastructure requirements.

With a complete backup, validated restoration, and controlled scheduler cutover, your Hermes Agent migration preserves existing workflows and provides a clear path for future server upgrades.