Deploy OpenClaw (Self-Hosted)

Deploy and Host OpenClaw on Railway

OpenClaw is a personal AI assistant with persistent conversations, tools, browser automation, and integrations with messaging channels. This template deploys the official stable image with Chromium and the native OpenClaw Control UI.

About Hosting OpenClaw

The service uses ghcr.io/openclaw/openclaw:latest-browser, a persistent /data volume, an HTTPS domain, and a /healthz health check. The first start initializes Railway’s web origin, proxy trust, and Chromium settings through the official CLI. Later starts use the saved configuration and the image’s native Docker initializer. No separate setup application is required.

Quick start

1. Deploy the template without adding provider API keys in Railway. Credentials and model selection are configured inside OpenClaw.
2. If you add or change a custom domain after the first deployment, add its full HTTPS origin to gateway.controlUi.allowedOrigins in OpenClaw’s configuration, then restart the service. You can use the original Railway domain to update this setting. Your login, model selection, and data stay on /data.
3. Once Railway reports a successful deployment, open the service’s Console and run the following once for your first browser:

openclaw dashboard --json | node -e 'let s="";process.stdin.on("data",d=>s+=d);process.stdin.on("end",()=>{const u=new URL(JSON.parse(s).browserUrl);u.protocol="https:";u.hostname=process.env.RAILWAY_PUBLIC_DOMAIN;u.port="";const f=new URLSearchParams(u.hash.slice(1));f.set("gatewayUrl","wss://"+u.host);u.hash=f.toString();console.log(u.href)})'

Open the printed HTTPS link within ten minutes. It contains a single-use owner pairing credential; keep it private. This pairs that browser with administrator access without disabling device authentication. After pairing, use the normal service domain for chat, Models, channels, settings, and device approvals. A new browser profile needs its own pairing link or approval from an existing administrator.

Open Models → Connect provider to add your own API key, connect a supported subscription with OAuth, or configure a custom endpoint. Choose the model in OpenClaw; Railway startup does not change that selection. Credentials and configuration stay on the persistent volume across redeployments.

API usage is billed by the provider separately from Railway. Subscription OAuth follows the connected account’s access and limits.

Common Use Cases

• A personal assistant with persistent context and files.
• Research and browser tasks using bundled headless Chromium.
• Connecting supported chat channels and managing them from the native UI.
• Trying supported model providers with your own credentials.

Dependencies for OpenClaw Hosting

• A Railway account with enough memory and storage for the Gateway and optional browser workloads.
• Your own model-provider credentials or supported subscription login.

Deployment Dependencies

• Official OpenClaw source
• Official Docker images
• Control UI and browser pairing
• Model providers

Implementation Details

Configuration, credentials, sessions, browser profiles, and memory live in /data/.openclaw; agent files live in /data/workspace. Configure Railway volume backups before relying on important data. A volume survives a deployment, but deleting it deletes the stored state. Use one replica with this attached volume.

The public listener uses port 8080. On an empty volume, OPENCLAW_INITIAL_CONFIG sets gateway.publicOrigin from Railway’s public domain. Once initialized, OpenClaw owns the configuration. Adding a domain later requires updating gateway.controlUi.allowedOrigins and restarting; changing OPENCLAW_INITIAL_CONFIG does not overwrite an existing configuration.

Gateway token authentication and device pairing remain enabled. OpenClaw listens directly on port 8080, using its native proxy configuration. No custom HTTP server, WebSocket proxy, or image build is added. The short startup command initializes an empty volume once, then invokes the official Docker entrypoint. It does not reset provider credentials, model selection, or saved settings on redeploy.

The default trusted proxy range is 100.64.0.0/10, which covered the Railway ingress peers observed during deployment tests. Railway overwrote supplied X-Forwarded-For, X-Real-IP, and forwarded host/protocol headers in those tests. This range is an observed runtime default, not a published Railway guarantee; revisit it if Railway changes its ingress network. Trusting the ingress does not bypass Gateway token authentication or device pairing.

OpenClaw detects bundled Chromium automatically on Railway. The initial configuration sets browser.noSandbox=true because the tested Railway runtime requires it. RAILWAY_RUN_UID=0 allows OpenClaw to create and maintain state on Railway’s mounted volume. OpenClaw and Chromium run as root inside this container; Chromium’s internal sandbox is disabled. Use this as a trusted personal assistant, and review what access and tools you grant it.

New installations resolve the official stable browser image. Existing services require an image update deployment to receive a newer image; restarting the same deployment does not upgrade it. Back up the volume before upgrading and follow the official update guide. The official Docker initializer runs openclaw doctor --fix --non-interactive before starting the Gateway, including retained-volume migration when needed. Validation used OpenClaw 2026.9.7, including a real OpenAI reply, public UI access, Chromium, and persistent state.

Variables

All template variables include descriptions in Railway. The reference below is alphabetical; Railway controls the order displayed in its editor.

Why Deploy OpenClaw on Railway?

Railway provides the HTTPS endpoint, persistent volume, deployment health checks, logs, and service console in one project. This template keeps the OpenClaw runtime official and lets each deployer manage providers and models in OpenClaw.