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

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 specifies that you must configure tenancy mode and public origins before installation.

Configure your deployment with a values.private-network.yaml file:

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:

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 file:

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:

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 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:

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

Verify service health:

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 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 for environments with zero outbound internet connectivity.
• Local Development: Use 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 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.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}