Run OpenClaw safely on Mac in a Linux ARM VM

Run OpenClaw safely on Mac by giving it a dedicated Linux ARM VM instead of installing the Gateway directly on your host macOS account. Kyvenza creates the arm64 guest, keeps its disk and tools separate from your Mac files, and lets you delete the whole environment when you are done testing.

This guide uses Ubuntu ARM as the example because it is the simplest default for most OpenClaw Linux installs. Debian ARM and Fedora ARM work the same way once the guest operating system is installed.

Why run OpenClaw safely on Mac in Kyvenza

Kyvenza is a good fit when you want an OpenClaw VM that behaves like a small Linux server on the Apple Silicon Mac you already own.

Use this workflow when:

• You want to evaluate OpenClaw without giving it access to your host home directory, SSH keys, browser profile, or work files.
• You prefer a full Linux guest OS over a container that shares Docker Desktop's Linux environment with other projects.
• You want a clean place for OpenClaw config, provider tokens, channel credentials, logs, and workspace files.
• You are testing agent behavior and want the option to stop or delete the entire VM if the setup gets messy.

Do not use this workflow as a substitute for a real always-on server. The OpenClaw Gateway inside the VM runs only while your Mac is awake and the Kyvenza VM is running.

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 Linux guest, Docker images if you use Docker, OpenClaw logs, and any 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 Linux guest:

• Ubuntu ARM, Debian ARM, or Fedora ARM installed from an arm64 installer.
• Internet access from the guest.
• A model provider account and API key, if your OpenClaw setup uses provider API keys.
• Node 24, or Node 22.16 or later, if you use the normal OpenClaw CLI install path.
• Docker Engine and Docker Compose v2, if you use the optional containerized Gateway path.

OpenClaw's own docs currently recommend Node for the Linux Gateway runtime and list Docker as an optional containerized deployment path. Read the official OpenClaw install overview, Linux platform notes, and Docker guide before changing the commands below for production use.

Create the Linux ARM VM in Kyvenza

1. Open Kyvenza.
2. Click + in the toolbar to start the VM assistant.
3. Choose Linux.
4. Select Ubuntu unless you specifically want Debian or Fedora.
5. Name the VM something explicit, such as openclaw-ubuntu.
6. Start with at least 4 vCPUs, 4096 MB of memory, and 64 GB of disk. Use more memory and disk if you plan to build containers, install browser tooling, or keep long OpenClaw session history.
7. Keep the storage path on a disk with enough free space.
8. Skip shared folders for the first install. Add them later only when you are comfortable with what the agent should be allowed to read.
9. Review the configuration and click Create VM.

Kyvenza downloads the latest official ARM64 installer for the selected Linux distribution and mounts it on the first boot. Install Linux normally in the VM console, shut the guest down after installation, then start it again. If Kyvenza does not automatically detect that installation is complete, use the Linux installation completion control in the VM detail view before the next boot.

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

Install OpenClaw directly in the Linux VM

After the Linux guest boots into the installed system, open a terminal inside the VM.

Update the base system first:

sudo apt update
sudo apt upgrade -y
sudo apt install -y curl ca-certificates git

Use OpenClaw's installer script:

curl -fsSL https://openclaw.ai/install.sh | bash

Then run onboarding and install the user service:

openclaw onboard --install-daemon

During onboarding, choose your model provider, enter the required key or OAuth flow, and let OpenClaw configure the Gateway. When it finishes, verify the install:

openclaw --version
openclaw doctor
openclaw gateway status

The Gateway normally listens on port 18789. If you are working inside a graphical Linux guest, open:

http://127.0.0.1:18789/

If your Linux guest is headless, use OpenClaw's recommended SSH tunnel pattern from another machine or from the Mac host if you have SSH access into the guest:

ssh -N -L 18789:127.0.0.1:18789 <user>@<guest-ip>

Then open http://127.0.0.1:18789/ on the machine that created the tunnel. Keep this local-first until you have read OpenClaw's security guide.

Optional: deploy OpenClaw with Docker

Use Docker when you want the OpenClaw Gateway itself to run in containers inside the Linux VM. This adds operational overhead, but it can make the OpenClaw files, Compose state, and container lifecycle easier to reset.

Install Docker in the guest using your distribution's official packages, then confirm Compose v2 is available:

docker --version
docker compose version

Clone the OpenClaw repository:

git clone https://github.com/openclaw/openclaw.git
cd openclaw

Run OpenClaw's Docker setup script from the repository root:

./scripts/docker/setup.sh

To use OpenClaw's prebuilt image instead of building locally:

export OPENCLAW_IMAGE="ghcr.io/openclaw/openclaw:latest"
./scripts/docker/setup.sh

The setup script runs onboarding, writes the Gateway token to .env, and starts the Gateway through Docker Compose. Check the local endpoints:

curl -fsS http://127.0.0.1:18789/healthz
curl -fsS http://127.0.0.1:18789/readyz

For the Control UI, use the dashboard helper from the same repository:

docker compose run --rm openclaw-cli dashboard --no-open

If the browser reports that pairing is required, follow OpenClaw's Docker troubleshooting commands:

docker compose run --rm openclaw-cli devices list
docker compose run --rm openclaw-cli devices approve <requestId>

Harden the OpenClaw VM

A Linux ARM VM gives OpenClaw a separate filesystem from your Mac. It does not make every OpenClaw configuration safe.

Before connecting real accounts or letting the agent handle untrusted messages:

• Keep OpenClaw bound to local access unless you intentionally configure remote access.
• Do not expose 18789 to the public internet without OpenClaw's security hardening guidance.
• Avoid Kyvenza shared folders for sensitive host paths such as ~/.ssh, browser profiles, password-manager exports, or client workspaces.
• Use separate VMs for separate OpenClaw identities, such as personal, research, and work experiments.
• Store only the provider keys and channel credentials that the VM actually needs.
• Run openclaw doctor after changing authentication, channels, sandbox settings, or remote access.

If you enable OpenClaw's own agent sandboxing, remember that it is inside the guest. That is useful defense in depth, but the Kyvenza boundary is still the VM, not a replacement for OpenClaw's tool policy and channel allowlists.

What Kyvenza does not support

Kyvenza runs native arm64 guests on Apple Silicon. It does not emulate Intel systems and it does not turn an OpenClaw VM into a production hosting platform.

Current limits to keep in mind:

• Windows on ARM is not supported.
• x86_64 Linux images are not supported.
• Intel Macs are not supported.
• Nested virtualization is not supported.
• 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, or loses network access, the OpenClaw Gateway in the VM is affected.

How it compares

Running OpenClaw directly on your Mac is faster to start, but it places the Gateway, tools, credentials, logs, and workspaces in your host account. That is convenient for a trusted personal setup and risky for experiments.

Docker on macOS is useful for container workflows, but it still belongs to your host development environment. A Kyvenza Linux ARM VM gives OpenClaw its own guest OS, package state, service manager, and disk. You can still run Docker inside the VM if you want OpenClaw's containerized Gateway or agent sandbox features.

A VPS or dedicated machine is still the right choice when OpenClaw must run 24/7 while your Mac is asleep or off. Kyvenza is the local option: better for evaluation, development, channel testing, and isolated personal deployments on the Mac you already use.

Troubleshooting

The VM does not boot after Linux installation

Shut the VM down and confirm the Linux installer is marked complete in the Kyvenza VM detail view. If the installer ISO is still mounted, the guest may keep returning to the installer.

OpenClaw says openclaw is not found

Check the Node and npm global paths inside the Linux guest:

node --version
npm prefix -g
echo "$PATH"

If the global npm bin directory is missing from PATH, add it to the guest user's shell startup file and open a new terminal.

The Gateway is not running

Use OpenClaw's local checks first:

openclaw doctor
openclaw gateway status

For Docker deployments:

docker compose ps
docker compose logs --tail=100 openclaw-gateway

The Control UI cannot connect

Keep the first test local to the VM. If you need to reach the Gateway from the Mac host, use an SSH tunnel or OpenClaw's documented remote-access flow instead of opening the Gateway broadly on your network.

For Docker pairing issues:

docker compose run --rm openclaw-cli dashboard --no-open
docker compose run --rm openclaw-cli devices list
docker compose run --rm openclaw-cli devices approve <requestId>

Docker build fails with an out-of-memory error

Increase the VM memory in Kyvenza while the VM is stopped, then retry. OpenClaw's Docker docs note that image builds need at least 2 GB of RAM; in practice, an OpenClaw VM is more comfortable with 4 GB or more.

Kyvenza reports a VM or backend error

Open Diagnostics & Troubleshooting and review the bundled Lume status, recent VM lifecycle events, and storage free space. Pro users can export a diagnostics bundle for support.

Next steps

• Download Kyvenza from kyvenza.com.
• Review System requirements before creating larger OpenClaw VMs.
• Read OpenClaw's official security guide before connecting public channels or exposing remote access.
• If you need more than three Kyvenza VMs for separate OpenClaw profiles, compare Free and Pro on Kyvenza pricing.