OpenClaw on Opalstack: a real AI gateway, no root required

John Spounias

John Spounias

— 3 min read
OpenClaw on Opalstack: a real AI gateway, no root required

OpenClaw is an open-source “personal AI assistant” built around a Gateway. The Gateway is the whole point: it’s the always-on brain/entrypoint, and everything else is optional.

Most “run an AI assistant on a server” guides still assume one of these:

  • root access
  • Docker spaghetti
  • “just systemctl it bro”
  • a pile of mysterious config you’re supposed to guess

That’s not how Opalstack works.

On Opalstack, OpenClaw runs as a userspace app inside your account. No root. No systemd. No drama.

TL;DR

  1. Create an OpenClaw app on Opalstack (Open App Stack).
  2. The installer drops a self-contained gateway under your home dir.
  3. Start it with ~/apps/<appname>/start.
  4. Open the dashboard with a token (kept in state/.env).
  5. Keep it running with a cron watchdog (every ~10 minutes).

The pitch

You don’t want “a demo”. You want something you can actually run:

  • isolated per app
  • restartable
  • loggable
  • upgradeable
  • and readable (it’s a script, not a black box)

That’s exactly what an Open App Stack is: an installer you can read and modify.

What you get from the OpenClaw Open App Stack

When you install OpenClaw on Opalstack, you’re not just getting npm install -g openclaw.

You get a working, production-ish baseline that looks like this:

  • Userspace install (no global Node installs needed)
  • Per-app state + config isolation
  • Token auth on the Control UI (no “oops it’s public”)
  • Start/stop/status scripts
  • Cron watchdog to keep it alive (and come back after reboots)
  • Logs where you’d expect them

In other words: “run a gateway” instead of “become a part-time platform engineer.”

Where it lives on disk (so you can debug like an adult)

Your OpenClaw app folder will look like:

  • App root: ~/apps/<appname>/
  • OpenClaw project dir: ~/apps/<appname>/oc/
  • Wrapper CLI: ~/apps/<appname>/oc/bin/openclaw
  • Config: ~/apps/<appname>/oc/openclaw.json
  • State: ~/apps/<appname>/oc/state/
  • Token env: ~/apps/<appname>/oc/state/.env
  • Logs:
    • Console: ~/apps/<appname>/oc/logs/openclaw.console.log
    • JSONL: ~/apps/<appname>/oc/logs/openclaw.jsonl

Control it (start / stop / status / upgrade)

From SSH:

# start the gateway
~/apps/<appname>/start

# stop it
~/apps/<appname>/stop

# status (+ a quick OpenClaw status check)
~/apps/<appname>/status

# upgrade OpenClaw in-place (keeps state/config)
~/apps/<appname>/upgrade

# tail the live console log
tail -f ~/apps/<appname>/oc/logs/openclaw.console.log

Open the dashboard (without “token_missing”)

This gateway uses token auth. The token is stored here:

cat ~/apps/<appname>/oc/state/.env

Option A: SSH tunnel (simple + safest)

# on your laptop
ssh -L 19001:127.0.0.1:19001 youruser@your-opalstack-server

Then open:

  • http://127.0.0.1:19001/?token=PASTE_TOKEN_HERE

Option B: put it behind an Opalstack site proxy

If you map the gateway port to a site/domain, you’ll still need the token on first load:

  • https://yourdomain.tld/?token=PASTE_TOKEN_HERE

Why this runs clean on Opalstack

A couple implementation details worth knowing:

  • The installer binds the gateway to loopback and trusts 127.0.0.1 as a proxy hop.
  • OpenClaw is installed into a per-app npm prefix, not system-wide.
  • A cron watchdog runs the start script every ~10 minutes, so if the gateway dies, it comes back.

That’s the “no systemctl” trick: it’s boring, and it works.

Provider keys / onboarding (the part people forget)

OpenClaw can run with no provider keys configured, but agents won’t answer until you set them up.

Once the gateway is running, you’ll typically do one of these:

# interactive onboarding
~/apps/<appname>/oc/bin/openclaw onboard

# or add an agent explicitly
~/apps/<appname>/oc/bin/openclaw agents add main

If you want the installer script (it’s open)

Here’s the exact Open App Stack installer we run on AlmaLinux 9:

https://raw.githubusercontent.com/opalstack/installers/refs/heads/master/el9/openclaw/install.py

Fork it. Tweak it. Ship your own flavor. That’s the point.

Security notes (straight talk)

  • The Control UI is an admin surface. Don’t expose it publicly without auth.
  • Treat state/.env like a secret. Don’t commit it. Don’t paste it into screenshots.
  • If you publish the dashboard on a public domain, you are responsible for access control.

Next up

If you want to go further:

  • run multiple OpenClaw gateways (one per app) with isolated state
  • wire OpenClaw into real workflows (channels, skills, automations)
  • treat it like a service: logs, restarts, upgrades, and sane defaults
  • chain together apps like n8n via webhook

That’s what “managed hosting” should feel like.

Read more