feat(enterprise): serve desktop releases without public egress

[benjaminshafii]

What changed

This makes Mac and Windows desktop delivery work without required public release egress:

• Den can serve a versioned, read-only desktop release repository from OPENWORK_DESKTOP_RELEASES_DIR/<version>/.
• /v1/app-version now advertises deployment-owned installer and updater URLs.
• Windows ARM64 is first-class end to end: Den, the installer, architecture correction, and the updater consume win-arm64 when published. Existing x64-only mounts remain valid and omit the optional ARM64 URL.
• Den serves exact-version release assets with GET, HEAD, immutable caching, and byte-range support.
• Mounted updater manifests are accepted only when they reference relative, allow-listed files that exist on the same mount; symlinks, traversal, incomplete releases, and public pointer URLs fail closed.
• The generic installer asks Den for the supported version and platform URL instead of constructing a GitHub URL.
• The installed desktop preserves the Den API URL in its bootstrap, uses Den for architecture correction and stable updates, and uses Electron networking for enterprise trust stores.
• macOS alpha updates fail closed unless an operator explicitly configures OPENWORK_DESKTOP_ALPHA_UPDATE_FEED_URL.
• Generic installer GitHub fallback now requires OPENWORK_INSTALLER_RELEASE_FALLBACK_ENABLED=true.
• Helm values, volume mounts, and the operator guide cover private release delivery. Existing Linux release behavior is intentionally unchanged and Linux installer work remains out of scope.

Root cause

The generic installer and Electron updater each independently constructed upstream GitHub release URLs. Den could serve a stamped organization installer, but it did not own the signed desktop release or updater feed, and its generic-installer cache fetched GitHub implicitly when a local artifact was absent. That made a fully private install/update path impossible.

Operator rollout

For zero-egress delivery, mount:

• generic wrappers at OPENWORK_INSTALLER_ARTIFACTS_DIR
• the unmodified signed desktop release at OPENWORK_DESKTOP_RELEASES_DIR/<latestAppVersion>/

The desktop release directory must include latest-mac.yml, latest.yml, both Mac DMGs and updater ZIPs, the Windows x64 EXE, and all referenced blockmaps. To support Windows ARM64, also mount openwork-win-arm64-<version>.exe and reference it from latest.yml; Den advertises ARM64 only when both are present. Keep public fallback disabled.

Connected deployments can opt in explicitly with OPENWORK_INSTALLER_RELEASE_FALLBACK_ENABLED=true and/or OPENWORK_DESKTOP_RELEASES_PUBLIC_BASE_URL.

Integration with #2633

This PR remains based directly on dev and is independently mergeable. It was audited against #2633's overlapping installer, environment, artifact-resolver, test, documentation, Docker, and Helm edits.

The intended combined behavior is:

1. Outer organization wrapper (feat(installer): ship durable signed Windows packages #2633): signed, byte-stable Windows x64/ARM64 ZIPs with sidecar configuration. Resolution order is mounted wrapper -> cache -> OPENWORK_INSTALLER_RELEASE_BASE_URL -> GitHub only when OPENWORK_INSTALLER_ALLOW_GITHUB_FALLBACK=true.
2. Inner desktop release (feat(enterprise): serve desktop releases without public egress #2631): the wrapper asks Den's /v1/app-version for its architecture-specific URL. Den serves a mounted versioned release or an explicitly configured desktop mirror; the installer and stable updater never invent a GitHub URL.

When resolving the textual conflicts, keep #2633's durable ZIP/signing flow and canonical outer-wrapper environment names, while keeping #2631's OPENWORK_DESKTOP_RELEASES_* settings, Den release routes, manifest validation, range serving, and Den-owned release URL API. In release-asset.ts, retain #2631's caller-supplied Den URL and #2633's x64/ARM64 filename support—do not restore the old hardcoded GitHub URL. Documentation and Helm changes are additive: describe both the outer private wrapper base and the inner private desktop/update repository.

Validation

All feature validation ran in Daytona sandboxes.

Linux build/test sandbox

• pnpm --filter @openwork/installer test — 29 passed, 0 failed.
• pnpm --filter @openwork/desktop test — 46 passed, 0 failed, 1 macOS-only skip.
• pnpm --filter @openwork/desktop typecheck:electron — passed.
• pnpm --filter @openwork-ee/den-api exec bun test test/desktop-releases.test.ts test/installer-artifacts.test.ts — 12 passed, 0 failed.
• pnpm --filter @openwork-ee/den-api exec tsc --noEmit — passed.
• Route-policy exception registration check — 1 passed. The full baseline policy test still reports 12 unrelated uncovered routes already present on origin/dev; this PR does not broaden those exceptions.
• helm lint packaging/helm/openwork-ee — passed.
• Helm render with both private artifact mounts plus the alpha-feed override — passed and contained all expected env/volume wiring.
• Bun cross-compilation produced PE32+ Windows x64 and ARM64 installers plus a Mach-O arm64 Mac installer.

Daytona Windows x64

The compiled Windows installer ran in headless dry-run mode from an isolated C:\ow\airgapped-eval directory. It:

1. queried the Den-only /v1/app-version endpoint,
2. selected Den's openwork-win-x64-0.17.19.exe,
3. verified the private artifact with HEAD,
4. wrote an isolated bootstrap with requireSignin=true, and
5. contained no GitHub URL.

Result: WINDOWS_DRY_RUN_PASS.

Fraimz

pnpm fraimz --flow airgapped-desktop-delivery — Passed, 6/6 frames plus voiceover coverage.

The report proves mounted-byte preservation, Den GET/HEAD/range delivery, disabled public wrapper fallback, x64 and ARM64 installer resolution through Den, sign-in-required bootstrap, internal stable updater feed, alpha fail-closed behavior, and the approved-host allowlist.

• Daytona report: fraimz.html
• Sandbox path: /workspace/evals/results/2026-07-10T03-25-39-952Z/fraimz.html

The Daytona preview URL is temporary; the full assertions are also summarized in the follow-up PR comment.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
openwork-app	Ready	Preview, Comment	Jul 10, 2026 4:40am
openwork-den	Ready	Preview, Comment	Jul 10, 2026 4:40am
openwork-den-worker-proxy	Ready	Preview, Comment	Jul 10, 2026 4:40am
openwork-landing	Ready	Preview, Comment, Open in v0	Jul 10, 2026 4:40am

[benjaminshafii]

Fraimz proof — airgapped-desktop-delivery

Verdict: Passed on commit 09e7546a4.

Command: pnpm fraimz --flow airgapped-desktop-delivery
Result: 1 passed, 0 failed, 0 skipped; 6/6 approved voiceover frames plus coverage.

Temporary rendered report: fraimz.html
Daytona path: /workspace/evals/results/2026-07-10T03-25-39-952Z/fraimz.html

Frame-by-frame assertions

1. Mounted signed release repository

   • Den published metadata plus GET and HEAD routes.
   • Den advertised exact-version x64 and ARM64 Windows artifact URLs.
   • Both mounted architecture artifacts were served from Den.
   • Mounted x64 bytes remained SHA-256-identical.
   • Byte-range delivery returned 206, the correct Content-Range, and the requested bytes.

2. Organization setup package with GitHub blocked

   • The mounted Windows generic wrapper was returned.
   • Disabled fallback made zero calls to the injected public fetcher.

3. Installer follows Den metadata

   • x64 and ARM64 installers selected their architecture-specific Den URLs.
   • Both downloaded the expected mounted bytes.
   • Neither architecture invented or contacted a GitHub URL.

4. First launch is organization-gated

   • Bootstrap required sign-in.
   • Both web and API configuration pointed to the organization deployment.
   • Bootstrap contained no public release host.

5. Internal stable update feed

   • Windows stable feed resolved from Den metadata.
   • All observed update URLs were on the internal Den host.
   • An unconfigured macOS alpha feed failed closed instead of using GitHub.

6. Approved-host network boundary

   • Every observed setup/version/artifact/first-launch/update host was allow-listed.
   • GitHub was absent from all observed requests.

Backward-compatibility assertions

• A legacy x64-only mounted repository remains valid.
• Den omits win-arm64 when the ARM64 executable or updater-manifest entry is absent.
• Den advertises win-arm64 only when both are mounted.
• An external release base advertises both architectures as an explicit operator contract.
• Daytona cross-compilation produced a PE32+ ARM64 installer (bun-windows-aarch64-v1.3.14).

Separate Windows Daytona execution

A Bun-cross-compiled PE32+ x64 installer was downloaded into the existing Windows Daytona VM under isolated C:\ow\airgapped-eval state and run with --headless --dry-run.

Observable output:

OpenWork Installer — Organization
[check-version] Deployment supports OpenWork 0.17.19.
[done] Dry run ok: openwork-win-x64-0.17.19.exe available
WINDOWS_DRY_RUN_PASS ... requireSignin=True

The Den fixture log recorded exactly the expected Windows requests:

GET /v1/app-version 200
HEAD /v1/desktop-releases/0.17.19/openwork-win-x64-0.17.19.exe 200

This is installer-resolution/bootstrap proof, not a claim that a production-signed desktop EXE was installed in the VM; signing is intentionally owned by #2633.

[benjaminshafii]

Terminology cleanup validation

Validated commit a31726202.

• pnpm --filter @openwork/install-config build — passed
• pnpm --filter @openwork-ee/utils build — passed
• pnpm --filter @openwork/installer test — 29 passed
• pnpm --filter @openwork/desktop test — 46 passed, 0 failed, 1 platform skip
• pnpm --filter @openwork-ee/den-api exec bun test test/desktop-releases.test.ts — 7 passed
• node --check evals/flows/airgapped-desktop-delivery.flow.mjs — passed
• Fraimz — Incomplete for this terminology-only rerun because no running Den/Electron CDP environment is available in this workspace