---
title: "Deploy OpenWork"
description: "OpenWork w/ OpenCode, persistent storage, remote access. openwork open work"
category: "AI/ML"
url: https://railway.com/deploy/openwork
---

# Deploy OpenWork

OpenWork w/ OpenCode, persistent storage, remote access. openwork open work

**[Deploy OpenWork on Railway](https://railway.com/template/openwork)**

- **Creator:** Xav's Projects
- **Category:** AI/ML
- **Total deploys:** 1

## Template content

### openwork https://bc.xavto.fr/xavto/dark.svg

- **Source:** https://github.com/XavTo/openwork
- **Public domain:** Yes

## Documentation

# 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

- [OpenWork GitHub repository](https://github.com/different-ai/openwork)
- [OpenWork self-hosting documentation](https://openworklabs.com/docs/start-here/self-host)

### Implementation Details

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

#### Required Railway settings

```text
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:

```text
/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

```env
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

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

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

4. In a compatible OpenWork client, add a remote worker using the Railway URL and `OPENWORK_TOKEN`.
5. Configure an AI model provider through the client or the OpenWork/OpenCode configuration.
6. 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:

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

Check that the public health endpoint responds:

```bash
curl -i "$BASE_URL/health"
```

Expected result:

```text
HTTP/2 200
```

Verify that protected routes reject unauthenticated requests:

```bash
curl -i "$BASE_URL/status"
```

Expected result:

```text
HTTP/2 401
```

Test authenticated server status:

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

The response should report:

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

Test the workspace and runtime capabilities:

```bash
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:

```bash
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:

```text
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.



## Similar templates

- [Chat Chat](https://railway.com/deploy/-WWW5r) — Chat Chat, your own unified chat and search to AI platform.
- [stella](https://railway.com/deploy/stella) — Self-host stella with web, API, Postgres, Redis, and object storage.
- [Hermes Agent | OpenClaw Alternative with Dashboard](https://railway.com/deploy/hermes-agent-or-openclaw-alternative-wit) — Self-Hosted Hermes AI Agent for Telegram, Discord & Slack

Open this page in a browser: https://railway.com/deploy/openwork