Skip to content

Deploy Hermes Agent in a macOS VM on Apple Silicon

A Hermes Agent macOS VM lets you install and test Hermes inside a separate macOS guest instead of giving it your everyday Mac account. Kyvenza creates the macOS arm64 VM on Apple Silicon; once the guest is running, Hermes sees that guest as its Mac and keeps its files, sessions, credentials, launchd service, and tool state there.

Use this workflow when you want local macOS behavior without putting a new agent runtime directly on your host. It is useful for evaluation, macOS-specific gateway testing, and safer experiments with terminal tools, but it is still a local VM that stops when your Mac sleeps, shuts down, or loses network access.

When a Hermes Agent macOS VM fits

Kyvenza is a good fit when you want a Hermes Agent macOS VM that behaves like a small secondary Mac, not a shared folder inside your main user account.

Use this workflow when:

  • You want to try Hermes before installing it on your host Mac.
  • You need macOS behavior, such as launchd service setup, macOS browser permissions, or account-backed messaging flows.
  • You want Hermes memory, skills, sessions, provider credentials, and gateway logs separated from your main account.
  • You are testing agent tool access and want a VM you can stop, clone, or delete when the experiment is done.
  • You want to connect messaging platforms carefully without exposing your host files to the agent.

Use the Linux ARM VM Hermes guide instead when you want a server-like setup, Docker terminal backend, or a workflow closer to a VPS. Docker Desktop inside a macOS guest depends on nested virtualization, which Kyvenza does not support.

Requirements

On the Mac host:

  • An Apple Silicon Mac running macOS 14.0 Sonoma or later.
  • Kyvenza installed and past first-run onboarding. See Install Kyvenza and System requirements.
  • Enough free disk space for the macOS restore image, the VM disk, Hermes data under ~/.hermes, package caches, logs, and workspace files.
  • A Kyvenza Free or Pro entitlement. The Free tier allows up to three VMs; Pro removes that VM count limit. See Licensing.

Inside the macOS guest:

  • Internet access.
  • An administrator account for the first install.
  • Git available before running Hermes' git-based installer.
  • A model provider account or endpoint you plan to configure with Hermes.

Hermes' official installer handles uv, Python 3.11, Node.js 22, ripgrep, and ffmpeg after Git is available. Read the official Hermes installation guide, quickstart, messaging gateway guide, and security guide before connecting real accounts.

Create the macOS VM in Kyvenza

  1. Open Kyvenza.
  2. Click New VM.
  3. Choose macOS as the guest type.
  4. Name the VM something explicit, such as hermes-macos.
  5. Start with at least 4 vCPUs, 8192 MB of memory, and 128 GB of disk if your Mac has enough headroom. Hermes can accumulate sessions, logs, skills, browser state, and package caches over time.
  6. Leave shared folders empty for the first install. Add a narrow shared folder later only when a task truly needs host files.
  7. Review the configuration and click Create VM.

Kyvenza downloads the latest supported macOS IPSW automatically and creates the VM with its bundled Lume backend. The first macOS VM can take a while because the restore image is large.

Start the VM, open the console, and complete macOS Setup Assistant inside the guest. For a basic Hermes CLI or gateway test, you do not need to sign in with your primary Apple ID. If you later test account-backed services, do that deliberately inside the VM and treat the guest as a separate Mac.

For the general VM workflow, read Create your first VM, Managing VMs, and Importing images.

Prepare the macOS guest

Open Terminal inside the VM and confirm the basics:

bash
sw_vers
git --version
curl --version

If git is missing, install Apple's command line developer tools when macOS prompts you, or install Git using your preferred macOS package manager inside the guest. Do not rely on host tools; Hermes runs inside the VM and only sees the guest environment.

If you plan to keep this VM around, install any macOS updates you want before Hermes. A clean, updated guest is easier to clone later if you have Kyvenza Pro.

Deploy Hermes Agent in the macOS VM

Run Hermes' official installer from Terminal inside the guest:

bash
curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash

Reload your shell so the hermes command is available:

bash
source ~/.zshrc

Run the setup wizard:

bash
hermes setup

Use the setup flow to choose your model provider, configure credentials, and decide which tools should be enabled. Then verify the install:

bash
hermes --version
hermes doctor

Start with a normal local conversation before you add messaging platforms, cron jobs, skills, or broad tool access:

bash
hermes

If the base chat works, configure the messaging gateway:

bash
hermes gateway setup

Install and run the gateway as a macOS launchd agent inside the VM:

bash
hermes gateway install
hermes gateway start
hermes gateway status
tail -f ~/.hermes/logs/gateway.log

Hermes writes the launchd plist to:

text
~/Library/LaunchAgents/ai.hermes.gateway.plist

Because launchd plists capture environment details at install time, rerun hermes gateway install after you add important tools to the guest PATH. That lets the gateway pick up new binaries for browser automation, messaging bridges, or other subprocesses.

Keep the Hermes Agent macOS VM isolated

In this workflow, Hermes' "host" is the macOS guest. The agent can work with files, shells, browser state, credentials, and messaging sessions inside the VM, but it cannot read your host Mac's files unless you intentionally expose them.

Use that boundary deliberately:

  • Do not share your host home directory with the VM.
  • Do not share ~/.ssh, browser profiles, password-manager exports, private repositories, or client folders.
  • If you need file exchange, create a small folder such as ~/Kyvenza-Hermes-Exchange and share only that path.
  • Prefer read-only shared folders when Hermes only needs to inspect files.
  • Keep provider keys and messaging tokens scoped to the experiment.
  • Use one VM per Hermes profile when you want separation between personal, research, and work contexts.
  • Run hermes doctor after changing providers, tools, gateway auth, or messaging platforms.

Hermes also has its own safety controls. Keep dangerous command approvals enabled, avoid --yolo and /yolo for normal use, and do not set gateway allow-all options for a bot with terminal access. Hermes' gateway denies unauthorized users by default unless you configure allowlists or approve users through pairing.

What Kyvenza does not support

Kyvenza runs native arm64 guests on Apple Silicon. For a Hermes Agent macOS VM, keep these limits in mind:

  • Windows on ARM is not supported.
  • x86_64 guest operating systems are not supported.
  • Intel Macs are not supported.
  • Nested virtualization is not supported, so do not plan around Docker Desktop inside a macOS VM.
  • GPU passthrough is not supported.
  • Kyvenza uses its bundled Lume backend and ignores a system-installed Lume.
  • The VM is local to your Mac. If the Mac sleeps, shuts down, loses network access, or Kyvenza stops the VM, Hermes inside the guest is affected.

Some Hermes features depend on external accounts, messaging platform tokens, local permissions, or optional tools. Configure those inside the VM if your goal is to keep Hermes separate from the host.

How it compares

Running Hermes directly on your host Mac is the shortest setup path, but it puts Hermes sessions, tools, gateway state, launchd service, logs, and credentials in your main account. That may be fine for a trusted personal setup. It is a poor first move if you are still deciding which tools, skills, messaging platforms, and permissions to allow.

A Kyvenza macOS VM takes longer to prepare, but cleanup is straightforward. You can stop it, keep it as a known-good baseline, clone it with Pro before risky changes, or delete it when the experiment is over.

A Kyvenza Linux ARM VM is usually better for server-like Hermes deployments and Docker-based isolation. A VPS or dedicated machine is better when Hermes must stay online while your Mac is asleep or away from the network. The macOS VM is the local choice when the guest operating system itself needs to be macOS.

Troubleshooting

Kyvenza spends a long time downloading the restore image

The first macOS VM needs a supported IPSW restore image. Keep Kyvenza open and keep the Mac awake until the download and creation step finishes. If it fails, check disk space and then open Diagnostics & Troubleshooting.

hermes is not found after install

Reload the guest shell and confirm ~/.local/bin is on PATH:

bash
source ~/.zshrc
echo "$PATH"
which hermes

If the command still is not found, rerun the installer output steps carefully and check the official installation troubleshooting section.

Hermes says an API key is missing

Run the model setup again:

bash
hermes model
hermes doctor

Make sure you entered the provider credentials inside the guest, not on the host.

The gateway does not start

Check Hermes and the launchd log inside the VM:

bash
hermes doctor
hermes gateway status
tail -n 100 ~/.hermes/logs/gateway.log

If you installed new tools after the service was created, rerun:

bash
hermes gateway install
hermes gateway restart

The wrong user can message the agent

Stop the gateway, review allowlists and pairing approvals, then start it again:

bash
hermes pairing list
hermes gateway stop
hermes gateway start

Do not use GATEWAY_ALLOW_ALL_USERS=true unless the VM is disposable and the Hermes tool surface is intentionally limited.

A shared folder exposes too much

Stop the VM, remove the shared folder from the VM configuration, and start again. Create a smaller exchange folder and share only that path. If Hermes only needs to read those files, mark the share read-only in Kyvenza.

The VM feels too small after Hermes is installed

Shut down the guest and increase CPU, memory, or disk in Kyvenza while the VM is stopped. Hermes data, sessions, skills, browser state, and logs can grow during longer experiments.

Next steps

Built with VitePress.