Maester Maester Cloud

Self-hosting

The Sponsor plan runs the exact same stack the hosted service deploys — in your Azure subscription, under your governance. Your subscription includes read access to the private repository (the GitHub invitation arrives via Polar after checkout) and monthly updates while subscribed.

What you'll deploy

One resource group containing a Static Web App (Standard) for the portal, a consumption Function App for the API and processing, and a storage account for reports, results, and history. Idle cost is effectively the SWA Standard base fee (~$9/month) — compute and storage cost pennies until you use them.

Prerequisites

  • An Azure subscription where you can create resource groups, and the az CLI logged in.
  • A Microsoft Entra admin to register the sign-in app (same as hosted).
  • Your GitHub account connected via Polar so you can clone jozrahq/maester-cloud.

Deploy

git clone https://github.com/jozrahq/maester-cloud
cd maester-cloud

az group create --name maester-cloud --location australiaeast
az deployment group create \
  --resource-group maester-cloud \
  --template-file infra/customer-stack/main.bicep \
  --parameters subdomain=maester customerId=self-hosted \
    entraTenantId=<your-tenant-id> entraClientId=<your-app-client-id>

Create the sign-in app first using any of the three methods from Getting started step 3 — the PowerShell script is in the repo at scripts on the website, or follow the Entra-portal steps with your own portal URL as the SPA redirect URI.

Custom domain

Add your own domain on the Static Web App (Custom domains → Add): create the CNAME it shows you in your DNS, and Azure issues and renews the certificate automatically (free managed certs). Use that URL as your app's redirect URI.

Onboard and send

From here the experience matches hosted: sign in, follow the in-portal checklist, and send your first report with the uploader script (point -ApiBaseUrl at your portal URL).

Staying current

Releases are published in the private repository with notes; updating is re-running the same az deployment group create from the new tag — deployments are idempotent, and your data (storage account) is untouched by stack updates. Release announcements go to sponsors by email.