Moving Hermes Agent to a VPS sounds simple until the new machine boots clean and your agent has no idea who it is.
The failure is rarely the binary. You can reinstall a CLI. What hurts is the operating context around it: memory files, skills, cron jobs, scripts, local state, repo workspaces, config, and credential material after client-side encryption. That is the part Keepmyclaw cares about today. OpenClaw and Hermes backup and restore. Not generic chat export. Not browser history. Not a magic prompt vault.
The operator thesis is blunt: treat a VPS move like disaster recovery, not like setup. If you cannot restore Hermes on a clean machine from a backup, you do not have a migration plan. You have a laptop with vibes.
What has to survive the VPS move?
Start with the directories and files that make Hermes useful after the install step.
For a normal Hermes workspace, protect:
~/.hermes/for cron output, sessions, state, scripts, skills, and agent working files~/.openclaw/when the same operator still has OpenClaw credentials or migration state- active project workspaces, especially repos under
~/Projects/ - persona files and product playbooks used by recurring jobs
- custom scripts used by cron jobs
- config files that define provider, model, toolsets, and delivery behavior
- credential files only after client-side encryption
- ledgers under
~/.hermes/state/that prevent duplicate posts, duplicate outreach, and stale experiments
Do not stop at the obvious repo. Hermes cron jobs often depend on tiny helper files that do not look important until they disappear. A script path, a prompt file, a browser automation state file, a Reddit credential location, a GitHub auth assumption. That is where clean-machine restores usually bleed.
Set recovery parameters before touching the server
Pick numbers before the move. Otherwise every restore becomes emotional.
Use these as sane defaults:
- RPO: 15 minutes for active operator state, 24 hours for cold archives
- RTO: 30 minutes to boot Hermes and run a smoke job on the VPS
- retention: 30 daily snapshots, 12 weekly snapshots, 6 monthly snapshots
- restore test cadence: one clean-machine drill every 30 days
- pre-migration freeze window: 10 minutes before the final snapshot
- checksum requirement: SHA-256 for every exported archive
- credential handling: client-side encryption before upload, no plaintext credential backups
- cron verification: list jobs, run one safe read-only job, then inspect output
- repo verification:
git status, branch, remotes, and last commit recorded before migration - rollback window: keep the old machine untouched for 72 hours after the VPS cutover
Those numbers are not sacred. They are a starting point. The mistake is having none.
Take a preflight inventory
Before you back anything up, write down what the old machine thinks exists.
Capture the Hermes version, current provider settings, enabled cron jobs, important script paths, project repo paths, and the current branch state for active repos. For each cron job, record the job name, schedule, prompt, attached skills, script, toolsets, and delivery target. A migrated job without its script or credential file is just a timed failure with better posture.
Also record the current public-action boundaries. If a job can post, reply, deploy, index, or email, the restored VPS must preserve its caps and safety rules. Losing those rules is worse than losing the job.
Keepmyclaw should back up the encrypted runtime state. You should still keep a human-readable manifest beside it. The manifest answers the dumb restore questions fast: which account, which repo, which schedule, which credentials, which jobs are allowed to act.
Four failure scenarios worth planning for
The cron jobs restore without their scripts
Hermes can show the job, but the script path points to a missing file. The run fails later, usually when nobody is watching.
Mitigation: include ~/.hermes/scripts/ in the backup. After restore, compile safe scripts and run read-only smoke checks. For public posting jobs, verify configuration only. Do not test by posting into the void like a raccoon with sudo.
The memory restores but the dedupe ledgers do not
This one is expensive. The agent remembers its voice but forgets what it already published, replied to, indexed, or emailed. Then it repeats old work and looks broken.
Mitigation: treat ~/.hermes/state/ as production data. Restore it before any job runs. Check ledgers for content URLs, social action IDs, experiments, approvals, rejected topics, and do-not-touch rules.
The credentials exist but cannot be used
A credential file can survive the move and still fail because the path changed, file permissions changed, the token expired, or the new VPS lacks a needed CLI login. Do not solve this by spraying secrets into logs.
Mitigation: store credentials only after client-side encryption. After restore, verify presence, expected file path, file mode, and account identity through safe metadata endpoints. Print lengths and account names, not secrets.
The repo restores onto the wrong branch
A migration can restore the files but leave the repo behind origin, ahead of origin, or on an old feature branch. Then the first autonomous edit creates nonsense.
Mitigation: record git status, remotes, current branch, and the last commit before backup. After restore, fetch origin, confirm the default branch, and require a clean state before SEO, checkout, or deployment jobs edit anything.
The VPS clock or scheduler is wrong
Cron work can drift if the VPS timezone, clock sync, or scheduler state changes. A job that used to run hourly now runs twice or misses a window.
Mitigation: record timezone, scheduler status, next run times, and delivery settings before migration. After restore, compare the job list against the manifest before enabling autonomous runs.
The safe migration order
First, pause jobs that can create public side effects. That means posting, replying, deploying, emailing, indexing, or changing production systems. Read-only state jobs can usually stay paused too. Fewer moving pieces. Novel concept.
Second, take the final encrypted snapshot. Include Hermes state, OpenClaw migration state if present, active workspaces, scripts, ledgers, configs, and encrypted credentials. Generate checksums. Store the manifest beside the snapshot.
Third, provision the VPS and install Hermes. Do not start autonomous jobs yet. Restore the encrypted backup, decrypt locally, and place files back at the expected paths. Fix ownership and permissions before running anything.
Fourth, run smoke checks. List Hermes jobs. Inspect a recent session file. Compile scripts. Check project repos. Verify credential metadata safely. Run one read-only cron job and inspect the output file.
Fifth, re-enable jobs in layers. Monitoring jobs first. Draft-only jobs next. Public-action jobs last, and only after their caps, account, ledgers, and prompts match the manifest.
What Keepmyclaw should prove after restore
A backup is only useful if the restored agent can act like the old agent without pretending nothing changed.
The restore should prove:
- Hermes can start on the VPS
- skills and memory are present
- cron jobs list with the expected schedules
- scripts exist at expected paths
- state ledgers survived
- project workspaces are on the expected branches
- encrypted credentials can be used without exposing secrets
- one safe read-only job can run and write output
- public-action jobs remain paused or capped until verified
If any of those fail, keep the old machine alive and fix the restore. Do not cut over because the homepage says the server is online. The server is not the product. The restored operating context is.
The short checklist
Before the move:
- inventory Hermes jobs, scripts, skills, state, configs, and workspaces
- pause public-action jobs
- take a final encrypted snapshot
- generate SHA-256 checksums
- keep the old machine untouched for 72 hours
After the move:
- restore files to the same expected paths
- fix ownership and permissions
- verify credentials through safe metadata only
- run one read-only smoke job
- compare cron schedules against the manifest
- re-enable autonomous jobs slowly
Hermes on a VPS is only an upgrade if the agent wakes up with its working memory intact. Otherwise you just bought a clean machine and renamed the outage.