# OpenWork Deployment Strategies: A Complete Guide to Self-Hosting different-ai/openwork

> Explore OpenWork deployment strategies for your AI needs. Learn about six options from desktop binaries to air-gapped Kubernetes. Discover production-ready Helm charts for efficient self-hosting.

- Repository: [Different AI/openwork](https://github.com/different-ai/openwork)
- Tags: how-to-guide
- Published: 2026-08-04

---

**The different-ai/openwork project supports six distinct deployment strategies ranging from desktop-only binaries to air-gapped Kubernetes clusters, with the Helm chart `openwork-ee` being the primary production packaging method.**

OpenWork by different-ai is an open-source AI workbench that combines a desktop client with a optional backend control plane. Depending on your team size, security requirements, and infrastructure capabilities, you can choose from lightweight single-user setups to enterprise-grade multi-tenant deployments. This guide covers every official deployment strategy with precise configuration examples drawn directly from the source repository.

---

## Desktop-Only Deployment

The simplest **OpenWork deployment strategy** requires no server infrastructure. Individual users download the pre-built Electron application from the [OpenWork website](https://openworklabs.com/download) and run workers locally or connect to remote inference endpoints.

- **Best for:** Solo developers, small teams, or security-restricted environments
- **Components:** OpenWork app (Electron/React) + optional remote worker runtime
- **Packaging:** Binary distribution, no container orchestration needed

This mode bypasses the **Den controller** entirely—the desktop client manages its own state and tool executions.

---

## Self-Hosted Single-Organization Deployment

Teams wanting full data control without multi-tenancy complexity can deploy the **Den control plane** on their own infrastructure. According to the [`packaging/helm/openwork-ee/README.md`](https://github.com/different-ai/openwork/blob/main/packaging/helm/openwork-ee/README.md), the Helm chart defaults to `single_org` mode.

### Core Components

| Component | Purpose | Source Location |
|-----------|---------|-----------------|
| **Den web** | Sign-in UI and web dashboard | `packages/den/web/` |
| **Den controller** | Authentication, provisioning, API (`/api/den`) | `packages/den/api/` |
| **OpenWork app** | Desktop client | `packages/app/` |
| **Inference service** (optional) | Model proxying and rate limiting | `packages/inference/` |

### Helm Installation

```bash
helm upgrade --install openwork-ee \
  oci://ghcr.io/different-ai/charts/openwork-ee \
  --version 0.17.1 \
  -f values.prod.yaml

```

### Minimal Production Values

```yaml

# values.prod.yaml

image:
  tag: "0.17.1"
config:
  tenancy:
    mode: "single_org"
    singleOrgName: "Acme"
    singleOrgSlug: "acme"
    ownerEmails: "admin@acme.com"
    allowPublicSignup: "false"
  public:
    webOrigin: "https://openwork.acme.local"
    apiOrigin: "https://api.openwork.acme.local"
secret:
  values:
    databaseUrl: "mysql://openwork:securepw@mysql.internal:3306/openwork_den?sslmode=verify-full"
    betterAuthSecret: "32-character-random-secret"
    denDbEncryptionKey: "another-32-character-secret"

```

The **Helm chart manages secrets via Kubernetes `Opaque` Secrets**—either generating them or referencing existing ones containing `DATABASE_URL`, `BETTER_AUTH_SECRET`, and `DEN_DB_ENCRYPTION_KEY`.

---

## Self-Hosted Multi-Organization (Enterprise) Deployment

For large enterprises requiring **SSO integration, audit logs, and strict tenant isolation**, the same Helm chart supports multi-tenant mode with additional configuration.

### Enterprise-Only Components

- **Better Auth** with SAML/OIDC providers
- **Sentry** or **OpenTelemetry** observability backends
- **GitHub connector** for repository imports

### Enabling Multi-Org Mode

Override the default tenancy configuration in your Helm values:

```yaml
config:
  tenancy:
    mode: "multi_org"

```

The `config.tenancy.mode` parameter **must be explicitly set to `multi_org`**—the chart does not infer this from other settings.

---

## Private-Network Deployment

Organizations operating inside VPNs or on-premise networks without public internet access require **custom certificate authority (CA) support** and relaxed URL validation.

### Required Configuration

```bash
helm upgrade --install openwork-ee \
  ./packaging/helm/openwork-ee \
  --set config.public.allowPrivateMcpUrls=1

```

### Key Settings

| Setting | Purpose | Environment Variable |
|---------|---------|----------------------|
| `DEN_ALLOW_PRIVATE_MCP_URLS=1` | Permit internal MCP server URLs | Pod env var |
| Custom CA bundle | Trust internal TLS certificates | `NODE_EXTRA_CA_CERTS` |

The chart mounts your CA bundle and injects `NODE_EXTRA_CA_CERTS` into all containers automatically. See the *Private network deployment* guide linked from [`packaging/helm/openwork-ee/README.md`](https://github.com/different-ai/openwork/blob/main/packaging/helm/openwork-ee/README.md) for complete instructions.

---

## Air-Gapped Deployment

**Zero-outbound-internet environments** require full image mirroring and disabled external dependencies.

### Air-Gapped Requirements

- Fully mirrored container images in internal registry
- Internal artifact PVCs for build caches
- Disabled external password-breach screening (Have I Been Pwned API)
- Custom CA for all inter-service TLS

**Documentation:** `packages/docs/start-here/air-gapped-deployment.mdx`

---

## Hosted Workers on Render (Zero-Infrastructure)

Teams preferring managed infrastructure can use **OpenWork Cloud** for the web UI while running workers on Render.

### Architecture

| Layer | Provider | Components |
|-------|----------|------------|
| Control plane | OpenWork Cloud | Den web, Den controller |
| Compute | Render | Den controller workers, inference runtime |

### Local Development

```bash
pnpm dev:den:seed-demo

# Login: alex@acme.test / OpenWorkDemo123!

```

Point the desktop client at the hosted URLs—no local Kubernetes or Docker required.

---

## Local Development with Docker Compose

Before any production deployment, validate configurations using the **Den local stack**.

```bash
docker compose -p openwork-dev \
  -f packaging/docker/docker-compose.den-dev.yml \
  up --build

```

The compose file ([`packaging/docker/docker-compose.den-dev.yml`](https://github.com/different-ai/openwork/blob/main/packaging/docker/docker-compose.den-dev.yml)) includes:

- MySQL database
- Den API (controller)
- Den Web (UI)
- Optional OpenTelemetry collector

---

## Observability Configuration

Both Helm and Docker deployments support **OpenTelemetry or Sentry** backends.

### OpenTelemetry Helm Values

```yaml
observability:
  backend: otel
  serviceNames:
    denApi: openwork-den-api
    denWeb: openwork-den-web
  otel:
    endpoint: "http://otel-collector.observability.svc.cluster.local:4318"
    tracesSampler: parentbased_always_on
    headers:
      existingSecret: openwork-otel-headers
      key: OTEL_EXPORTER_OTLP_HEADERS

```

Set `observability.backend=sentry` to use Sentry instead.

---

## Summary

- **Desktop-only** needs no infrastructure—download and run
- **Single-org self-hosted** uses Helm chart defaults with `mode: single_org`
- **Multi-org enterprise** requires explicit `mode: multi_org` plus Better Auth/SAML
- **Private-network** deployments need `allowPrivateMcpUrls=1` and custom CA bundles
- **Air-gapped** requires full image mirroring and disabled external APIs
- **Hosted/Render** eliminates infrastructure management entirely
- All strategies share the same service mesh: desktop → Den web → Den controller (`/api/den`)

---

## Frequently Asked Questions

### What is the default tenancy mode in the OpenWork Helm chart?

The `openwork-ee` Helm chart defaults to `single_org` mode. You must explicitly override `config.tenancy.mode` to `multi_org` for enterprise multi-tenant deployments, as documented in `packaging/helm/openwork-ee/README.md#tenancy-mode`.

### How do I deploy OpenWork without any Kubernetes infrastructure?

Use the **desktop-only** strategy by downloading the Electron client from openworklabs.com, or choose the **hosted workers (Render)** strategy where OpenWork Cloud manages the control plane and you only configure Render workers.

### Where are secrets stored in a Kubernetes deployment?

Secrets are managed via Kubernetes `Opaque` Secrets referenced by the Helm chart. Required keys are `DATABASE_URL`, `BETTER_AUTH_SECRET`, and `DEN_DB_ENCRYPTION_KEY`. The chart can create these automatically or reference an existing secret via `secret.existingSecretName`.

### How do I enable observability in production?

Set `observability.backend` to `otel` or `sentry` in your Helm values. For OpenTelemetry, specify the collector endpoint and sampler configuration. The Docker development stack includes an OTEL collector for local validation.

### What file contains the complete Helm chart documentation?

[`packaging/helm/openwork-ee/README.md`](https://github.com/different-ai/openwork/blob/main/packaging/helm/openwork-ee/README.md) contains the authoritative reference for installation, values, secrets, custom CA certificates, and observability configuration.