Docker & Hosted Deployment
Relevant source files
The following files were used as context for generating this wiki page:
OpenWork is designed with a "local-first, cloud-ready" philosophy, providing flexible deployment options ranging from a standalone desktop application to containerized cloud environments. The architecture supports both self-hosted instances on private infrastructure and a managed hosted worker model through OpenWork Cloud.
Sources: AGENTS.md:15, README.md:4
Deployment Architectures
OpenWork categorizes its deployment into several distinct modes to accommodate different security requirements and scaling needs.
1. Self-Hosted Infrastructure
In a self-hosted deployment, OpenWork Enterprise runs entirely within the customer's servers. This model ensures that no code, API keys, or prompts are visible to the OpenWork team, as there is no hosted control plane or phone-home telemetry for these instances. Users bring their own LLM gateways (e.g., LiteLLM, Cloudflare AI Gateway) and authentication stacks (SSO/SAML).
Sources: ee/apps/landing/components/landing-trust.tsx:90-116
2. Dockerized Dev/Test Stack (Den)
For development and testing, OpenWork provides the "Den local stack." This Docker-based configuration bundles the Den control plane, a MySQL database, and the OpenWork Cloud web app into a single environment.
The diagram above illustrates the internal communication between components in the Den local stack.
Sources: packaging/docker/README.md:5-18
3. Micro-Sandbox Image
The micro-sandbox is a pre-baked image designed for isolated work. It compiles openwork and openwork-server from source and includes a pinned opencode binary. It typically operates with OPENWORK_APPROVAL_MODE=auto.
Sources: packaging/docker/README.md:65-79
4. Hosted Workers (OpenWork Cloud)
OpenWork Cloud provides a managed experience where users get access to hosted workers without managing their own keys or server infrastructure. These workers are launched via the web app and connected to the desktop client through a "Connect remote" flow.
Sources: AGENTS.md:10, README.md:23
Configuration and Environment Variables
Deployment behavior is primarily controlled via environment variables. The system distinguishes between "Collaborator" tokens (routine access) and "Owner/Host" tokens (admin actions/approvals).
Common Configuration Options
| Variable | Description | Default |
|---|---|---|
OPENWORK_TOKEN | Bearer token for client/collaborator access. | Auto-generated UUID |
OPENWORK_HOST_TOKEN | Admin/Owner token for host-level actions. | Auto-generated UUID |
DEN_PROVISIONER_MODE | Determines worker provisioning logic (stub or render). | stub |
OPENWORK_APPROVAL_MODE | Set to auto or manual for tool execution permissions. | manual |
OPENWORK_PORT | Host port mapped to the server container. | 8787 |
Sources: packaging/docker/README.md:118-124, packaging/docker/docker-compose.dev.yml:13-23, 64-71
Orchestration Logic
The openwork-orchestrator (CLI host) serves as the primary entry point for containerized deployments. It manages the lifecycle of the OpenCode engine and the OpenWork server.
The diagram shows the orchestrator initializing both the internal engine and the public-facing server.
Sources: packaging/docker/README.md:95-103, README.md:12-16
Persistence and Storage
Data persistence in Docker deployments is handled through volume mounts to ensure workspace and configuration data survive container restarts.
- Workspace Path: Mounted at
/workspace. This contains the project files and.opencodeconfigurations. - Host Data: Mounted at
/dataor/persist. This includes OpenCode caches, server configurations, and authentication tokens. - Database: In the Den dev stack, MySQL data can be reset using
docker compose down -v.
Sources: packaging/docker/README.md:126-130, packaging/docker/docker-compose.dev.yml:32-37
Deployment Security and Trust
OpenWork emphasizes data residency, allowing organizations to pick specific regions and network boundaries for their deployment. In self-hosted modes, no customer data is received by the OpenWork team.
| Data Type | Self-Hosted Deployment | Cloud Deployment |
|---|---|---|
| API Keys | Stored in your infra | Encrypted in OpenWork Cloud |
| Code/Files | Stored in your infra | Stored in OpenWork Cloud |
| Prompts | Direct to LLM provider | Proxied via Cloud |
| Telemetry | None | Basic usage metrics |
Sources: ee/apps/landing/components/landing-trust.tsx:125-155
Summary
OpenWork's deployment strategy provides a seamless transition from local development to production-grade hosting. Whether utilizing the den-dev stack for rapid iteration, the micro-sandbox for isolated tasks, or full Enterprise self-hosting for maximum security, the project maintains a consistent interface through the openwork-orchestrator and environment-based configuration.