Deploy and Host OpenWork on Railway

OpenWork is an open-source, local-first AI workspace powered by OpenCode. It provides a permissioned interface for running agentic workflows, working with files, managing skills and plugins, and connecting desktop or web clients to a local or remote worker without exposing the underlying OpenCode service directly.

About Hosting OpenWork

Hosting OpenWork on Railway creates a private remote worker containing both the OpenWork server and its managed OpenCode runtime. The template deploys one long-running service, exposes the OpenWork API over HTTPS, and stores the workspace, server configuration, OpenCode state, and scoped tokens on a persistent Railway volume mounted at /data. Access is protected by separate client and host tokens. Railway builds the included Dockerfile, routes traffic to port 8787, and checks /health before activating a deployment. This template is intended for a single persistent remote workspace rather than the complete multi-user OpenWork Cloud control plane.

Common Use Cases

Run a private OpenWork and OpenCode workspace from any compatible remote client.
Keep AI-generated files, skills, commands, plugins, and MCP configuration on persistent storage.
Provide a token-protected remote worker for personal use or controlled collaboration.

Dependencies for OpenWork Hosting

A Railway account with persistent volume support.
A compatible OpenWork client and access to an AI model provider for agent execution.

Deployment Dependencies

Implementation Details

This template deploys a single Railway service with one persistent volume.

Required Railway settings

Dockerfile path: packaging/docker/Dockerfile
Public port: 8787
Healthcheck path: /health
Volume mount path: /data

All persistent paths are located under the same Railway volume:

/data/workspace
/data/openwork-orchestrator
/data/sidecars
/data/home

The OpenWork server is exposed publicly, while the managed OpenCode process remains bound to the container's loopback interface.

Environment variables

RAILWAY_DOCKERFILE_PATH="packaging/docker/Dockerfile" # Path to the Railway-compatible Dockerfile.
PORT="8787" # Public port used by Railway for routing and healthchecks.
OPENWORK_PORT="8787" # Internal port used by the OpenWork server.
OPENWORK_SERVER_CONFIG="/data/openwork-orchestrator/server.json" # Persistent OpenWork server configuration file.
OPENWORK_TOKEN_STORE="/data/openwork-orchestrator/tokens.json" # Persistent store for scoped access tokens.
OPENWORK_TOKEN="${{secret(32)}}" # Client token used by remote apps and collaborators.
OPENWORK_HOST_TOKEN="${{secret(32)}}" # Privileged owner token used for approvals and token management.
OPENWORK_APPROVAL_MODE="manual" # Requires approval before privileged agent actions.
OPENWORK_APPROVAL_TIMEOUT_MS="30000" # Approval request timeout in milliseconds.
OPENWORK_CORS_ORIGINS="*" # Origins allowed to access the OpenWork API.

Do not replace the generated token functions with fixed credentials when publishing the template. Each deployment should receive unique client and host tokens.

How to use the template

Deploy the template and wait for the OpenWork service to become healthy.
Open the service variables and copy the generated OPENWORK_TOKEN.
Use the Railway public domain as the remote worker URL:

https://your-service.up.railway.app

In a compatible OpenWork client, add a remote worker using the Railway URL and OPENWORK_TOKEN.
Configure an AI model provider through the client or the OpenWork/OpenCode configuration.
Start a session and ask OpenWork to read or create files inside the workspace.

The root URL may return 404. This is expected because the server API does not provide a homepage at /. Use /health for readiness checks and /ui for the included lightweight test interface when enabled.

How to test the deployment

Set the Railway domain and client token in a terminal:

export BASE_URL="https://your-service.up.railway.app"
export OPENWORK_TOKEN="your-client-token"

Check that the public health endpoint responds:

curl -i "$BASE_URL/health"

Expected result:

HTTP/2 200

Verify that protected routes reject unauthenticated requests:

curl -i "$BASE_URL/status"

Expected result:

HTTP/2 401

Test authenticated server status:

curl -i \
  -H "Authorization: Bearer $OPENWORK_TOKEN" \
  "$BASE_URL/status"

The response should report:

{
  "ok": true,
  "readOnly": false,
  "workspaceCount": 1,
  "authorizedRoots": ["/data/workspace"]
}

Test the workspace and runtime capabilities:

curl -i \
  -H "Authorization: Bearer $OPENWORK_TOKEN" \
  "$BASE_URL/workspaces"

curl -i \
  -H "Authorization: Bearer $OPENWORK_TOKEN" \
  "$BASE_URL/capabilities"

curl -i \
  -H "Authorization: Bearer $OPENWORK_TOKEN" \
  "$BASE_URL/whoami"

Each request should return HTTP 200.

To test the privileged host token:

export OPENWORK_HOST_TOKEN="your-host-token"

curl -i \
  -H "X-OpenWork-Host-Token: $OPENWORK_HOST_TOKEN" \
  "$BASE_URL/tokens"

For a complete end-to-end test, connect an OpenWork client and ask it to create a file:

Create a file named railway-test.txt containing:
OpenWork Railway persistence test.

After approving the action, redeploy the Railway service and ask OpenWork to read the same file. If the file remains available, the OpenWork server, managed OpenCode runtime, permissions, and Railway volume are all working correctly.

Important limitations

This template deploys one remote worker, not the complete OpenWork Cloud or Den multi-user stack.
An AI provider and valid model credentials are still required to execute prompts.
The Railway container is not a full virtual machine and cannot provide nested Docker, systemd, KVM, or unrestricted host access.
Browser automation is not enabled by this template unless an appropriate remote browser integration is added separately.
Because the service uses a persistent volume, Railway redeployments may include a short period of downtime.
Keep OPENWORK_HOST_TOKEN private. It grants privileged access to approvals and token management.

Why Deploy OpenWork 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 OpenWork 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.