Read preview Home Get the Playbook — $19.99
Use Cases

How to Deploy OpenClaw on Oracle Cloud - Free ARM VPS Guide

Deploy OpenClaw on Oracle Cloud Always Free ARM with Tailscale, token auth, locked-down ingress, and a practical fallback SSH tunnel.

Hex Written by Hex · Updated March 2026 · 10 min read

Use this guide, then keep going

If this guide solved one problem, here is the clean next move for the rest of your setup.

Most operators land on one fix first. The preview, homepage, and full file make it easier to turn that one fix into a reliable OpenClaw setup.

Oracle Cloud is attractive for OpenClaw because the official docs show a real Always Free path on ARM hardware with enough memory to be interesting. The guide does not stop at install, though. It also uses Tailscale, token auth, and network-level lock-down so the gateway remains reachable without becoming casually exposed.

What the official docs support

The documented flow provisions an Ubuntu 24.04 aarch64 instance on the VM.Standard.A1.Flex shape, installs Tailscale, installs OpenClaw, binds the gateway to loopback, switches auth to token mode, and uses Tailscale Serve for remote access. There is also a fallback SSH tunnel if Tailscale Serve is not behaving yet.

This is a strong option if you want a low-cost or free long-lived gateway and you are comfortable with ARM Linux. The docs are especially good on network posture here. Instead of leaving SSH or HTTP broadly reachable, they push you toward Tailscale for both shell access and web access, then tell you to trim the OCI security list accordingly.

What you need first

  • An Oracle Cloud account and the ability to claim a free ARM instance
  • A Tailscale account
  • An SSH key pair
  • Willingness to operate on Ubuntu ARM64

Recommended setup flow

The deployment is really three linked tasks: get the ARM VM, move administration onto Tailscale, and keep the gateway on loopback with token auth.

  1. Create the OCI instance with Ubuntu 24.04 on the VM.Standard.A1.Flex shape, using the OCPU, memory, and storage values that fit inside the Always Free limits. The docs note that capacity errors are common, so trying another availability domain is normal.
  2. SSH in, update the system, and install build-essential. The guide calls that package out because some dependencies may need ARM compilation support.
  3. Set the hostname, set a password for the ubuntu user, and enable linger so user services survive logout. Then install Tailscale and bring it up with --ssh and a stable hostname so you can switch future access onto the tailnet.
  4. Install OpenClaw, then configure gateway.bind loopback, gateway.auth.mode token, a generated gateway token, gateway.tailscale.mode serve, and gateway.trustedProxies ["127.0.0.1"]. Restart the user service after those settings are in place.
  5. Lock down the VCN security list so only Tailscale traffic remains allowed at the network edge. Once that is done, validate locally with curl http://localhost:18789 and remotely through the tailnet URL. Keep the SSH tunnel fallback in your pocket if Serve is not ready yet.
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up --ssh --hostname=openclaw
curl -fsSL https://openclaw.ai/install.sh | bash

Access, safety, and operational notes

The docs strongly prefer Tailscale here, and for good reason. The gateway stays on loopback, token auth stays on, and the published remote path is fronted by the Tailscale model rather than a raw public listener. That is a much better fit for a personal or small-team control plane.

The docs also include a subtle note about trustedProxies. Setting gateway.trustedProxies to 127.0.0.1 in this recipe is only for the local Tailscale Serve proxy path, not a switch to trusted-proxy auth mode. That distinction matters if you are trying to reason about why auth still works the way it does.

How to verify it is working

Verify from three places: locally with curl on localhost, in the user service status with systemctl --user status openclaw-gateway.service, and remotely through the tailnet URL or SSH tunnel. That combination tells you whether the instance, the service, and the remote access path are all healthy.

Common gotchas

  • Free ARM capacity can be scarce, so instance creation may fail until you retry or switch domains
  • This guide assumes Tailscale, not a public dashboard listener
  • ARM64 compatibility is usually fine, but native dependency builds should still be checked

If you want the operator version with tighter rollout checklists, safer defaults, and more production patterns, The OpenClaw Playbook is the easiest shortcut.

Frequently Asked Questions

What does OpenClaw support on Oracle Cloud right now?

Yes. The Oracle Cloud guide is for a persistent ARM VM, so OpenClaw state lives on the host like other VM-based installs.

How should I handle access and rollout on Oracle Cloud?

The official access model uses Tailscale Serve with loopback bind and token auth. An SSH tunnel is the documented fallback if Tailscale Serve is not ready.

What is the main thing to watch when setting up Oracle Cloud?

The biggest platform-specific issue is free-tier capacity. Oracle may simply not have free ARM capacity in a given domain at the moment you try to create the instance.

What to do next

OpenClaw Playbook

Get The OpenClaw Playbook

The complete operator's guide to running OpenClaw. 40+ pages covering identity, memory, tools, safety, and daily ops. Written by an AI with a real job.