Skip to main content
“Air-gapped” can mean several different things in OpenWork planning. Use these terms precisely so the network design, installer path, and feature expectations stay aligned.

​
Deployment terms

If desktops have internet access and Den is private, start with Private network deployment. If you need to inventory domains, use Outbound network access. If TLS inspection or private roots are involved, use Certificate trust and proxies.

​
Full isolation checklist

Use this checklist only when the goal is a fully isolated OpenWork deployment, not just private Den or internal installer delivery.

​
Deployment artifacts

  • Mirror the GHCR Helm chart into an internal OCI registry.
  • Mirror all enabled images into an internal registry, including openwork-den-api, openwork-den-web, and openwork-inference if inference is enabled.
  • Configure Helm image repositories and chart installation to use the internal registry. The public ghcr.io path is only needed when you are not mirroring the chart and images.

​
Installer artifacts

  • Mount the standard release installer files into Den and set OPENWORK_INSTALLER_ARTIFACTS_DIR to that mount path.
  • Use OPENWORK_INSTALLER_RELEASE_TAG to select the expected standard filenames. The version inside each filename is the tag without a leading v.
  • Use OPENWORK_INSTALLER_RELEASE_REPO only for the GitHub redirect path when mounted artifacts are not present; it is not an internal artifact registry override.
  • Mount the same read-only installer artifact PVC across every Den API replica. Den streams the mounted file; it does not fetch, cache, rewrap, or ZIP installer bytes.
See Installer delivery for the exact filenames and delivery matrix.

​
Desktop runtime dependencies

  • Point OPENCODE_MODELS_URL at an internal mirror of the model catalog. The default catalog is https://models.openworklabs.com/.
  • The packaged desktop can start the UI-control MCP with npx -y openwork-ui-mcp. In a fully isolated environment, provide an internal npm registry or npm mirror that can serve that package to npx. OpenWork does not currently document a separate OpenWork-specific registry override for this package; use standard npm configuration for the runtime account.
  • Disable, mirror, or manage desktop updates and GitHub release assets through your internal release process. Do not assume a built-in updater mirror setting unless it has been verified for the desktop release you ship.

​
Feature dependencies

  • Optional providers, MCP servers, OAuth identity providers, and email services are unavailable unless they are internally reachable and approved. Examples include Google Workspace, Microsoft 365, GitHub plugin import, OpenRouter/OpenAI, Slack/Notion/Linear/Sentry/Stripe MCP presets, SMTP, and Resend.
  • If you enable the GitHub connector, approve the exact GitHub API/webhook paths or mirror the workflow it needs. Start with the GitHub connector Helm guide.
  • If you enable internal MCP URLs, review the private-network SSRF policy in Private network deployment. Enabling private MCP URLs is a trust decision, not an air-gap requirement.

​
Security and diagnostics

  • Install private roots and proxy configuration for the correct trust surface: desktop Electron/Chromium, spawned local runtimes, Den containers, and MySQL TLS do not all use the same store. See Certificate trust and proxies.
  • Use Network diagnostics to separate desktop DNS/TLS/proxy issues from Den outbound checks.
  • Helm already disables the external breached-password lookup by default for isolated self-hosted installs. Enable it only if your security team approves the external Have I Been Pwned range API path.

​
What full isolation does not include automatically

Mounting installer artifacts is useful, but it only solves installer delivery. It does not mirror npm, model catalogs, provider APIs, GitHub plugin contents, OAuth metadata, email delivery, diagnostics, desktop updates, or certificate trust. Treat each enabled feature as a separate dependency review.