What is sprig?

Your people already vibe-code apps in Claude: dashboards, calculators, internal tools. The building works. What doesn’t work is everything after: the app can’t reach corporate data, it gets passed around as an HTML file over email or a share, there’s no authentication, no audit trail, and nobody knows what’s running where.

sprig is a deploy target for vibe-coded apps, installed inside your own Azure tenant. It gives every builder a governed sandbox and gives Claude a set of skills so that one sentence (“share this solution”) turns an artifact into a running, Entra-secured internal app.

What you get

A governed publish path. One always-warm gateway serves every app at <app>.apps.<yourdomain>: no per-builder Azure resource group, no per-app Azure resource. Builders reach it through a Claude connector (claude.ai) or Claude Code; they need zero Azure permissions or tooling.
Locked down by default. Every published app is gated by its own pair of Entra groups (viewers/builders), checked by the gateway on every request: only the owner can open it until Ops approves a share request.
Live corporate data, no copies. Apps read data from a source Ops has exposed (an Azure SQL Database, or a Fabric Warehouse / lakehouse source) at query time, with the viewer’s identity all the way to the database for the default, db-delegated sources; a smaller set of sources (currently Fabric only) are gateway-enforced instead, an audited exception where a service identity reads and sprig filters per viewer. Sharing an app never shares data access. Viewers see exactly what their own permissions allow.
Ops stays in control without running a ticket queue. Install once, expose data sources under governance, approve share requests, all from a Claude conversation. Budgets, an audit trail, and DBA-facing grant scripts are part of the flow.

What sprig is not

Not a hosting service. Nothing runs on our infrastructure. sprig is software you install into your subscription; we never hold credentials to your tenant.
Not a code generator. Claude builds the apps. sprig is the boundary between “Claude made a thing” and “the company runs a thing”.
Not a data warehouse. sprig never stores your corporate data. Every query streams through the gateway to the database and back, in-flight only, under the caller’s own identity (on-behalf-of) for db-delegated sources, or a scoped, audited service identity for the gateway-enforced exception - the gateway is a proxy in the request path, not a copy of your data.
Not a general PaaS. The sandbox is deliberately narrow: one gateway, group-based access, no arbitrary compute. That narrowness is what keeps Ops involvement minimal.

Where it runs

Azure today (Container Apps, Data API builder, Entra ID, Azure SQL). The platform is self-contained in one subscription: one platform resource group holding the gateway, the shared data layer, and their supporting infrastructure, not one resource group per builder.

Next: How it works