OpenClaw on Daytona

Daytona gives you an isolated Linux sandbox with SSH access and built-in preview URLs, and OpenClaw comes pre-installed in its medium snapshot, so the docs’ recipe starts the moment you are in. The rule that shapes the whole page: keep the Gateway on loopback and reach the dashboard through Daytona’s signed preview URLs, never by exposing the Gateway port. Here is the create-and-onboard sequence, the origin step that most people get wrong, the start and restart commands, the security layers, channel setup, updating, and the lifecycle gotcha.

Create and onboard

• You need a Daytona account, a Daytona API key and a model provider key; install the CLI with Homebrew or the Windows installer, keep it current since older versions miss newer sandbox commands, and log in with the API key.
• Create the sandbox with the medium snapshot, which provides enough memory headroom for the Gateway, and auto-stop set to zero so it keeps running until you stop it; then SSH in.
• Run onboarding non-interactively with the accept-risk flag, your provider key flag, and skips for daemon, channels, skills, hooks and health; the daemon skip matters because Daytona sandboxes run no service manager, so you start the Gateway by hand.
• Onboarding configures a Gateway auth token that you print with the auth-token show command in an interactive terminal; the command refuses to print when stdout is not a terminal, so it cannot be captured through a pipe, and the config getter returns a redacted placeholder instead of the value.

Keep the Gateway on loopback and reach the dashboard through Daytona’s signed preview URLs. Do not expose the Gateway port directly to the public internet.

The origin step

The Gateway accepts browser connections only from allowed origins, and Daytona’s preview proxy sits in front of it, so both must be configured before the first start. From your local terminal, not the sandbox, generate a signed preview URL for the Gateway port; back in the sandbox, allow that origin in the Control UI allowed-origins setting and trust the in-sandbox proxy by listing loopback as a trusted proxy. Paste the URL exactly as printed, scheme and host only, no trailing slash and no path: the Gateway compares the browser origin literally, browsers send the origin without a trailing slash, and address bars often display one, so copy from the terminal. Then start the Gateway in the background with nohup so it survives SSH disconnects, confirm with the health command, and restart later by killing the process and running the same nohup line. The first browser connection queues a device pairing request that you list and approve from the sandbox shell.

Security, channels, updates

• Three layers protect access: the time-limited signed preview URL, which expires after an hour by default and can be regenerated with a longer expiry, the Gateway token required by the Control UI, and device approval for every new browser or client. Each regenerated preview URL has a different host, so it is a new origin that must be added to the allowed list before the Control UI stops rejecting it.
• Telegram: create the bot with BotFather, export the token and add the channel with the use-env flag, which validates the token without copying it into the config, store it in the state directory’s env file so the background Gateway gets it after a restart, restart, message the bot and approve the pairing code, which expires after an hour. WhatsApp ships as a separate plugin, so install and enable it, since installing does not enable, then link by scanning the QR code from the sandbox session; the linked account’s own number is allowed without pairing.
• The snapshot’s global npm tree is owned by root, so a plain update cannot write to it; update with sudo while preserving the path, then run doctor to migrate older config, and restart. Sandbox state persists across stop and start, but the Gateway process does not auto-start after a resume, so reconnect and run the nohup line again.

OpenClaw remote access is the general treatment of reaching a Gateway from outside, and The OpenClaw Gateway explained the process you are keeping on loopback.

When to pick it

Daytona fits a personal Gateway you are happy to start by hand and reach through a URL that rotates; the docs also point to an SDK guide for programmatic sandbox provisioning. OpenClaw doctor is the command that closes every update, and Diali versus your own server weighs this class of self-run hosting against a managed one.

On Diali

Diali is the same idea with the sandbox lifecycle removed: the Gateway stays private, the dashboard is reached through Diali’s own sign-in rather than a rotating preview URL, and nothing stops when the box idles. Hosted OpenClaw on Diali is the assistant and Diali pricing what it costs.

• Medium snapshot, auto-stop off, no daemon.
• Exact origin, no trailing slash, loopback trusted.
• The Gateway does not survive a sandbox restart.