Skip to main content
Organization install links help members install the standard OpenWork desktop and connect it to the correct Den organization. Den does not build a customer-specific installer or wrap the installer in a ZIP. The implementation and security details remain in the repository’s Organization Install Links guide.

​
Delivery matrix

​
Mounted artifact behavior

When OPENWORK_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. The expected filename depends on the deployment. A self-hosted Den (single-org mode, the default) serves the enterprise distribution; the hosted multi-org OpenWork Cloud serves the cloud distribution. Install links never serve the public openwork-<platform>-<version> filenames. The version in the filename is the resolved release tag without a leading v:
  • openwork-enterprise-mac-arm64-<version>.dmg
  • openwork-enterprise-mac-x64-<version>.dmg
  • openwork-enterprise-win-x64-<version>.exe
  • openwork-enterprise-linux-x86_64-<version>.AppImage
  • openwork-enterprise-linux-arm64-<version>.AppImage
On hosted OpenWork Cloud the prefix is openwork-cloud- instead of openwork-enterprise-. A mounted file with any other name is ignored and the request falls through to the GitHub redirect. 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.

​
Which version is installed

Den resolves one release version per download request, in this order:
  1. If the organization’s allowedDesktopVersions desktop policy is set, the highest listed version wins. This is the way to pin a fleet or to opt into a newer desktop than the Den itself.
  2. Otherwise, if OPENWORK_INSTALLER_RELEASE_TAG is set on Den API, that tag wins.
  3. Otherwise, a self-hosted Den running a published release image installs its own release version (the version reported by GET /health on Den API), so a self-hosted control plane never hands out a desktop newer than itself by default. Hosted OpenWork Cloud, and Den builds without a release version, install the latest published stable release instead.
Mounted artifacts must match the resolved version. When you rely on the default in step 3, place the files for the Den release you run; when you set a policy or an override, place the files for that version. 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. 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 write desktop-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.