> ## Documentation Index
> Fetch the complete documentation index at: https://differentai-cleanup-ai-gateway-models-replacement.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Self-host

> Run OpenWork on your own server or infrastructure.

Most users just use the [desktop app](https://openworklabs.com/download). 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 Collections, or shared providers without running infra? Use [OpenWork Cloud](/cloud/get-started) instead. Rolling this out across a company? [Book a call](https://calendar.app.google/86QpCENvhfEzDFLu5) about [Enterprise](/cloud/enterprise).

<Note>
  Want to try the self-hosted control plane before planning production infrastructure? Start the [pull-only Docker Compose evaluation stack](/self-host/evaluate-with-docker-compose). It uses published images and does not require cloning or building the repository.
</Note>

## 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.
* **OpenWork Gateway**: optional model-request routing and metering service from `ee/apps/gateway`, including the existing OpenWork Models proxy. This is not the separate `den-gateway` Web proxy.

If you only need one private remote workspace, deploy the worker runtime. If you want OpenWork Cloud-style accounts, teams, and organization management, deploy Den web, Den controller, and optionally OpenWork Gateway.

For Kubernetes installs, use the published Helm chart:

```bash theme={null}
helm upgrade --install openwork-ee oci://ghcr.io/different-ai/charts/openwork-ee \
  --version <chart-version> \
  -f values.prod.yaml
```

`--version` pins the chart. Inspect its `image.tag`, `appVersion`, and component image overrides to pin the intended images; older published charts can default to the floating tag `latest`. The images are `openwork-den-api`, `openwork-den-web`, and optional `openwork-inference` (the retained Gateway repository) on GHCR unless mirrored internally. A chart upgrade alone does not add Gateway support to older images.

For Gateway deployment configuration, use the chart implementation introduced in `0.2.0` or later with matching Den API, Den Web, and Gateway images from the capability-version-1 release. The checkout's placeholder `appVersion` is not a compatible image recommendation. Follow [Enable OpenWork Gateway](/self-host/gateway) for explicit configuration and [Upgrade Gateway safely](/self-host/gateway-upgrade) for the quiesced database cutover before any existing installation rolls out these images. Gateway is GA for admins in every organization when configured, without an organization flag or platform-admin grant. `GATEWAY_ENABLED` and `deploymentCapabilities.aiGateway` remain installation configuration checks: legacy `inference.enabled: true` alone does not enable Gateway management, and OpenWork Models billing remains separate.

Choose a tested provider path in [Deploy to your cloud](/self-host/deploy-to-your-cloud/overview). The public guides cover AWS, Azure, and Google Cloud, including managed MySQL, ingress, DNS, TLS, migrations, and secure creation of the first administrator.

## Plan the network

Use the dedicated Self-host planning pages instead of copying hostname, certificate, proxy, and diagnostics details into this overview:

* [Private network deployment](/start-here/private-network-deployment): the common topology where laptops have internet plus VPN access and Den stays private.
* [Air-gapped deployment](/start-here/air-gapped-deployment): definitions and the checklist for full isolation.
* [Outbound network access](/start-here/outbound-network-access): the canonical customer IT destination inventory and "what breaks when blocked" guidance.
* [Certificate trust and proxies](/start-here/certificate-trust-and-proxies): desktop, sidecar, Den, and MySQL trust surfaces.
* [Enterprise desktop deployment](/start-here/enterprise-desktop-deployment): the enterprise binary, MDM distribution, and the `desktop-bootstrap.json` reference.
* [Installer delivery](/start-here/installer-delivery): GitHub redirect and mounted artifacts for organization install links.
* [Network diagnostics](/start-here/network-diagnostics): Windows doctor, Cloud catalog diagnostic trust, and Den outbound checks.

If you want self-hosted repository imports and sync from GitHub, configure the [GitHub connector for Helm](/start-here/github-connector-helm) after the core Den web and Den controller hosts are reachable.

To keep organization names, wordmarks, and desktop icons inside your deployment, follow [Brand an on-prem deployment](/start-here/on-prem-branding).

## 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.

In production, hosted OpenWork runs the Cloud app and Den controller as scaled Render services with at least two instances. Render load balances traffic across healthy instances, removes failing instances from routing, and restarts failed instances. Den controller application instances are stateless replicas; shared control-plane state is stored in PlanetScale.

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 `DEN_BASE_URL`, tokens, and provider credentials with env vars. Den derives the Better Auth URL, CORS/trusted origins, API defaults, MCP resource defaults, and web-app host allowlist from `DEN_BASE_URL` unless you set compatibility overrides for a split-origin deployment.
* Run Den database migrations before the Den controller receives traffic.

For containerized services, start from the [Docker packaging](https://github.com/different-ai/openwork/tree/dev/packaging/docker) 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.
* Hosted OpenWork uses PlanetScale for Den control-plane state. PlanetScale production clusters provide one primary and at least two replicas across three availability zones, managed failover, and automated backups.
* Postgres is not required by the current Den deployment path.

For production, configure encryption explicitly:

* Enable encryption at rest for the MySQL-compatible database, database backups, object storage, worker volumes, and logs that may contain operational metadata.
* Require TLS for application-to-database traffic. In OpenWork, `sslmode=require`, `sslmode=verify-ca`, `sslmode=verify-full`, and `sslaccept=strict` all verify the server certificate chain and hostname (Den's MySQL client treats `verify-ca` the same as `verify-full`), so the server certificate must chain to a trusted CA and carry the database hostname in its SAN. Use `sslmode=verify-full` and provide a private CA bundle through the database platform or Helm `customCa`. Only `sslaccept=accept` encrypts without certificate verification; keep it for smoke tests.
* Keep local Docker database defaults for development only; use precreated Secret references for production credentials.
* Set a unique `DEN_DB_ENCRYPTION_KEY` of at least 32 characters. OpenWork uses it to encrypt selected sensitive database columns, but it does not replace infrastructure-level encryption at rest.

For a self-hosted production deployment, use a managed MySQL-compatible database with automated failover and backups, or provide equivalent redundancy yourself. Document the restore process, backup retention, recovery time objective, recovery point objective, and the person or team responsible for failover and restore.

## Auth and SSO

Den uses Better Auth. It runs in your deployment, uses your database, and is configured with your `BETTER_AUTH_SECRET`, `DEN_BASE_URL`, and optional GitHub/Google OAuth credentials. `BETTER_AUTH_URL`, trusted origins, CORS origins, and web-app hosts are derived from `DEN_BASE_URL`; set the older variables only when you are intentionally migrating or running a split-origin topology.

Private deployments should keep public signup disabled and use the one-time [first-administrator setup flow](/self-host/deploy-to-your-cloud/first-administrator). Configuring an owner or platform-admin email does not create an account or password, and OpenWork does not ship a default administrator password.

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.

For isolated Kubernetes deployments without approved outbound access to the Have I Been Pwned Pwned Passwords range API, the Helm chart disables external breached-password lookup by default. Email/password sign-in lockout remains local. If your deployment approves that external lookup, enable it in Helm. See [Air-gapped deployment](/start-here/air-gapped-deployment) for the broader isolation checklist.

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-style self-hosting is composed of three main pieces:

* Next.js frontend
* Node.js backend (Hono) with MySQL DB
* Electron/React desktop app

The desktop app should be pointed at the Den web URL. On startup it reads `${DEN_BASE_URL}/api/runtime-config` from Den Web and uses the returned `denApiUrl` as the source of truth for Den API and MCP traffic. Den Web returns `DEN_API_PUBLIC_URL` when you set it; otherwise it deterministically derives the API origin as `api.${DEN_BASE_URL}`. `DEN_BASE_URL` is required on Den Web. `DEN_API_BASE` is the server-only URL Den Web uses to reach Den API internally; it is never returned to desktops.

* API default: `https://api.<den-web-host>/v1/...`
* MCP default: `https://api.<den-web-host>/mcp/...`

For self-hosted deployments, configure the desktop `baseUrl` to the public Den web origin and make sure `${DEN_BASE_URL}/api/runtime-config` is reachable from member desktops. If the API is not available at `api.${DEN_BASE_URL}`, set `DEN_API_PUBLIC_URL` on Den Web to the externally reachable API origin you want desktops to use.

These three pieces cover most features, but do not include:

* Remote code execution through sandboxes
* Analytics
* Telemetry through OpenTelemetry
* Transactional email for invitations and lifecycle messages

## Optional vendors

OpenWork does not require many third-party services for the core runtime. These are optional or deployment-specific:

* Render: our current hosted service and worker deployment path.
* Daytona: optional sandbox provider for cloud workers.
* Vercel: optional Den web 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.
* GitHub connector app: optional repository connector for importing and syncing plugins or marketplaces from GitHub. For Helm installs, use the [GitHub connector setup guide](/start-here/github-connector-helm).

## Don't want to run infra?

Skip the server. [**OpenWork Cloud**](/cloud/get-started) runs hosted workers for your team.

Cloud also gives you org-wide primitives you'd otherwise have to build: [Collections](/cloud/share-with-your-team/collections), [shared LLM providers](/cloud/share-with-your-team/managed-llm-provider), [RBAC](/cloud/members-and-rbac), and [OpenWork Web](/cloud/run-in-the-cloud/shared-workspace).

## Looking for support for a larger rollout?

If you're rolling OpenWork out across a company of 150+ employees, a single self-hosted server 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**](/cloud/enterprise) page or [book a 30-minute call](https://calendar.app.google/86QpCENvhfEzDFLu5).