# Deployment Strategies for OpenWork: Private Network, Air-Gapped, and Local Development

> Explore OpenWork deployment strategies: local Docker Compose, private network Helm charts, and air-gapped installations. Run OpenWork anywhere from your laptop to a data center.

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

---

**OpenWork supports three primary deployment strategies—a Docker Compose stack for local development, a Helm chart for private-network enterprise environments, and a fully air-gapped installation for complete network isolation—allowing teams to run the platform anywhere from a laptop to a hardened data center.**

The different-ai/openwork repository provides infrastructure-as-code templates for each deployment strategy for OpenWork, ensuring the same Den API, Den Web, and MySQL core components run consistently across development and production environments.

## Private-Network Deployment Strategy

The private-network strategy deploys OpenWork inside a corporate LAN or VPN while allowing laptops to access the public internet for installers and model catalogs. This semi-air-gapped approach uses the **OpenWork EE Helm Chart** to orchestrate the Den API and Den Web services on Kubernetes.

According to `packages/docs/start-here/private-network-deployment.mdx`, this configuration exposes Den Web as a reverse-proxy for Den API (`/api/den`), allowing the desktop client to communicate through a single origin. The Helm chart documentation in [`packaging/helm/openwork-ee/README.md`](https://github.com/different-ai/openwork/blob/main/packaging/helm/openwork-ee/README.md) specifies that you must configure tenancy mode and public origins before installation.

Configure your deployment with a [`values.private-network.yaml`](https://github.com/different-ai/openwork/blob/main/values.private-network.yaml) file:

```yaml
config:
  tenancy:
    mode: "single_org"
    singleOrgName: "Acme"
    singleOrgSlug: "acme"
    ownerEmails: "admin@acme.com"
  public:
    webOrigin: "https://openwork.acme.internal"
    apiOrigin: "https://api.openwork.acme.internal"
    mcpResourceUrl: "https://api.openwork.acme.internal/mcp"
    desktopDenBaseUrl: "https://openwork.acme.internal"
    corsOrigins: "https://openwork.acme.internal,https://api.openwork.acme.internal"
    betterAuthTrustedOrigins: "https://openwork.acme.internal"
secret:
  values:
    databaseUrl: "mysql://openwork:REPLACE_ME@mysql.internal:3306/openwork_den"
    betterAuthSecret: "REPLACE_WITH_32+_CHARS"
    denDbEncryptionKey: "REPLACE_WITH_32+_CHARS"

```

Install the release using the OCI registry:

```bash
helm upgrade --install openwork-ee \
  oci://ghcr.io/different-ai/charts/openwork-ee \
  --version <release-tag> \
  -f values.private-network.yaml

```

Replace `<release-tag>` with the desired version tag from the GitHub Container Registry.

## Fully Air-Gapped Deployment Strategy

For environments prohibiting all outbound internet traffic, the fully air-gapped strategy requires mirroring every dependency—including the Helm chart, container images, installer artifacts, and model catalogs—into internal infrastructure. This strategy uses the same Helm chart as the private-network deployment but with extensive configuration for internal registries and mounted artifacts.

As documented in `packages/docs/start-here/air-gapped-deployment.mdx`, you must mirror the container images (`openwork-den-api`, `openwork-den-web`, `openwork-inference`) into an internal OCI registry. The desktop client requires internal mirrors for the model catalog (`OPENCODE_MODELS_URL`) and npm registry to fetch `npx openwork-ui-mcp`.

Mount installer artifacts internally by configuring the `installerArtifacts` block and setting `OPENWORK_INSTALLER_ARTIFACTS_DIR` to the mount path. For private certificate authorities, enable the `customCa` configuration in your Helm values.

Create a [`values.air-gapped.yaml`](https://github.com/different-ai/openwork/blob/main/values.air-gapped.yaml) file:

```yaml
config:
  tenancy:
    mode: "single_org"
    singleOrgName: "Acme"
    singleOrgSlug: "acme"
    ownerEmails: "admin@acme.com"
  public:
    webOrigin: "https://openwork.acme.internal"
    apiOrigin: "https://api.openwork.acme.internal"
    mcpResourceUrl: "https://api.openwork.acme.internal/mcp"
    desktopDenBaseUrl: "https://openwork.acme.internal"
    corsOrigins: "https://openwork.acme.internal"
    betterAuthTrustedOrigins: "https://openwork.acme.internal"
    installerReleaseTag: "v0.18.0"
    installerReleaseRepo: "different-ai/openwork"
    installerArtifacts:
      enabled: true
      existingClaim: openwork-desktop-artifacts
      mountPath: /var/lib/openwork/installer-artifacts
secret:
  create: false
customCa:
  enabled: true
  existingSecret: openwork-ca
  key: ca.crt

```

Deploy from your internal registry:

```bash
helm upgrade --install openwork-ee \
  oci://registry.internal/different-ai/openwork-ee \
  -f values.air-gapped.yaml

```

Ensure all external URLs resolve to internal equivalents, or the desktop client will fail during authentication or model loading.

## Local Development Deployment Strategy

Developers can spin up a complete OpenWork stack using Docker Compose for rapid iteration and testing. The [`packaging/docker/docker-compose.den-dev.yml`](https://github.com/different-ai/openwork/blob/main/packaging/docker/docker-compose.den-dev.yml) file defines services for Den API, Den Web, and MySQL with sensible defaults for workstation environments.

This strategy exposes three ports on the host:
- `8788` for the Den API
- `3005` for the Den Web interface
- `3306` for the MySQL database

Start the development stack:

```bash
docker compose -f packaging/docker/docker-compose.den-dev.yml up -d

```

Verify service health:

```bash
curl http://localhost:3005/api/health
curl http://localhost:8788/health

```

Both endpoints should return HTTP 200 when services are ready. You can override default configuration using environment variables or a `.env` file, such as setting `DEN_ORG_MODE=single_org` to automatically create the default organization.

## Summary

OpenWork provides three distinct deployment strategies to match your security requirements and infrastructure constraints:

- **Private-Network Deployment**: Use the Helm chart with [`values.private-network.yaml`](https://github.com/different-ai/openwork/blob/main/values.private-network.yaml) when laptops need internet access but services must remain inside the corporate VPN.
- **Fully Air-Gapped Deployment**: Mirror all artifacts and use the Helm chart with [`values.air-gapped.yaml`](https://github.com/different-ai/openwork/blob/main/values.air-gapped.yaml) for environments with zero outbound internet connectivity.
- **Local Development**: Use [`docker-compose.den-dev.yml`](https://github.com/different-ai/openwork/blob/main/docker-compose.den-dev.yml) for disposable developer environments on local workstations.

All strategies share the same core services, enabling seamless promotion from local development to production Kubernetes clusters.

## Frequently Asked Questions

### What hardware resources are required to deploy OpenWork?

The Helm chart and Docker Compose files do not specify strict resource limits, but the Den API and Den Web services typically require standard Kubernetes worker nodes with at least 2 CPU cores and 4GB RAM per replica. The optional Inference service requires GPU resources if running local models. MySQL-compatible databases should run on dedicated infrastructure with persistent storage for production workloads.

### Can I deploy OpenWork without using Kubernetes?

Yes, while the production deployment strategies rely on the OpenWork EE Helm chart for Kubernetes, you can adapt the container images (`openwork-den-api`, `openwork-den-web`) to run on any container orchestrator or directly on Docker. The [`packaging/docker/docker-compose.den-dev.yml`](https://github.com/different-ai/openwork/blob/main/packaging/docker/docker-compose.den-dev.yml) file demonstrates the container relationships and environment variables required to run the platform without Kubernetes, though this is recommended only for development or small-scale deployments.

### How do I handle SSL certificates in an air-gapped OpenWork deployment?

For air-gapped environments using private certificate authorities, configure the `customCa` section in your Helm values to mount an internal CA certificate. Set `customCa.enabled` to `true`, specify the `existingSecret` containing your `ca.crt`, and ensure the secret is available in the same namespace. This allows the Den API and Web services to trust internal TLS certificates for database connections and internal registries.

### What database does OpenWork require?

OpenWork requires a MySQL-compatible database to store persistent data for organizations, policies, and MCP connections. The `databaseUrl` secret value must use the MySQL connection format (e.g., `mysql://user:pass@host:3306/database`). The Docker Compose development stack includes a MySQL container, while production deployments should connect to a managed MySQL service or dedicated database cluster for high availability.