OpenClaw on Synology NAS

Looking for Synology Chat? If you want to talk to your bot through the Synology Chat app, see the OpenClaw Synology Chat guide. This page is about hosting OpenClaw on the NAS itself.

Can you run OpenClaw on a Synology NAS?

Yes. OpenClaw publishes an official container image at ghcr.io/openclaw/openclaw, with a Docker Hub mirror at openclaw/openclaw, for linux/amd64 and linux/arm64. Synology's Container Manager (called “Docker” before DSM 7.2) lives in Package Center, and its Project feature builds a stack from a docker-compose.yml. OpenClaw does not run a model on the NAS: it calls a hosted model provider, so no GPU and no fast CPU are needed. What you need is a 64-bit model that can install Container Manager, an API key for a model provider, and some free RAM.

Which Synology models and how much RAM?

• Architecture. amd64 and arm64 only. Check your model's CPU in its spec sheet on synology.com. A 32-bit ARM model cannot pull the image, and if Container Manager is not offered for your model, this guide does not apply.
• RAM. Upstream's Docker guide gives a 6 GB figure only for building the image from source, which you will not do because you pull a prebuilt one. For running it, our measurements from production containers say 1 GB is enough for a chat-only agent and 2 GB is the comfortable number; see OpenClaw system requirements. Remember DSM and your other packages share the same memory.
• Disk. Any local volume works. State, workspace and sessions live in the folders you mount, so size them for your chat history and files.

Step by step: OpenClaw in Container Manager

1. Create the data folders and fix ownership

The gateway runs as the non-root node user, UID 1000inside the container. A folder created by your DSM account is owned by a different ID, and OpenClaw then fails with permission errors when it tries to create files. Enable SSH in Control Panel, log in, and create three folders (one for config and state, one for the agent workspace, one for the local auth-profile key) owned by 1000:

sudo mkdir -p /volume1/docker/openclaw/{config,workspace,secrets}
sudo chown -R 1000:1000 /volume1/docker/openclaw

Upstream's compose file mounts all three: the state directory at /home/node/.openclaw, the workspace inside it, and a separate folder at /home/node/.config/openclaw that holds a key needed to recover legacy encrypted credentials. Mount each as a directory, never as a single file: upstream warns that a single-file bind can diverge from what the container sees when OpenClaw saves its config.

2. Run first-time onboarding

Upstream's setup script runs the onboarding wizard in a throwaway container before the gateway starts, and you can do the same by hand. The wizard prompts for your model provider and its API key and sets gateway token authentication, using the token from the environment variable rather than printing it:

# generate a long random gateway token and keep it somewhere safe
openssl rand -hex 32

# run the wizard once (replace PASTE_TOKEN with the value above)
sudo docker run -it --rm \
  -e HOME=/home/node \
  -e OPENCLAW_GATEWAY_TOKEN=PASTE_TOKEN \
  -v /volume1/docker/openclaw/config:/home/node/.openclaw \
  -v /volume1/docker/openclaw/workspace:/home/node/.openclaw/workspace \
  -v /volume1/docker/openclaw/secrets:/home/node/.config/openclaw \
  --entrypoint node \
  ghcr.io/openclaw/openclaw:2026.9.8 \
  dist/index.js onboard \
    --mode local --no-install-daemon \
    --gateway-auth token \
    --gateway-token-ref-env OPENCLAW_GATEWAY_TOKEN \
    --skip-ui --suppress-gateway-token-output

Then apply the Docker gateway defaults that upstream's script applies after onboarding. It binds the gateway to all interfaces inside the container and allows the control UI origins you will use through the tunnel:

sudo docker run --rm \
  -e HOME=/home/node \
  -v /volume1/docker/openclaw/config:/home/node/.openclaw \
  -v /volume1/docker/openclaw/workspace:/home/node/.openclaw/workspace \
  -v /volume1/docker/openclaw/secrets:/home/node/.config/openclaw \
  --entrypoint node \
  ghcr.io/openclaw/openclaw:2026.9.8 \
  dist/index.js config set --batch-json \
  '[{"path":"gateway.mode","value":"local"},{"path":"gateway.bind","value":"lan"},{"path":"gateway.controlUi.allowedOrigins","value":["http://localhost:18789","http://127.0.0.1:18789"]}]'

Binding to lan is safe here only because the compose file below publishes the port on the NAS's loopback and the gateway demands the token.

3. Create the Project

In Container Manager open Project and click Create. Name it, point the path at a working folder such as /volume1/docker/openclaw-project, and choose to create the compose file in the editor. Paste this, using the same token as above:

services:
  openclaw:
    image: ghcr.io/openclaw/openclaw:2026.9.8
    container_name: openclaw
    restart: unless-stopped
    init: true
    environment:
      - HOME=/home/node
      - OPENCLAW_GATEWAY_TOKEN=paste-the-same-token-here
    volumes:
      - /volume1/docker/openclaw/config:/home/node/.openclaw
      - /volume1/docker/openclaw/workspace:/home/node/.openclaw/workspace
      - /volume1/docker/openclaw/secrets:/home/node/.config/openclaw
    ports:
      - "127.0.0.1:18789:18789"
    cap_drop:
      - NET_RAW
      - NET_ADMIN
    security_opt:
      - no-new-privileges:true
    command: ["node", "dist/index.js", "gateway", "--bind", "lan", "--port", "18789"]

• image is pinned to 2026.9.8, the latest release tag when this guide was written. Never use latest on a NAS you leave unattended; an update should happen when you choose it.
• ports binds 18789 to 127.0.0.1 on the NAS. Nothing else on your network can open it. Upstream's own compose file also publishes ports 18790 and 3978; this setup needs neither, so leave them out.
• init: true, cap_drop and no-new-privileges follow upstream's compose file.
• command is upstream's gateway command. The image also ships a built-in health check, and you can probe it by hand from the NAS with curl -fsS http://127.0.0.1:18789/healthz.

Finish the Create wizard and Container Manager pulls the image and starts the container. Watch the Project's log tab until the gateway reports it is up.

4. Open the control UI and approve your browser

The port is loopback-only, so tunnel to it from your computer. Replace the user and host with yours:

ssh -L 18789:localhost:18789 you@your-nas

Leave that running, open http://localhost:18789/ in your browser, and paste your token into the Gateway secret field (also under Settings → Gateway). Keep the local port at 18789: those are the origins allowed in step 2. If you want another local port, add that origin to gateway.controlUi.allowedOrigins first.

A new browser then needs device pairing. From an SSH session on the NAS list and approve the pending request inside the running container:

sudo docker exec openclaw node dist/index.js devices list
sudo docker exec openclaw node dist/index.js devices approve <requestId>

Upstream documents these as docker compose run --rm openclaw-cli devices list and devices approve, using a second CLI service; running the same command with docker exec avoids adding that service to your Project. After approval the browser keeps its own device token for later visits.

5. Connect a chat channel

Chat channels connect outward from the gateway, so they need no inbound port and no router change. For Telegram, create a bot with BotFather, then add it:

sudo docker exec openclaw node dist/index.js channels add --channel telegram --token "<token>"

Telegram's default DM policy is pairing: message your bot, then run pairing list and pairing approve the same way as above to approve yourself. Our OpenClaw Telegram guide covers the details. Discord uses the same channels add command with --channel discord.

Choosing an image variant

• Plain tag (for example 2026.9.8). The default image and the right choice for most NAS setups.
• -slim. Upstream's minimal-footprint variant. Pick it if disk or memory is tight and you do not need the extras in the default image.
• -browser. Includes Chromium for the control UI's browser panel. It is bigger, and a browser needs more memory, so choose it only if you want that panel and have RAM to spare. With this variant, upstream also keeps the browser cache at /home/node/.cache/ms-playwright.
• Per-arch tags. The Docker Hub mirror also lists -amd64 and -arm64 tags. The plain tag is multi-platform and picks the right one for your NAS, so you rarely need these.

Keeping it running, updated and backed up

• Always on. restart: unless-stopped brings the gateway back after a DSM reboot, unless you stopped the Project by hand.
• Updating. Back up first. Check the published image tags, change the tag in your compose file, then rebuild the Project or run docker compose pull and docker compose up -d in the project folder. On start the entrypoint runs openclaw doctor --fix --non-interactive, and database upgrades leave timestamped .bak files beside the database for rollback. Update the tag in the onboarding commands too if you reuse them.
• Backups. Upstream says to keep all three folders in backups: config, workspace and the secrets folder. Add /volume1/docker/openclaw to Hyper Backup or your usual job. Treat the backup as sensitive: upstream notes current OAuth token material is stored as plaintext in SQLite under the config directory, so the folder and its copies are credentials. Encrypt the backup destination.

Reaching it remotely without exposing it

Do not forward port 18789 on your router, and do not publish the control UI through a public DSM reverse proxy. The control UI is the admin surface for your agent and its credentials. Safer options:

• Chat channels need no inbound port. For daily use, talk to the bot in Telegram or Discord and never open the UI remotely.
• Tailscale or a VPN to reach the NAS privately, then the SSH tunnel above over that network. Upstream's control UI docs recommend Tailscale for remote access. See OpenClaw with Tailscale.
• An SSH tunnel, as in step 4, which is the non-Tailscale option upstream documents. Browsing through localhost also keeps you in a secure context, which some control UI features require.

The token is your only gateway credential, so make it long and random (openssl rand -hex 32) and never reuse a password.

Common problems on Synology

• Permission denied or EACCES on the state folder. The folders are not owned by UID 1000. Re-run the chown from step 1 and restart the container.
• “no matching manifest” or exec format error. Your CPU is not amd64 or arm64. The image is not published for it.
• Unreachable control UI. The gateway's image default binds to loopback inside the container, which Docker's port mapping cannot reach. The compose command passes --bind lan for that reason; keep it, and keep the token.
• Token mismatch. The secret you pasted differs from OPENCLAW_GATEWAY_TOKEN in the running container. The onboarding command and the compose file must hold the same value. Edit the Project and recreate it after changing it.
• Pairing required. A new browser must be approved with devices approve (step 4); a new Telegram user must be approved with pairing approve (step 5).
• Origin errors in the UI. You opened it from an address that is not in gateway.controlUi.allowedOrigins. Use the tunnel on port 18789 as described.
• Slow or killed on a small-RAM model. Skip the -browser variant and close other packages. A compose memory limit only caps the container; it does not add memory.
• Synology Chat confusion. Installing OpenClaw on the NAS does not set up the Synology Chat channel, and the Chat channel does not host anything. They are separate; see the Synology Chat guide.

Running Hermes Agent on Synology instead

Prefer Hermes Agent? It runs in Container Manager too, but it uses a different image (nousresearch/hermes-agent), a different data path and its own user mapping, so none of the commands above apply. Our Hermes Agent on Synology guide has the matching walkthrough. For the Compose basics behind both, see the OpenClaw Docker guide and the OpenClaw Docker Compose guide.

NAS vs managed hosting

A NAS you already own costs nothing extra and keeps your files at home. The trade is that you are the sysadmin: updates, backups, remote access, power cuts and the odd broken pull are yours.

The managed alternative

OpenClaw Launch hosts OpenClaw and Hermes Agent for you, so there is no Container Manager, no UID 1000 and no tunnel to maintain. Start with the free 30-minute trial, no credit card required.

• Lite: $3 for the first month, then $6/month (or $60/year). 1 vCPU, 2 GB RAM, 10 GB storage, 1 instance, $1/month AI credits included.
• Pro: $20/month (or $200/year). 2 vCPU, 4 GB RAM, 40 GB storage, up to 3 instances, $10/month AI credits.

Plenty of people do both: the NAS for tinkering, a managed instance for the bot that has to stay up. See the hosting page for how it works, or best OpenClaw hosting to compare providers.

Frequently Asked Questions

Related Guides

• OpenClaw Docker — the general Docker guide
• OpenClaw Docker Compose — compose setup beyond the NAS
• OpenClaw System Requirements — measured RAM, CPU and disk
• OpenClaw with Tailscale — private remote access
• OpenClaw Synology Chat — use Synology Chat as a channel
• Hermes Agent on Synology — the Hermes version of this guide
• Best OpenClaw Hosting — all options compared