Skip to main content

Documentation Index

Fetch the complete documentation index at: https://openworklabs.com/docs/llms.txt

Use this file to discover all available pages before exploring further.

Most users just use the desktop app. Self-hosting is for teams that want OpenWork to run on their own server, VPC, or private cloud and then connect the desktop app to it remotely. Want hosted workspaces, team skill hubs, or shared providers without running infra? Use OpenWork Cloud instead. Rolling this out across a company? Book a call about Enterprise.

​
What you deploy

OpenWork is split into normal services:
  • OpenWork app: the desktop or web client people use.
  • Den web: the web app for sign-in, worker launch, and connect links if you want a cloud-style setup.
  • Den controller: the control plane for auth, workers, and provisioning.
  • Worker proxy: optional layer for provider-backed workers and signed runtime URLs.
If you only need one private remote workspace, deploy the worker runtime. If you want OpenWork Cloud-style accounts, teams, and worker creation, deploy Den web, Den controller, the worker proxy, and worker runtimes.

​
How we deploy hosted workers

Our hosted deployment uses Render for long-running services and worker provisioning. Render gives us service deploys, env vars, health checks, logs, and worker builds without asking us to operate raw AWS services directly. If you want to run closer to AWS yourself, use the same service boundaries on ECS/Fargate, EC2, Kubernetes, or another container platform. The production shape is straightforward:
  • Put HTTPS in front of every public service.
  • Expose the OpenWork server/worker URL, not raw opencode.
  • Keep workspace and data paths on durable storage.
  • Configure public URLs, auth origins, CORS origins, tokens, and provider credentials with env vars.
  • Run Den database migrations before the Den controller receives traffic.
For a containerized worker runtime, start from the Docker packaging in the repo.

​
Databases and storage

  • Worker runtimes use filesystem state and opencode SQLite data inside the mounted workspace/data paths.
  • The Den control plane uses a MySQL-compatible database. Local Docker uses MySQL 8.4; production can use standard MySQL or PlanetScale-compatible credentials.
  • Postgres is not required by the current Den deployment path.
  • The share service stores public bundle payloads in Vercel Blob in our hosted setup. Local/dev can fall back to filesystem storage. If you self-host share, use equivalent object storage or leave share disabled.

​
Auth and SSO

Den uses Better Auth. It runs in your deployment, uses your database, and is configured with your BETTER_AUTH_SECRET, BETTER_AUTH_URL, trusted origins, and optional GitHub/Google OAuth credentials. SSO (SAML/OIDC) is in the current rollout and is designed to run against your own identity provider. When enabled, callback URLs and trusted origins should point at your self-hosted Den web/controller hosts. If you do not deploy Den, worker access is token-based with OPENWORK_TOKEN and OPENWORK_HOST_TOKEN.

​
Minimal Working Stack

​
OpenWork Cloud and the Desktop App

OpenWork cloud is composed of two services:
  • NextJS frontend
  • NodeJS backend (Hono) with MySQL DB
  • Electron/React desktop app
These three alone cover most feature but do not include:
  • Remote code execution through sandboxes
  • Analytic
  • Telemetry (upcoming) via open telemetry
  • Email management: inviting users, etc.

​
Optional vendors

OpenWork does not require many third-party services for the core runtime. These are optional or deployment-specific:
  • We use Render: our current hosted service and worker deployment path.
  • Daytona: optional sandbox provider for cloud workers.
  • Vercel: optional Den web/share hosting and worker DNS automation.
  • PostHog: optional analytics for public web surfaces. You can point it at self-hosted PostHog with NEXT_PUBLIC_POSTHOG_HOST, or remove/clear the key in your self-hosted web build if you do not want analytics.
  • Polar: optional billing/paywall for hosted cloud workers.
  • Loops: optional user sync and lifecycle messaging.
  • GitHub/Google OAuth: optional social sign-in providers for Better Auth.

​
Don’t want to run infra?

Skip the server. OpenWork Cloud runs hosted workers for your team. Cloud also gives you org-wide primitives you’d otherwise have to build: team skill hubs, shared LLM providers, RBAC, and shared workspaces.

​
Looking for support for a larger rollout?

If you’re rolling OpenWork out across a company of 150+ employees, the orchestrator on a single VM might be harder to manage. At that scale our customers typically want:
  • SSO (SAML/OIDC) so people sign in with the identity your company already uses
  • Audit logs across sessions, tool calls, and model usage
  • Model and tool allowlists enforced centrally, not per-workspace
  • VPC / on-prem deployment with your own networking and compliance constraints
  • Support and rollout help from our team and custom deployment, not just in GitHub.
You can check the Enterprise page or book a 30-minute call.