OpenClaw Deployment Guides: Railway.app and Fly.io

Part 1: Deploy OpenClaw on Railway.app

Railway is a cloud platform that makes deploying applications as simple as pushing to a Git repository. It handles infrastructure, SSL certificates, and scaling automatically, making it one of the fastest ways to get OpenClaw running in production. This guide walks you through the entire process from account creation to a live deployment.

Prerequisites

Before you begin, make sure you have the following:

• A Railway account -- sign up at railway.app. The free Trial plan includes $5 of usage credit per month, which is enough to test your deployment. No credit card is required for the Trial plan.
• A GitHub account with your OpenClaw project pushed to a repository. Railway integrates directly with GitHub for automatic deployments.
• Your API keys ready: ANTHROPIC_API_KEY and/or OPENAI_API_KEY, depending on which model provider your OpenClaw agent uses.
• Node.js 20 or later installed locally if you plan to use the Railway CLI for manual deploys.

Optionally, install the Railway CLI for command-line deploys:

# macOS (Homebrew)
brew install railway

# Or via npm
npm install -g @railway/cli

# Authenticate
railway login

Step 1: Create a New Project

1. Log in to the Railway dashboard.
2. Click New Project in the top-right corner.
3. Select Deploy from GitHub repo.
4. If this is your first time, Railway will prompt you to authorize the Railway GitHub App. Grant access to the repository containing your OpenClaw project.
5. Select your OpenClaw repository from the list.
6. Railway will automatically detect the project type and begin an initial deployment.

Alternatively, if you prefer starting from the CLI:

# Navigate to your OpenClaw project directory
cd /path/to/your/openclaw-project

# Link to a new Railway project
railway init

# Deploy directly from the command line
railway up

Step 2: Configure the Service

After creating the project, configure the service settings:

1. In the Railway dashboard, click on your service (the card showing your repository name).
2. Go to the Settings tab.
3. Under Deploy, set the Start Command:

openclaw start

4. Under Build, Railway uses Nixpacks by default to auto-detect your Node.js project. It reads your package.json to determine the build command. If your project has a build step, ensure your package.json includes:

{
  "scripts": {
    "build": "npm run compile",
    "start": "openclaw start"
  },
  "engines": {
    "node": ">=20.0.0"
  }
}

5. Navigate to the Variables tab to set environment variables. Click New Variable for each:

Railway encrypts all environment variables at rest and injects them at runtime. They are never exposed in build logs.

Step 3: Add a Dockerfile (Optional)

Railway auto-detects Node.js projects using Nixpacks, so a Dockerfile is not strictly required. However, if you want precise control over the build environment, create a Dockerfile in your project root:

FROM node:20-slim

# Install OpenClaw globally
RUN npm install -g openclaw@latest

# Create app directory
WORKDIR /app

# Copy project files
COPY package*.json ./
RUN npm ci --production

COPY . .

# OpenClaw default port
EXPOSE 3000

# Health check
HEALTHCHECK --interval=30s --timeout=10s --retries=3 \
  CMD curl -f http://localhost:3000/health || exit 1

CMD ["openclaw", "start"]

When Railway detects a Dockerfile in the root of your repo, it automatically uses Docker for the build instead of Nixpacks. No additional configuration is needed.

Step 4: Deploy

Railway supports two deployment methods:

Automatic Deploys (recommended): Every push to your default branch (usually main) triggers an automatic deployment. Railway builds the new version, runs health checks, and switches traffic with zero downtime.

# Simply push your code -- Railway handles the rest
git add .
git commit -m "Configure OpenClaw agent"
git push origin main

Manual Deploys via CLI:

# Deploy the current directory
railway up

# Watch deployment logs
railway logs

After deploying, Railway provides a public URL in the format https://your-project-name.up.railway.app. You can find this URL in the Settings > Networking section of your service.

Step 5: Custom Domain and SSL

Railway automatically provisions SSL certificates for all deployments, including the default .up.railway.app domain.

To add a custom domain:

1. Go to your service Settings > Networking > Custom Domain.
2. Click Add Custom Domain and enter your domain (e.g., agent.yourdomain.com).
3. Railway will display a CNAME record. Add this to your DNS provider:

CNAME  agent.yourdomain.com  your-project-name.up.railway.app

4. SSL is provisioned automatically via Let's Encrypt once DNS propagation completes (typically 5-30 minutes).

Persistent Storage

If your OpenClaw agent needs to persist configuration files, logs, or local data between deployments, attach a Railway Volume:

1. In the dashboard, click New inside your project and select Volume.
2. Set the mount path to /app/data (or wherever your agent stores persistent files).
3. Choose a size (1 GB is sufficient for most configurations).

In your OpenClaw configuration, point any persistent paths to the volume mount:

# Example: set the data directory
OPENCLAW_DATA_DIR=/app/data

Volumes persist across deployments and redeploys. They are backed up automatically by Railway.

Cost Breakdown

Typical OpenClaw usage on the Hobby plan runs $5-15/month, depending on how frequently your agent processes requests. The base $5/month includes a generous resource allowance. Compute is billed at $0.000463/min per vCPU and $0.000231/min per GB of RAM.

Pros and Cons

Advantages:

• Fastest path from code to production -- deploy in under 10 minutes
• Automatic SSL, GitHub integration, and zero-downtime deploys out of the box
• Environment variables are encrypted and managed through a clean UI
• Built-in logging, metrics, and deployment history
• Nixpacks auto-detection means no Dockerfile needed for standard Node.js projects

Limitations:

• Less control over the underlying infrastructure compared to VPS-based approaches
• Volume storage is limited and region-locked (no multi-region replication)
• The Trial plan is restrictive for anything beyond testing
• No SSH access to the container for debugging
• Egress bandwidth is metered and can add up for high-traffic agents