Deploy and Host DeepSeek Harness on Railway

DeepSeek Harness (dsh) is DeepSeek's own open-source agent harness — the layer that turns a model into an agent that can read your files, run shell commands, search the web, and keep working across a long task. Everything in it is a plugin: models, tools, skills, sessions, sandboxes, storage, loops, scheduling, and the UI itself.

Upstream ships it as npx @deepseek-ai/dsh web, which serves the Web UI on 127.0.0.1:3080 — your laptop, while your laptop is awake. This template runs that same Web UI on Railway, always on, reachable from any browser, behind a password.

About Hosting DeepSeek Harness

The hard part of hosting this is not the app, it is the exposure.

DeepSeek Harness has no authentication. Upstream states this plainly — "No TLS, auth, or origin policy" — and its CLI refuses to bind a public address, erroring with "it would expose remote code execution to the network". That refusal is correct: an agent with a shell tool on an open URL is a remote-code-execution box on your Railway account, and a persistent volume means anyone who finds it keeps their foothold across your redeploys.

So this template does not bypass that refusal. dsh stays bound to loopback exactly as upstream intends, and a Caddy reverse proxy owns the public port, enforces HTTP basic auth, and forwards to loopback — rewriting Host and Origin so the harness's own anti-DNS-rebinding fence stays satisfied through the proxy. The agent is never reachable from outside; the only public surface is the authenticated proxy.

The gate cannot be switched off. Leave the password blank and the container generates a strong one on first boot, stores it on the volume, and prints it once to your deploy log.

Also handled for you: the container listens on Railway's injected PORT; the healthcheck path is answered by the proxy, since Railway's health prober cannot present credentials; the agent and the proxy supervise each other, so if the agent dies the container exits and Railway restarts it rather than serving a green healthcheck over a dead agent; and node-pty gets a real toolchain, without which the image does not even build.

Runs on Ubuntu 24.04 with Node 24 and a full apt userland, so the agent can apt-get install what it needs mid-session. There is a companion template, DeepSeek Harness on NixOS, that swaps the base for the nix package manager — same gate, same persistence, reproducible pinned packages from nixpkgs instead of apt.

Measured at 164 MiB idle under a 1 GB cap, so it fits Railway's Trial and Hobby plans comfortably.

Why Deploy DeepSeek Harness on Railway

Always on, and reachable from anything. The upstream quick start dies when you close your laptop. Here the agent keeps its session, its memory, and its workspace on a volume, and you pick the task back up from your phone.
Gated by default, provably. Unauthenticated requests to the UI, to the API, and to the WebSocket all return 401 — including requests that forge a loopback Host header to try to satisfy the harness's own fence. Verified, not asserted.
One volume covers everything. Sessions, config, credentials, and the agent's files all live under a single mount, so a redeploy does not wipe the work.
Nothing to fill in but your model key. Every platform setting is baked into the image rather than dumped on the deploy form as blank required fields.
Pinned, not floating. The harness is in developer preview and upstream warns of compatibility-breaking changes, so the version is pinned — your deploy does not break the next time upstream ships.

Common Use Cases

A coding agent that outlives your laptop — hand it a long refactor or a migration, close the lid, check the trajectory view from your phone later.
A shared team agent box — one gated URL your team can open, with an append-only session log of everything the model saw, so a run can be inspected, resumed, forked, or replayed.
A harness development sandbox — DSH is a plugin system in developer preview, and Creator mode is built for authoring and testing Cordis plugins. A disposable hosted instance is a safer place to experiment than your own machine.
A scratch environment you do not mind breaking — the agent gets a real shell in a container that is one redeploy away from clean.

Dependencies for DeepSeek Harness Hosting

A DeepSeek API key from platform.deepseek.com. Other providers work too — DSH resolves each provider's key from a variable that provider's own entry in settings.yaml names.
A volume mounted at /home/dsh, for sessions, config, credentials and the workspace.

Deployment Dependencies

DeepSeek Harness — the upstream project (MIT)
Product page — modes, plugin model, trajectory view
@deepseek-ai/dsh — the published CLI
Caddy — the authenticating reverse proxy in front of it
DeepSeek Platform — where the API key comes from

Implementation Details

Set the access gate at deploy time, or let it generate one:

Variable	Default	Purpose
`DEEPSEEK_API_KEY`	—	Model access. The UI loads without it; the agent cannot answer.
`DSH_USERNAME`	`admin`	Basic-auth user.
`DSH_PASSWORD`	generated	Basic-auth password. Blank means generated, never disabled.
`DEEPSEEK_BASE_URL`	DeepSeek API	Point at a gateway or proxy instead.

The request path:

browser ──TLS──> Railway edge ──> Caddy on $PORT   (basic auth; 401 without credentials)
                                       │
                                       └──> dsh web on 127.0.0.1:3080  (never reachable outside)

To retrieve a generated password, open the deploy logs and look for the [entrypoint] lines on first boot. To stop it appearing in logs at all, set DSH_PASSWORD as a service variable.

One caveat, stated plainly. This is a single shared password over Railway's TLS. That is the right gate for one operator running their own agent box. It is not multi-user access control, and it does not protect you from someone who already has the password. If the workspace will hold anything sensitive, put Cloudflare Access or a VPN in front as well.