Signed installers

Understand workspace packages, integrity checks, and the release process behind enrollment downloads.

On this page

Beam distributes workspace-specific Mac and Windows desktop installers from Enrollment & installers. The packages contain enrollment configuration, so treat their distribution as an administrative operation. They are distinct from the public Agent CLI npm package.

Download a published package

Sign in with an owner or administrator account, open the setup page, and confirm the workspace ID and platform. Download the Mac package or Windows MSI that your operator has published. Verify the expected publisher before installation and test on a representative endpoint.

If an artifact is unavailable, ask the operator to check the installer manifest and read-only release mount. The dashboard does not build installers on demand. It also does not contain signing keys.

Build and publish a release

Operators use the repository's platform-specific scripts:

PlatformBuild scriptRequired trust checks
macOSapps/mdm-service/scripts/build-macos.shDeveloper ID Installer signing, notarization, stapling, and Gatekeeper acceptance
Windowsapps/mdm-service/scripts/build-windows.ps1Authenticode signing, timestamping, and publisher verification

Build with a reviewed, pinned fleetctl release on a dedicated signing host. Supply enrollment configuration and signing credentials from your secret manager. Enrollment secrets can appear in packaging process arguments; protect builder access and avoid command transcripts containing them.

After signing, the operator publishes the artifact with the manifest tool:

Code
bun apps/mdm-service/scripts/installer-manifest.ts /absolute/signed-package.pkg /absolute/release-output WORKSPACE_ID VERSION

Use an MSI path for Windows. The tool verifies the copied artifact's platform signature, refuses to overwrite an existing version, and updates the manifest atomically. Serialize publication per workspace; merge both platform entries when separate build hosts publish a release.

How download integrity works

The service verifies the artifact size and SHA-256 hash against the manifest before streaming the same open file. A modified or mismatched package is refused. Mount the complete workspace release directory read-only and ensure the service user can read it.

A matching hash establishes consistency with the published manifest. Endpoint signature checks and successful installation remain separate verification steps.

Update an existing rollout

Publish a new version, retain the previous release under your retention policy, and validate the new installer on a test device. Keep manifests with deployment records so the operator can identify exactly what was distributed. Updating package files does not automatically upgrade every enrolled endpoint.

Explore the docs