Install

Everything is driven by the sprig CLI at the distribution root. The aggregate command runs the full sequence with a review gate:

az login
./sprig azure install <subscriptionId> -o <ops-upn> -e <budget-email>

That performs, in order:

1. Preview (--what-if) — prints every resource the install would create, plus the planned Entra objects and role grants. Nothing is changed. The command pauses for your confirmation.
2. Install — resource layer via Bicep (platform resource group, storage + tables, Function App, managed identity, monitoring, budget), then the Entra layer (the two platform app registrations, the Graph role grant, the Ops role assignment to <ops-upn>).
3. Deploy — builds the platform code and zip-deploys it to the Function App.
4. Smoke test — verifies resources, Entra wiring, the Graph grant, and the live health endpoint.

The install is idempotent: re-running updates in place, never duplicates. It writes sprig-install.json — a non-secret descriptor (endpoint, client ids, tenant) that builder machines use for one-command configuration. Distribute it freely; it contains no credentials.

Individual steps

Prefer granular control? Each stage is its own script:

cd infra
./install.sh -s <subscriptionId> --what-if     # review only
./install.sh -s <subscriptionId> -o <ops-upn>  # resource + Entra layers
./deploy-platform.sh                            # build + deploy platform code
./smoke.sh                                      # post-install verification

First-contact notes

• Entra propagation can lag a few seconds after app-registration creation; the installer is safe to simply re-run if a Graph step 404s.
• The first hit on the health endpoint after deployment can take ~30 s (consumption cold start).
• If your region rejects the Linux consumption plan, pick another with -l <region>.

Next: Onboard builders.