Skip to content
sprigsprigsprig

Requirements & preflight

Azure

Section titled “Azure”
  • A subscription for sprig (a dedicated subscription is recommended: cleanest budget and policy boundary).
  • The installing operator holds Owner on that subscription.
  • Region supporting Azure Container Apps (most do; westeurope is the default).
  • Choose a non-overlapping IPv4 CIDR for the managed platform VNet before installation. New installs use 10.240.0.0/24 unless you pass --platform-vnet-cidr <cidr>.
  • The installer creates vnet-<prefix>-platform and its dedicated Container Apps delegated subnet. The environment remains externally reachable: this option does not create peering, private endpoints, NAT Gateway, NSGs, firewall rules, private DNS, or an internal-only environment.
  • No container registry needs to be prepared. The installer creates or reuses one deterministic Sprig-owned Basic registry in the platform resource group. It is dedicated to signed Sprig release images so its access policy and lifecycle do not depend on an unrelated workload. The admin account and anonymous pull are disabled.
  • Azure Container Registry Basic has a fixed daily base charge, about USD 5 per month at pilot scale, with 10 GiB included, plus any usage-based storage and network charges.
  • The registry’s public network endpoint stays enabled so it can receive authenticated image imports when the selected image source requires them. This does not enable anonymous pull.
  • A domain you can delegate a subdomain of (apps.<domain>) to Azure DNS: every published app lives on it.

Entra

Section titled “Entra”

The tenant has Entra ID P1 or P2. Sprig assigns app roles through security groups, which requires one of these license tiers. The fixed sprig-users and sprig-operators groups have no separate per-group charge.

The installing operator can, at install time:

  • create app registrations,
  • create the Sprig security groups and manage their direct membership (for example, through the Groups Administrator role when ordinary group creation is restricted),
  • grant admin consent / Graph app roles (Global Administrator, or Privileged Role Administrator + Application Administrator).

This is needed once. Day-to-day operation requires only the Ops app role that the installer assigns, plus (for the connector/onboarding steps) rights to manage sprig-users and sprig-operators group membership and grant tenant-wide admin consent. See Claude connector & admin consent.

Operator v2 workstation

Section titled “Operator v2 workstation”
  • The standalone sprig operator binary. It does not require an Azure CLI login, Python, Node.js, npm, a source checkout, or release manifest/bundle files.
  • For an interactive install, an interactive terminal and SPRIG_CLIENT_ID set to the operator’s registered public client ID. Run sprig init to create the active context and complete device-code sign-in.
  • For unattended use, configure one explicit non-interactive identity: GitHub OIDC in a job that can request an OIDC token, or SPRIG_AUTH_MODE=environment with AZURE_CLIENT_ID and AZURE_CLIENT_SECRET. A service-principal sprig init also needs --tenant <tenant-id> because its tenant cannot be discovered interactively.
  • Required release inputs are supplied through environment variables: SPRIG_PLATFORM_VERSION, SPRIG_PLATFORM_IMAGE, SPRIG_OTEL_COLLECTOR_IMAGE, SPRIG_RELEASE_USERNAME, and SPRIG_RELEASE_PASSWORD. Sprig supplies one stable-release credential for the customer organization through the agreed secret-delivery channel. The customer does not create or manage the upstream registry token. When Sprig rotates the credential, replace both release credential variables before the next install or upgrade. The operator validates all required release inputs and reports any missing value before it contacts Azure.
  • A domain-serving install also needs a digest-pinned SPRIG_GATEWAY_IMAGE. Without it, the base platform, DNS zone, and Acmebot can install, but the domain remains unserved until the gateway image is set and sprig infra upgrade completes its identity, authentication, certificate-binding, and admin UI work.
  • Fabric sources need SPRIG_FABRIC_CONNECTOR_IMAGE, SPRIG_FABRIC_CONNECTOR_AUDIENCE, and SPRIG_FABRIC_CONNECTOR_APP_ID, all three or none. Setting only some of them is refused before the install starts. Without any of them the install succeeds and everything else works, but a registered Fabric source reports its schema as unavailable. See Expose an existing database.

Data side

Section titled “Data side”
  • The primary case: an existing Azure SQL Database with Entra sign-in that Ops exposes read-only via register_source/expose_entities, table by table, from a Claude conversation. See Expose an existing database.
  • A source can also be a Fabric Warehouse or lakehouse SQL analytics endpoint (fabric-dw), read-only, registered the same way; or a Power BI / Fabric semantic model (fabric-semantic), registered by workspace and item GUID; its schema (tables and measures) is discovered as the signed-in Ops user once the listed grants are applied and the Fabric inputs were supplied at install time, and its tables and measures expose read-only, always queried under each viewer’s own identity so the model’s row-level security applies.
  • Apps that need their own storage get a provisioned Azure SQL serverless database on the platform’s own logical server. Nothing for Ops to prepare ahead of time.
  • For a db-delegated source (Azure SQL Database, and the default), builders and viewers only ever see data their own identity already has permission to read at the source (on-behalf-of, all the way down); sprig grants itself no standing data access there. A source can instead be registered gateway-enforced (today, only fabric-dw): a service identity reads it and sprig filters per viewer above the database, an explicit, audited exception rather than a default. Semantic models (fabric-semantic) are always db-delegated: a service identity would bypass the model’s own row-level security, so no service-identity mode exists for them. See Data access for the full picture.

Preflight checklist

Section titled “Preflight checklist”
  1. Subscription chosen and quota sane. There are no per-builder or per-app resource groups under the gateway architecture: the platform footprint is fixed regardless of headcount.
  2. Operator can run sprig init with an interactive device-code sign-in or configured non-interactive identity, and can reach Azure and Graph.
  3. Decided who holds the Ops role (source exposure, share approvals): one or more named people.
  4. An apps domain chosen and DNS delegation planned (apps.<domain> → Azure DNS), and a non-overlapping platform CIDR chosen if 10.240.0.0/24 is unsuitable.
  5. Budget amount and alert email chosen.
  6. Read Exact permissions granted. Your security team will ask.
  7. Include the dedicated Basic release registry in the platform cost and teardown review.
  8. Confirm the platform VNet CIDR does not overlap the source VNet or any of its peers.