Deploy and Host OpenCode Server on Railway

OpenCode is the open-source, always-on AI coding agent from the team behind SST (formerly sst/opencode, now anomalyco/opencode, 199k+ GitHub stars). This template runs it as a persistent, authenticated web server so you can drive it from a browser or point automation at it, instead of only running it locally in a terminal.

About Hosting OpenCode Server

This template builds OpenCode from source at deploy time and wraps it with a small Node.js proxy that adds HTTP Basic Auth plus signed-cookie browser sessions, since the OpenCode CLI's own web server has no built-in authentication. All credit for that wrapper goes to LaceLetho/opencode-railway-template - this template deploys the same code, unmodified, from a fork so the source stays stable regardless of upstream changes.

The one thing this template does differently from the current catalog listing: it explains, and keeps verified, why the OpenCode version is pinned to v1.14.41 instead of tracking latest.

Testing this template against newer OpenCode releases (v1.18.18, the current tag, tested both as a source build and via the published opencode-ai npm package) reproduces the same failure every time: the internal opencode serve process starts and logs opencode server listening on http://127.0.0.1:18080, but the wrapper's own outbound health check to that same endpoint never resolves. No further log output, no timeout error, no crash - the outer proxy on port 8080 simply never starts, and every request gets Railway's own 502 Application failed to respond. v1.14.41 does not have this problem: verified across three separate live deployments, health check, and full Basic Auth login flow all passing cleanly. Something between those two releases broke compatibility with the wrapper's startup check, and the fix here is to not guess at a newer default until that's root-caused upstream.

Why Deploy OpenCode Server 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 OpenCode Server 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.

Specific to this template:

The version pin is verified, not stale. The catalog's most-installed OpenCode template also pins v1.14.41, but doesn't say why - this one documents the exact newer-version failure mode so nobody wastes an hour bumping OPENCODE_REF themselves and hitting the same silent 502.
HTTP Basic Auth and signed browser sessions in front of OpenCode's own unauthenticated web server, with timing-safe credential comparison.
A persistent volume at /data so your workspace, OpenCode config, and session history survive redeploys.

Common Use Cases

A personal, always-on coding agent you can reach from any browser or from CI, without keeping a terminal session open.
A shared OpenCode instance for a small team, gated behind a real password instead of an open port.
A sandboxed agent workspace that persists context (via the /data volume) between sessions.

Dependencies for OpenCode Server Hosting

None - OpenCode is built from source inside the container at deploy time.

Deployment Dependencies

Implementation Details

OPENCODE_SERVER_PASSWORD is required - set it before deploying, it's the password for HTTP Basic Auth and the browser login page (username defaults to opencode). Everything else has a working default.

Leave OPENCODE_REF at v1.14.41 unless you've independently verified a newer tag works with this wrapper - see above for what happens if you don't.

Verified on this template: source build completes, /global/health returns {"healthy":true,"version":"1.14.41"} through the authenticated proxy, and unauthenticated/wrong-password requests correctly get 401.