Copilot Managed Runtime is the name Microsoft put on the thing Code Apps was growing into. It went into public preview on 25 September 2026, and my first reaction on launch day was three things: another app type, another CLI, another admin center? Copilot Managed Runtime is the third name installment for an existing Power Platform product, and each name change is connected to one another. This post walks the chain from Code Apps (Vibe coded apps) through Managed Apps to Copilot Managed Runtime, so that the product line makes sense in context. At least trying to make more sense out of it whether you build apps, make them, or have to govern them.
I have been in the private preview since July and on the weekly Office Hours calls with the product team. Everything below is based on public Microsoft Learn docs for the public preview features made available 26.09.2026 and from some additional context details from the product team and other members of the private preview forum during its development.
The problem that started it all
Low-code developers have been building in PowerFx for years. The trouble was that almost nobody wanted to specialize in it. Ordinary users did not have the technical background to learn PowerFx (most of the targeted users did not know what a function was), and the people who did have technical background saw no reason to spend their time on a language that only works in one product based off of Excel. Learning the platform cost more than it was worth to build, so the low-code promise for Canvas apps ended up close to useless for the new “low-code developers” it was aimed at. Also which still got a pretty bad wrap from old school Dynamics/MDA developers (mostly because they were comfortable in their own niche field and not very adaptful, in my experience).
At the same time, the demands on the apps kept growing. The people who ask for a feature usually want more than a canvas app offers out of the box. Every extra feature pushes the build further into more technical territory, and sooner or later you need a developer to design the solution. At that point, learning PowerFx properly stops being worth the time, since it also almost always added an extra overhead.
Then AI came along, and building complex apps suddenly looked cheap, because a low-code developer could prompt a solution faster than anyone could code one. The new problem was governance: hundreds of generated apps with nobody in control of where they run, what they connect to, or who can use them. Fixing that, while giving prompt-first builders an isolated platform of their own, is what the rest of this story is about. Code Apps was the first attempt.
1. Evolved from Code Apps
Code Apps itself is generally available today. Code Apps was Microsoft’s first step to the governance problem as mentioned earlier above. Instead of making developers learn or memorize PowerFx, it lets a developer create a normal Vite app and hand it to Power Platform, which then applies the same policies it applies to a canvas app.
I have built Code Apps for clients and in workshops this year, and I wrote a whole series on running a Power Apps code app on any Vite framework. Code Apps has no repo-connection on the platform, no server for business rules, and no lightweight data store. Each has a workaround today. Each of these missing features is also why Managed Apps exists. To begin with I will try to explain each of the limits that Code Apps has today, in the sections below.
Limit one: the platform never sees/has your source
pa app push uploads a compiled app to Power Platform, which hosts that build, while your source code is locally on your device or in your own Git repo managed by your org. The Learn documentation still informs us that code apps don’t support Power Platform Git integration.
In parallell; the Power Apps vibe experience creates a code app for non-technical users. A developer can export that app and edit it in VS Code and redeploy it to keep working on it. The catch is that the redeployed app is a new app with no link to the original plan. The non-technical user cannot pick it up again in vibe and the developer cannot push changes back. Without source code access on the platform there is no way for the two to work on the same app.
Limit two: there is no real server-side
Power Platform hosts a code app, but the app itself runs in the user’s browser, on the user’s device, with the user’s own permissions. Take an approval app. The rule that only a manager may approve is enforced by code running on the requester’s own device, and nothing on Microsoft’s side checks it again, unless you make an effort to involve a backend service to be triggered. A developer who knows what they are doing can skip that check and call the connector on their own, but with business users – nothing guarantees that they apply the rule – vibe coding it.
Today you build the rule/logic as a Power Automate flow, a Dataverse plug-in or an Azure Function, because all of them run on Microsoft’s servers where the user cannot directly edit or access them. Doing so protects the logic, at a price: you are now building, deploying and governing two separate things for one app, and paying two bills for it. The product team knows this pattern as “canvas app plus Azure Function”, and the middle tier in the new runtime is being developed to end it: the server-side rule deploys together with the app, in the same sandbox, under the same governance. No more separate service context hell in future solutions.
So… the plan was…
Microsoft became aware of the limits (and freedom) over time. In June 2026 the Code Apps roadmap listed a Git repo for every app and server-side logic on a managed host as July previews. Neither arrived in Code Apps. Both are part of what Managed Apps covers, and what Copilot Managed Runtime offers today.
2. Introduced Managed Apps
In July 2026 Microsoft opened a private preview called Microsoft Managed Apps. The definition from the first call was short: a full-stack app built on open standards with hosting, lifecycle, security and governance included. In plain terms it is Code Apps v2 that as we all know now, got rebranded as Microsoft Copilot Managed Runtime (Managed Apps).
What Managed Apps adds to Code Apps
- A Git repo for every app (Preview). Every app gets a repository, whether it was created in Copilot Cowork, Copilot Studio or with the CLI, and with the CLI you can bring your own GitHub repo instead. Builds and deploys come from commits. A business user can start an app in Copilot Studio and a developer can clone the repo and continue it in VS Code. After that, Copilot Studio shows “This app isn’t available to edit right now” for the app, so the business user cannot take it back. The product team says that editing a Copilot Managed Runtime app in Copilot Studio again after a developer has changed it is planned, without a specific date yet.
- Server-side logic inside the app (Private). TypeScript that runs on the server deploys together with the app and inherits the same policies. The approval rule from above runs where the user cannot reach it and there is no Azure Function on the side. The preview name is Managed Functions.
- A built-in database (Private). Every app gets a small data store with no provisioning. Whoever can use the app can use the data. It is meant for the five-person list and has a path to SharePoint or Dataverse or SQL when the app outgrows it. The preview name is Managed Apps Data.
Governance
The product team was clear that Managed Apps is not a Power Platform product, which in practice means the app is a Microsoft 365 asset in the Microsoft 365 admin center next to agents (Preview) while the rules that govern it stay the Power Platform rules you already run: environments, environment groups, routing, DLP, advanced connector policies, Conditional Access and sharing limits. If your tenant already has routing rules and environment groups, Copilot Managed Runtime respects them and adds its own rules on top.
Cost and licensing plans?…
Licensing users is either through Power Apps Premium or Copilot Credits (API-call rate usage) for each user, never Premium plus credits for the same person.
- User with Power Apps Premium: running the app consumes no Copilot Credits. Premium covers all app operations. Two exceptions: the app calls a service that is billed separately regardless of license (Work IQ APIs is the example Learn gives), or the user exceeds the ordinary Power Apps Premium API request limits.
- User without Premium: the admin must have set up a spending policy for the service “Managed applications” with Copilot Credits. The rate is 0.1 credit per API call plus an amount per app launch (the launch rate is not published). Without credits the user gets a warning, then a block after 20 operations or five minutes.
- Building and development costs: Building with the CLI or SDK costs nothing. Building in Copilot Studio (think vibe.powerapps.com v2.0) or Cowork consumes Copilot Credits (Copilot Studio per environment in the Power Platform admin center, Cowork per user). Runtime credits are managed per user in the Microsoft 365 admin center, no matter where the app was built.
- The developer is a user too. Licensing/rates are enforced when you run
ms app devlocally, not only on the live URL, that means if the developer is missing Power Apps Premium license, then Copilot Credits per API call is applied. - Data access is separate. Sharing the app does not grant access to the data. The user still needs their own permissions on the SharePoint list or the Dataverse table, and Dataverse tables require a license that includes Dataverse access (Premium does).
3. Rename alignment: Copilot Managed Runtime
On 25 September 2026 Microsoft made the product public under a new name: Copilot Managed Runtime. The product is the same one as Managed Apps in the private preview. The CLI, the SDK and the portal did not change, and the npm packages are still called @microsoft/managed-apps-cli and @microsoft/managed-apps.
The name says Copilot because the places where people build these apps are Copilot products, and because the meter runs in Copilot Credits. The product team’s own advice on the call before launch was to see it as a name change and not read more into it. That matches what I see in the docs.
The different ways to start developing apps
A business user opens Copilot Cowork and describes the app in chat (Preview, Frontier program only). A maker opens Copilot Studio, describes the app or starts from data, refines it in a preview and publishes (Preview). The product team calls this the successor to the Power Apps vibe experience and App Builder. A developer uses the ms CLI and the SDK from any editor (Preview). A partner tool such as Lovable publishes through the same SDK, so an app made in Lovable runs inside your tenant like everything else (Preview). Whichever tool builds the app, the data comes through the same connectors, under the same admin policy, with each user signed in as themselves. Copilot Code was announced on launch day as a new surface in the Copilot app for widgets and dashboards and small hosted apps. It comes to Frontier tenants first (Preview).
If you never named a data source, the generated app keeps its records in the browser. It looks finished, but nobody else sees the data. Connect a real source before you share it.
Whichever way the app was made, it runs in Copilot Managed Runtime, inherits the tenant’s default governance policy, appears in the Microsoft 365 admin center inventory, and users open it from managedapps.cloud.microsoft. David Blyth’s launch blog put it in one sentence: central governance should not require centralized creation, still firm in their belief of continous co-op between business users and developers to create the business app that they want.
Code Apps and Copilot Managed Runtime, side by side
| Code Apps | Copilot Managed Runtime | |
|---|---|---|
| What you deploy | Compiled app via pa app push | Git commits, and the platform builds from the repo |
| Source of truth | Your local project or GitHub/GitLab connected on your local dev-machine | The repository (platform-managed or your own GitHub/GitLab) |
| Server-side logic | Separated from Code App: flows, Dataverse plug-ins or Azure Functions | Future plan: Middle tier in the same sandbox |
| App-scoped data | None. Dataverse, SharePoint or SQL through connectors | Future plan: Built-in database, plus the same connectors |
| Who builds | Developers CLI, Power Apps vibe | Cowork, Copilot Studio, CLI/SDK, Lovable, Copilot Code, Developers CLI |
| Admin home | Power Platform admin center | Microsoft 365 admin center, Apps node |
| ALM | Dataverse solutions and pipelines (Code App artifact) | Future plans: Git-based stages (Preview) artifacts moved available in MAC |
| Licensing | Power Apps Premium or pay-as-you-go | Copilot Credits per launch and per API call, or Power Apps Premium |
| Status | Generally available | Public preview / Private preview |
What this means if you build on Power Platform
The product team has confirmed that Code Apps will be kept, with its own backlog and its own Office Hours. It will not get the built-in database or the middle tier, and the two SDKs will not merge (Roadmap). Microsoft wants Code Apps to be a strict subset of what runs in Copilot Managed Runtime, with a migration “easy button” planned for after the runtime reaches general availability (Roadmap).
If I were you, I’d map the features like this:
- Makers: if you used the vibe experience, watch the Copilot Studio Apps path, which is the same idea with a Git repo a developer can pick up as the output.
- Developers: the
msCLI feels like the Code Apps npm CLI with Git bolted on, so try the quickstart and then decide whether the middle tier and built-in data are worth waiting for. - Admins: decide whether the Copilot Studio switch stays on and which environment groups get the CLI rule, before the first app shows up in your inventory.
Status today
Copilot Managed Runtime is in public preview and Microsoft are continuing the planned pipeline they left off as usual after announcement. The middle tier (server-side logic inside the app), the built-in database and the code-app migration path are not part of the public preview yet. Repositories must be on GitHub.com or GitHub Enterprise Cloud, since Learn says GitLab, Azure DevOps and GitHub Enterprise Server are not supported. Dataverse is reached through the connector, without the Dataverse actions and functions a Code App can add with pa app add dataverse-api, and Copilot Studio apps build only in the maker’s earliest personal developer environment, which the product team has confirmed.
So far, Copilot Managed Runtime has given me the repo on the platform that Code Apps never had. The server-side logic inside the app and the small data store are the two pieces I am waiting for, and both are still private preview. Microsoft has also opened up for builders with access to Lovable to build Copilot Managed Runtime apps. Whether it becomes the default for internal apps depends on the credit pricing. I will keep reporting as those pieces become publicly available.
If you run into bugs or other challenges with Copilot Managed Runtime, or want to share how you use it, leave a comment below or get in touch.
Where to go next
Start with the Copilot Managed Runtime overview on Microsoft Learn: https://learn.microsoft.com/microsoft-365/managed-apps/ . The SDK overview at https://learn.microsoft.com/microsoft-365/managed-apps/developer/ has the licensing table, and the admin overview at https://learn.microsoft.com/microsoft-365/admin/manage/apps/ has the creation-path defaults.
Leave a Reply