Delivery matrix
Mounted artifact behavior
WhenOPENWORK_INSTALLER_ARTIFACTS_DIR points at a mounted directory and the expected file exists, Den streams that file directly. It does not fetch from GitHub, cache on first request, rewrap, ZIP, or hold the whole installer in memory.
OPENWORK_INSTALLER_RELEASE_TAG selects the expected release version. The standard filenames use the release tag without a leading v:
openwork-mac-arm64-<version>.dmgopenwork-mac-x64-<version>.dmgopenwork-win-x64-<version>.exeopenwork-linux-x86_64-<version>.AppImageopenwork-linux-arm64-<version>.AppImage
OPENWORK_INSTALLER_RELEASE_REPO controls the GitHub redirect path when Den does not find a mounted artifact. It is not an internal artifact registry setting.
For multi-replica Den API deployments, mount the same read-only PVC at the same path on every replica. Connection grants are stored in MySQL, so preview and acceptance can land on different replicas safely, but installer bytes must be equally visible to each replica.
One-origin steady state and install-link exchange
For normal signed-in desktop traffic, prefer one desktop-facing Den web origin. The desktop derives API and MCP paths through that origin’s/api/den proxy.
If DEN_API_PUBLIC_URL is configured as a separate API origin, the one-time Open OpenWork install-link exchange must also reach that API origin. External MCP clients that use the published MCP URL must reach it too. This does not mean every steady-state desktop request needs both origins in the single-origin topology.
Managed fleets: enterprise binary + MDM
This page covers install-link delivery of the standard installer. Managed fleets typically skip the install-link handoff entirely: deploy the OpenWork Enterprise binary through MDM and writedesktop-bootstrap.json during provisioning so the first launch already targets your Den server. See Enterprise desktop deployment for the artifact names, bootstrap file reference, and what MDM does not need to push.