Overview
End-to-end deployment guide for the Arbium platform.
Two teams run the rollout in parallel. Cloud Ops stands up the backend on AWS, Google Cloud, or Azure and exposes it at an HTTPS URL you control. IT registers an app in your Entra tenant and ships Roots to managed devices. The threads converge twice: IT’s Entra values feed Cloud Ops’s Helm step, and Cloud Ops’s handoff table — on Windows, just the server address — feeds IT’s device rollout.
How to read this
Section titled “How to read this”Both teams start at their own Step 1.
- Cloud Ops follows the five-step installation guide, choosing AWS, Google Cloud, or Azure only for the foundation step.
- IT follows the Entra ID, Intune and Claude setup walkthroughs, which fill every Entra field, Intune setting and command with your values, and the Updates walkthrough for each new release. The Intune one needs the server address from Cloud Ops Step 5.
Every page opens with the same header — owner, rough time, what you’ll finish with, what you need first — and ends with what to do next.
What you’ll find
Section titled “What you’ll find”Cloud Ops stands up the Arbium backend, then hands the server address (and, for macOS, the upload endpoint and publishable key) to IT:
- Shared flow: prerequisites, provider selection, Helm configuration, verification, upgrades, and handoff.
- Provider foundations: EKS/Aurora on AWS, GKE/Cloud SQL on Google Cloud, or AKS/PostgreSQL Flexible Server on Azure.
IT registers the app in Entra, deploys Roots with Intune and connects Claude, through four interactive guides:
- Entra ID setup walkthrough — app registration, sign-in, security groups, provisioning
- Intune rollout walkthrough — the Intune app, rules, smoke test, rollout
- Updates walkthrough — moving managed devices to a new release
- Claude setup walkthrough — the Arbium Agents connector and plugin for your Claude organization
The auth model in one paragraph
Section titled “The auth model in one paragraph”Devices authenticate with a Microsoft Entra ID token, verified by the backend’s
standard OIDC integration — no Arbium-specific identity provider. On Windows,
Roots signs in silently with the person’s own work account through
the Windows sign-in broker; the deployment publishes which directory and
application to use, so nothing identity-related is configured on the device,
and attribution comes from the signed-in account. The macOS agent mints an
app-only token via OAuth 2.0 client credentials, with per-user attribution from
Open Directory’s AltSecurityIdentities. This is the same pattern Microsoft
Defender for Endpoint and CrowdStrike Falcon use.