Rayfin Preview Brings a Fabric Backend to AI-Built Apps
Microsoft introduced Rayfin and Fabric Apps preview so AI-built apps can deploy with Fabric database, authentication, GraphQL, and governance.
- What happened: Microsoft used Build 2026 to introduce the
RayfinSDK and CLI alongside Fabric Apps preview.- Rayfin turns an app described in code or natural language into a Fabric-backed application with database, authentication, GraphQL API, storage, and access policies.
- Developer impact: AI coding agents now have a documented path from generated app code to
npx rayfin updeployment inside a Fabric tenant. - Why it matters: The product question moves from whether an agent can scaffold an app to where that app's data, identity, schema, and permissions live.
- Watch: Fabric capacity, SSO limits, destructive schema changes, and pricing documents are the operational checks teams need before production.
- Fabric Apps is still in preview, and Microsoft Learn ties deployed apps to Fabric workspaces, Fabric capacity, and Microsoft Entra ID based Fabric SSO.
Microsoft's Rayfin announcement at Build 2026 targets a gap that appears after an AI coding agent has produced a plausible app. Microsoft Build Live described Rayfin on June 2, 2026 as an "open-source SDK and CLI" that can create a typed, governed backend when an app is described in code or natural language. The generated backend includes a database, authentication, storage, and access policies. The deployment target is Microsoft Fabric, where Microsoft says the app inherits the tenant's security, governance, and compliance controls and stores app data in OneLake.
That positioning places Rayfin beside the rest of Microsoft's Build 2026 agent stack: the GitHub Copilot app, Microsoft Foundry, Agent 365, Windows 365 for Agents, and related developer tools. If the Copilot app coordinates worktree-based sessions, GitHub Issues, pull requests, CI, review, and merge flows, Rayfin is aimed at the next boundary. It handles the point where the generated app needs real organizational data, identity, row-level authorization, an API, a deployment URL, and a capacity model.

Microsoft Learn makes the product shape more concrete. The Fabric Apps documentation, last updated on June 2, 2026, says Fabric Apps generates a database schema and GraphQL endpoint from a TypeScript data model. It also provides built-in authentication, static hosting, Fabric SSO, and SQL database in Fabric as one development workflow. The documented setup path starts with npm create @microsoft/rayfin@latest and deploys to a Fabric workspace with npx rayfin up.
| Rayfin or Fabric Apps piece | Role in the official docs | What changes for AI app development |
|---|---|---|
| TypeScript data model | Defines data structures with decorators such as @entity(), @text(), and @uuid() | Keeps the data contract for an agent-generated app inside reviewable code |
| Generated backend | Creates database schema, GraphQL endpoints, and authorization rules | Reduces the manual work of wiring API and database layers after UI generation |
| Fabric SSO | Uses Fabric brokered authentication backed by Microsoft Entra ID after deployment | Connects internal app login and authorization to the organization's identity boundary |
| Rayfin CLI | Documents up, --dry-run, status, db apply, and staticapp deploy | Splits generated changes into preview, deployment, status, schema, and static-app steps |
Rayfin's most direct competitors are not just no-code app builders. Replit, Vercel, Supabase, Firebase, and AWS Amplify already give teams fast deployment paths, managed storage, generated APIs, and backend primitives. Microsoft's different bet is the Fabric tenant. Build Live also mentioned a Replit partnership: an app can be created through natural language in Replit, then deployed with Rayfin so the app, data, and services remain inside the organization's Fabric tenant.
That makes Rayfin less a generic backend generator and more an enterprise placement tool for AI-built applications. Many teams have evaluated coding agents by asking how well they write code, repair tests, or generate screens. Rayfin shifts the question toward the execution and data boundary: if an agent creates an internal approval app, where does the SQL schema live, who signs in, which rows can a user read, how is the GraphQL endpoint exposed, and which tenant controls the resulting artifact?
The endpoint shape is already documented. Microsoft Learn says a deployed Fabric App has a single endpoint. /api/graphql handles the data API, while /auth handles authentication services. That detail matters to platform teams because app-generation speed is only one part of approval. Endpoint routing, tenant membership, capacity consumption, identity rules, and data residency often decide whether a generated app can leave a demo environment.
Authentication is also narrower than a general app platform. Microsoft Learn says deployed Fabric Apps use Fabric SSO, or Microsoft Entra ID single sign-on through Fabric brokered authentication. The same documentation says other authentication providers are not supported for deployed applications. That is a strong fit for internal apps in organizations that already run Microsoft 365 and Fabric. It is a constraint for customer-facing products, partner portals, or tools that need non-Microsoft identity providers.
The documented workflow is CLI-first. npm create @microsoft/rayfin@latest -- my-app --workspace <workspacename> creates the app template, Rayfin configuration, and frontend source code. Existing projects can use npx rayfin init .. npx rayfin up deploys the backend to Fabric and starts the frontend development server. Before deployment, npx rayfin up --dry-run previews the change. For status checks, Microsoft documents npx rayfin up status and a --json option.
The schema commands are where teams should slow down. Microsoft Learn says a data-model-only change can be applied with npx rayfin up db apply. It also warns that destructive changes, including column type changes and column deletion, can fail, and that --force may introduce a breaking change. In an AI-agent workflow, a schema migration is not just a prompt result. It is an operational change that can affect stored data and running users.
Fabric Apps also inherits Fabric's capacity model. The overview says a workspace must have Fabric capacity assigned and that Fabric Apps services consume capacity units. On June 4, 2026, a post in r/MicrosoftFabric asked about Rayfin cost calculation and licensing. The useful signal is not the thread's answer. It is that early adopters immediately searched for capacity planning and cost documentation, before there is much field experience with Rayfin itself.
That pattern repeats across AI app platforms. Coding agents reduce the time needed to create an app shell, but the moment the app uses database, authentication, storage, GraphQL, hosting, and governance, cost surfaces multiply. For Rayfin, teams should read pricing through Fabric capacity, SQL database in Fabric, app services, workspace permissions, and operational accounts rather than through a single simple app-builder price. Clear price and quota documentation will influence whether Fabric customers keep Rayfin in proofs of concept or approve production usage.
Rayfin's product message is therefore closer to "put AI-built apps inside the enterprise data boundary" than "let AI write the backend for you." Microsoft says app data lands in OneLake after deployment. For organizations already using Fabric, that sentence is substantial. It means app data can remain inside an existing analytics and governance environment instead of being copied into another SaaS backend or exported through an ad hoc integration.
For teams outside Fabric, that same sentence reads differently. Rayfin is not only another way to host a generated app. It is a Microsoft data-platform decision. The application backend, identity system, storage location, governance model, and capacity planning all pull toward Fabric. That may be exactly what a Microsoft-heavy enterprise wants. It may be too much platform commitment for a startup or a team already standardized on another backend.
The GitHub Copilot app connection explains why Microsoft showed Rayfin in the same Build media context. Build Live described the Copilot app as a way to start from GitHub Issues, pull requests, and parallel sessions, with each session isolated in a git worktree. If those sessions produce a reviewed app change and move through CI and merge, Rayfin becomes the path for turning the app into a Fabric App. The workflow is not just agent writes code. It is agent produces a change, humans review it, CI validates it, and Rayfin deploys the backend and frontend into the tenant.
That combination changes the developer's job. If the frontend draft, data model draft, GraphQL endpoint, authentication wiring, and deployment target can be generated in one path, the developer's highest-risk work moves to review. The expensive mistake is not a poorly styled button. It is an overbroad access policy, a destructive schema update, an endpoint exposed to the wrong users, or a migration that loses data. Rayfin's emphasis on a governed backend makes sense only if those artifacts are inspectable before they are applied.
Fabric Apps permissions add another approval layer. Microsoft Learn describes item permissions such as Run and interact, Edit, and Reshare. Those are ordinary enterprise controls, but they become more visible in an AI-generated-app workflow. When an agent creates a useful internal tool, a platform owner still has to decide who can run it, who can edit it, who can share it, which workspace owns it, and which Fabric capacity pays for it.
Rayfin is still a preview product. Microsoft Learn says a Fabric tenant administrator must enable the Fabric Apps workload. Deployment authentication is centered on Fabric SSO. Apps are bound to Fabric workspaces and capacity. The most realistic first use case is not a public customer app. It is an internal dashboard, approval helper, or workflow tool for a team already operating inside Fabric.
For engineering teams, the first proof of concept should be small and boring. Pick an internal tool where the data already belongs in Fabric. Keep the data model under rayfin/data as a TypeScript class. Run npx rayfin up --dry-run before deployment. Review the generated GraphQL API, database schema, and permission model in the same pull request as the agent-generated code. Attach the Entra ID group, Fabric item permission, and SQL schema change to the review so the generated artifact and the human-approved operational change are visible together.
There are three unresolved checks to track as Rayfin matures. First, the open-source claim needs the ordinary details enterprises expect: repository location, package history, license, changelog, issue process, and security policy. Second, pricing and quota documents need to be precise enough for capacity planning. Third, schema and access-policy review need a clear user experience when an AI agent edits the data model or authorization boundary.
Rayfin is interesting because backend generation itself is not new. The 2026 difference is that AI agents are now creating apps close enough to business data, identity systems, analytics platforms, and deployment policies that backend placement becomes the buying criterion. Microsoft is trying to close that loop inside Fabric. Other platforms will answer with their own deployment, database, authentication, and governance combinations.
The practical comparison for developers is not model name against model name. It is data location, permission granularity, schema migration behavior, authentication flexibility, preview-to-production path, and cost clarity. Rayfin gives Microsoft a strong answer for Fabric-centered organizations. It also makes the dependency clear: faster scaffolding comes with Fabric's workspace, capacity, SSO, and governance conditions.