Deploy to Railway

Keyring proxy from a Dockerfile, optional OpenClaw gateway alongside it.

Keyring Proxy Only

Deploy the signing proxy. Connect your own agent or OpenClaw instance externally.

Keyring Proxy + OpenClaw

Full stack: signing proxy and AI agent gateway with the SIWA skill pre-installed.

Coming soon

Overview

The core deployment is a single keyring-proxy service built from packages/keyring-proxy/Dockerfile. Railway builds directly from your Git repository — no Docker Hub needed.

Optionally, you can add an openclaw-gateway service in the same Railway project. OpenClaw is an AI agent gateway that routes chat messages to agents — agents use the keyring proxy for all signing operations via KEYSTORE_BACKEND=proxy.

Architecture

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

Agent / OpenClaw
  |
  +---> keyring-proxy (port 3100)
  |     KEYSTORE_BACKEND=encrypted-file
  |     Signs messages, never exposes keys
  |     (private networking)
  |
  +---> openclaw-gateway (port 18789)   [optional]
        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 keyring-proxy.railway.internal:3100.

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

Create a new project in Railway. At minimum you need one service (keyring-proxy). Add the openclaw-gateway only if you want to run an agent gateway alongside it.

Configure keyring-proxy

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. Set the port to 3100 in the service's networking settings.

5. 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 (optional)

The OpenClaw gateway is a separate Docker image — it is not built from this repo. You can deploy it as a Railway service using a Docker image reference.

1. Add a new service and select Docker Image as the source.

2. Point it at your OpenClaw image (e.g. from a container registry).

3. Name the service openclaw-gateway.

4. Set the port to 18789.

5. Use Railway reference variables to connect to the keyring-proxy:

KEYRING_PROXY_URL=http://keyring-proxy.railway.internal:3100
KEYRING_PROXY_SECRET=<same secret as keyring-proxy>

6. The entrypoint script (scripts/openclaw-entrypoint.sh) installs SIWA skill dependencies and registers the skill before starting the gateway.

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...).
KEYRING_PROXY_PORT	No	Defaults to 3100.

openclaw-gateway (optional)

Variable	Required	Description
KEYRING_PROXY_URL	Yes	URL of the keyring proxy. Use private networking (e.g. http://keyring-proxy.railway.internal:3100) when both services run in the same project, or a public domain when the agent runs externally.
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).

# keyring-proxy (internal only — run from Railway shell)
curl http://keyring-proxy.railway.internal:3100/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:

# Same Railway project — use internal networking
KEYSTORE_BACKEND=proxy
KEYRING_PROXY_URL=http://keyring-proxy.railway.internal:3100
KEYRING_PROXY_SECRET=<your-shared-secret>

# External agent / existing OpenClaw — use the public domain
KEYSTORE_BACKEND=proxy
KEYRING_PROXY_URL=https://your-keyring-proxy.up.railway.app
KEYRING_PROXY_SECRET=<your-shared-secret>

If your agent or OpenClaw instance runs inside the same Railway project, it reaches the proxy via internal networking. If it runs externally (e.g. an existing OpenClaw container or a local agent), assign a public domain to the keyring-proxy and use that URL instead. 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.