Deploy and Host OpenHuman Core on Railway

OpenHuman Core is the Rust backend behind the OpenHuman desktop app — agent runtime, memory, skills, scheduler and a JSON-RPC API. This template runs it as an always-on remote core on Railway, with its workspace on a persistent volume and its RPC surface behind a bearer token that Railway generates for you.

About Hosting OpenHuman Core

Hosting the core on Railway means your agent, its memory and its schedules keep running when your laptop is closed, and any OpenHuman desktop client can attach to the same core from anywhere. Deploy the template, wait for the service to go healthy, then copy OPENHUMAN_CORE_RPC_URL and OPENHUMAN_CORE_TOKEN from the service variables into the desktop app's remote-core settings.

This template is packaged for how Railway actually redeploys containers:

The managed Node runtime is baked into the image. The agent harness normally downloads Node v22.11.0 (29 MB archive, ~190 MB extracted) from nodejs.org on first boot, into a cache directory that is not the volume — so on Railway that download is replayed on every single redeploy, and a boot with no egress to nodejs.org leaves the JavaScript harness unavailable. Here the first boot is already a warm start.
A working healthcheck. The core reads its listen port from OPENHUMAN_CORE_PORT and ignores PORT, while Railway's healthcheck dials the port it injects — so an unmodified image cannot pass a healthcheck at all, and a broken boot is reported as a successful deploy. This image follows the injected port, and the deploy is gated on GET /health.
The version is pinned. The core migrates its workspace — config.toml and its SQLite session and memory databases — forward on boot, so an unpinned image turns any redeploy into an unrequested upgrade with no way back.
The deploy form asks for nothing. The token is generated by Railway and the RPC URL is derived from your public domain; every other setting is baked into the image.

The volume is mounted at /home/openhuman/.openhuman, which holds config, the session and memory databases, the skill registry and agent state.

Common Use Cases

Run OpenHuman as an always-on remote core that survives closing your laptop
Attach the OpenHuman desktop app from several machines to one shared agent, memory and schedule
Keep long-running agent flows, cron jobs and MCP clients executing on a hosted machine

Dependencies for OpenHuman Core Hosting

The OpenHuman desktop app, pointed at this deployment's RPC URL
A Railway volume for the core workspace
The TinyHumans backend (https://api.tinyhumans.ai) for sign-in and cloud services

Deployment Dependencies

Implementation Details

The core refuses to bind a public address without an operator-supplied token, so the template generates one:

OPENHUMAN_CORE_TOKEN="${{ secret(32) }}"
OPENHUMAN_CORE_RPC_URL="https://${{ RAILWAY_PUBLIC_DOMAIN }}/rpc"

Check the deployment before connecting a client:

curl https:///health          # 200, no token required
curl -X POST https:///rpc \
  -H "Authorization: Bearer $OPENHUMAN_CORE_TOKEN" \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"core.status"}'

An unauthenticated POST /rpc answers 401.

Why Deploy OpenHuman Core on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying OpenHuman Core on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.