Deploy to Railway

One-click template to deploy a fully onchain and secure agent — keyring proxy and OpenClaw gateway, pre-wired and ready to go.

Keyring Proxy + OpenClaw

Full stack: signing proxy and AI agent gateway with the SIWA skill pre-installed. One click deploys both services connected via private networking.

Overview

The template deploys two services: a keyring-proxy for secure key management and an openclaw-gateway AI agent gateway with the SIWA skill pre-installed. Railway builds directly from your Git repository — no Docker Hub needed.

OpenClaw routes chat messages to agents. Agents use the keyring proxy for all signing operations via KEYSTORE_BACKEND=proxy — private keys never enter the agent process.

Architecture

Service	Image	Purpose
keyring-proxy	packages/keyring-proxy/Dockerfile	Holds encrypted keys, HMAC-auth signing API
openclaw-gateway	Docker image	AI agent gateway with SIWA skill installed

Agent / OpenClaw
  |
  +---> keyring-proxy
  |     KEYSTORE_BACKEND=encrypted-file
  |     Signing service
  |     (private networking)
  |
  +---> openclaw-gateway
        KEYSTORE_BACKEND=proxy
        Delegates signing to keyring-proxy

Railway auto-provisions private DNS between services in the same project. The openclaw-gateway reaches the keyring-proxy at its internal URL — no public exposure needed.

Prerequisites

Before you begin, make sure you have:

A Railway account
The SIWA repo forked or cloned to your GitHub account
A password for the encrypted-file keystore
A shared HMAC secret for proxy authentication

Generate a random HMAC secret:

openssl rand -hex 32

Create Railway Project

The fastest way to create your project is with the deploy button — it sets up the keyring-proxy service with the correct Dockerfile and configuration automatically:

If you prefer to set things up manually, follow the steps below.

Configure keyring-proxy (manual)

1. Add a new service from your SIWA repo. Railway will detect the railway.json and use packages/keyring-proxy/Dockerfile.

2. Name the service keyring-proxy.

3. No start command override needed — the Dockerfile's default CMD runs pnpm run start.

4. If the openclaw-gateway (or your agent) runs in the same Railway project, keep this service private — it's reachable via internal networking. If your agent or OpenClaw instance runs outside Railway, assign a public domain so it can reach the proxy over the internet.

Configure openclaw-gateway

OpenClaw is an open-source AI agent gateway. Follow the OpenClaw Railway installation guide to deploy it. Once running, connect it to the keyring-proxy by setting these environment variables on the OpenClaw service:

KEYRING_PROXY_URL=https://your-keyring-proxy.up.railway.app
KEYRING_PROXY_SECRET=<same secret as keyring-proxy>

Environment Variables

keyring-proxy

Variable	Required	Description
KEYRING_PROXY_SECRET	Yes	Shared HMAC secret. Must match openclaw-gateway (if deployed).
KEYSTORE_BACKEND	No	Defaults to encrypted-file. Set to 'env' to use AGENT_PRIVATE_KEY.
KEYSTORE_PASSWORD	Conditional	Required when KEYSTORE_BACKEND=encrypted-file.
AGENT_PRIVATE_KEY	Conditional	Required when KEYSTORE_BACKEND=env. Hex-encoded private key (0x...).

openclaw-gateway

Variable	Required	Description
KEYRING_PROXY_URL	Yes	Public URL of the keyring proxy (e.g. https://your-keyring-proxy.up.railway.app).
KEYRING_PROXY_SECRET	Yes	Shared HMAC secret. Must match keyring-proxy.

Use Railway's shared variables to keep KEYRING_PROXY_SECRET in sync between both services.

Use an Existing Wallet

By default the keyring proxy generates and manages its own encrypted keystore. If you already have a wallet you want to use, you can pass the private key directly via environment variable instead.

Set these two variables on your keyring-proxy service:

KEYSTORE_BACKEND=env
AGENT_PRIVATE_KEY=0x<your-private-key>

When AGENT_PRIVATE_KEY is set, the proxy automatically uses the env backend — you can omit KEYSTORE_BACKEND entirely. No KEYSTORE_PASSWORD is needed in this mode.

This is useful when you want to plug in an existing wallet (e.g. one that already holds funds or is registered onchain) without going through the encrypted-file keystore flow.

Security note: the private key is held in memory at runtime. Make sure Railway's variable storage meets your security requirements. For higher security, prefer encrypted-file with a strong KEYSTORE_PASSWORD.

Verify Deployment

Health Checks

The keyring-proxy exposes a /health endpoint. Railway uses this for automatic health checks (configured in railway.json).

curl https://your-keyring-proxy.up.railway.app/health

# Expected: { "status": "ok", ... }

Test with curl

If you gave the keyring-proxy a public domain for debugging, you can test signing:

# Check health
curl https://your-keyring-proxy.up.railway.app/health

# Check address (requires valid HMAC headers)
# In production, only the openclaw-gateway or your agent
# should call the proxy — never expose it publicly.

In production, remove any public domain from the keyring-proxy. It should only be reachable via Railway's internal network.

Connect Your Agent

Point your agent at the deployed keyring-proxy by setting these environment variables:

KEYRING_PROXY_URL=https://your-keyring-proxy.up.railway.app
KEYRING_PROXY_SECRET=<your-shared-secret>

Use the public domain Railway assigns to your keyring-proxy service. The HMAC secret ensures only authorized clients can request signatures.

For the full authentication flow, see the Sign In documentation.

Documentation

SDK reference, protocol spec, security model, and contract addresses.

API Endpoints

Live HTTP endpoints you can call right now to try the full SIWA auth flow.