Deployment & readiness

This guide is for operators of the repository's self-hosted Fleet deployment. That deployment includes the Beam service, a durable operation ledger, and an isolated Fleet engine with its own data services. Optional device response adds NanoMDM or signed Windows workers. The dashboard database and Fleet database have separate responsibilities.

For Beam-hosted workspaces, use Setup to request activation and follow the configured Enrollment & installers flow. Hosted infrastructure changes are being coordinated separately; do not create a second service stack from this self-hosted guide for a hosted workspace.

Isolate each workspace

Use a separate Fleet instance, engine hostname, and data volumes per Beam workspace. Do not split a shared engine by Fleet group and present those groups as tenant isolation. Assign stable HTTPS names for the Beam service API and the public enrollment engine.

Pin tested container images by digest and review provider compatibility. A Beam license does not include Fleet Premium. Schema initialization and upgrades are explicit maintenance operations; application startup does not perform them automatically.

Connect the dashboard

For a static deployment, set a server-only dashboard mapping:

[
  {
    "orgId": "BEAM_WORKSPACE_ID",
    "serviceUrl": "https://mdm-api.example.com",
    "signingKey": "REPLACE_WITH_AT_LEAST_64_RANDOM_CHARACTERS"
  }
]

Store this as BEAM_MDM_SERVICE_CONNECTIONS. Configure the matching workspace and signing key in the MDM service's BEAM_MDM_TENANTS, along with its Fleet origin, automation token, and enrollment configuration. Never expose these values to the browser.

Hosted provisioning uses the provisioning worker's signed service integration and operator-configured connection. It checks configured provider readiness; it does not provision Fleet infrastructure or replace platform enrollment setup.

Plan network access

Administrative /v1/ requests require signed dashboard principals and should be restricted to the dashboard network where possible. Provisioned Windows workers need /device-response/; NanoMDM needs /apple-response/ callbacks. Devices reach the engine's HTTPS enrollment endpoints without dashboard sign-in. Apply proxy limits and keep credential headers out of logs.

Preserve state and identity

Back up Fleet data, encryption keys, Apple/Windows identities, installer manifests, and the Beam operation ledger. The ledger requires durable Redis with AOF, appendfsync always, and noeviction. Monitor persistence failures, disk, and memory. Loss of request IDs can compromise duplicate protection.

Readiness and liveness are different: the service's /health only proves the process responds. Monitor provider connectivity, durable storage, identity expiry, and representative device check-ins separately.

Activate in stages

Keep highImpactEnabled false while validating cross-workspace access, enrollment, installer trust, profile delivery/removal, and offline behavior. Test response channels and recovery on disposable hardware before enabling lock or wipe. Verify backups by restoring into an isolated environment.

The complete operator assets live in deploy/mdm, apps/mdm-service, and the repository deployment guides. Production credentials, signing, Redis durability, provider integration, and physical device outcomes must be validated for the deployed environment.