Device Management Toolkit — Cloud Deployment

Looking for the legacy MPS-based deployment? See the v2 branch.

Disclaimer: Production releases are tagged and listed under 'Releases'. Other check-ins should be considered in-development and should not be used in production.

This repo contains deployment artifacts for Device Management Toolkit (Console) — the unified service replacing the historical MPS+RPS split. Console can be deployed in either a cloud or on-prem environment.

For detailed documentation, see the docs site.

Clone

git clone --recursive https://github.com/device-management-toolkit/cloud-deployment.git

The --recursive flag is required — this repo uses git submodules under services/.

Get Started

Local development with Docker Compose

There are two auth modes. Simple (the default) uses Console's built-in login. Keycloak swaps in a bundled Keycloak OIDC IdP (a stand-in for a 3rd-party IdP like Auth0 / Entra). The Keycloak stack is layered on top of the simple one via docker-compose.keycloak.yml.

Linux / macOS / WSL:

make up            # simple console auth (default)
make up-keycloak   # bundled Keycloak OIDC

Windows (PowerShell):

./scripts/bootstrap-env.ps1
# simple (default):
docker compose up -d --build
# keycloak:
docker compose -f docker-compose.yml -f docker-compose.keycloak.yml up -d --build

The bootstrap step (run automatically by make, or ./scripts/bootstrap-env.ps1 on Windows) creates .env from .env.template if missing, auto-detects your host's LAN IP for MPS_COMMON_NAME (so AMT devices reach this host over CIRA and TLS certs match — getting this wrong is a common gotcha), and fills any blank password fields with random values. Override MPS_COMMON_NAME in .env if you have a DNS name or want a different IP.

make down stops either mode. make clean (or docker compose -f docker-compose.yml -f docker-compose.keycloak.yml down -v; Remove-Item -Recurse generated) also wipes volumes and generated material — switching modes is cleanest after a make clean. In Keycloak mode an init container generates a per-deployment TLS cert + RSA token-signing keypair into ./generated/ (gitignored) before Keycloak starts.

Once the stack is up, make opens your browser at https://<MPS_COMMON_NAME>/ (the app is served over HTTPS via Kong with a self-signed cert, so accept the browser warning). On Windows, open that URL manually after docker compose up.

If you'd rather configure manually: copy .env.template to .env, fill the fields yourself, then run the compose command for your mode.

Login

Simple mode (default)

Console handles authentication itself. Log in at https://<MPS_COMMON_NAME>/ (accept the self-signed cert warning) with standalone / the value of AUTH_ADMIN_PASSWORD in .env (auto-generated by bootstrap).

Keycloak mode

Authentication is handled by the bundled Keycloak instance. On first start it imports a realm export and creates a console realm.

Two distinct logins, two different realms — don't mix them up:

Where	URL	Realm	Credentials
Console / sample-web-ui (the app)	https://<MPS_COMMON_NAME>/	console	standalone / value of CONSOLE_USER_PASSWORD in .env
Keycloak admin console	https://<MPS_COMMON_NAME>:8443/admin/	master	admin / value of KEYCLOAK_ADMIN_PASSWORD in .env

The admin user only exists in the master realm. Using it on the app's login screen will fail — the app sends you to the console realm, which only contains the standalone user.

Keycloak mode serves two self-signed certs — accept both, or login will hang:

1. https://<MPS_COMMON_NAME>:8443/ — Keycloak. Login redirects here and the SPA makes silent token fetches to it; until the cert is accepted those fail and the page appears to stall. make up-keycloak opens this URL first for that reason.
2. https://<MPS_COMMON_NAME>/ — the app, via Kong.

Each cert is unique per clone. Console's server-side OIDC discovery skips TLS verification (AUTH_TLS_SKIP_VERIFY=true) so it doesn't need the cert trusted; the browser still does. Don't reuse this skip-verify behavior in production.

Cloud (Azure) deployment

Or via Azure CLI:

az group create --name dmt-console --location eastus
az deployment group create --resource-group dmt-console --template-file azureDeploy.json

Migration to Bicep is planned. The current ARM template is retained for compatibility.

Cloud Kubernetes (AKS, GKE, EKS) with Helm

helm install console ./charts -f ./charts/values-cloud.yaml

Enables headless Console + sample-web-ui + kong API gateway + mps-router.

On-prem Kubernetes with Helm

helm install console ./charts -f ./charts/values-onprem.yaml

Console with built-in UI; no kong, no sample-web-ui, no mps-router.

On-prem native (macOS, Linux, Windows)

See installers/ for native installer status.

Repository Layout

• services/ — git submodules (Console, RPS, sample-web-ui, mps-router).
• azureDeploy.json — Azure ARM deployment.
• charts/ — Helm chart with values-cloud.yaml and values-onprem.yaml overlays.
• installers/ — Console native installers (on-prem).
• docker-compose.yml — local-dev / cloud-style stack.

Branches

• main (this branch) — v3 (Console-era), active development.
• v2 — legacy MPS-era, minimum feature/maintenance only.

Additional Resources

• Documentation site
• Open a new issue
• Security policy
• Discord