Copilot Managed Runtime (Managed Apps)

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 questions: another app type, another CLI, another admin center? After a day with the Learn docs the answer is simpler than the name. Copilot Managed Runtime is the third name for one idea, and each name marks a problem the previous version could not solve. This post walks the chain from Code Apps through Managed Apps to Copilot Managed Runtime, so the product makes sense in context. It should work 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.

Table of Contents

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 server

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. A user who knows what they are doing can skip that check and call the connector on their own, so nothing guarantees the rule holds.

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 exists to end it: the server-side rule deploys together with the app, in the same sandbox, under the same governance.

So… the plan was…

Microsoft became aware of the limits 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?…

A user with a Power Apps Premium plan runs a managed app under that plan and consumes nothing extra (Preview). Everyone else consumes Copilot Credits per app launch and per API call, and the admin sets the spending policy for that in the Microsoft 365 admin center. Building the app is billed separately and depends on where you build: Cowork bills the creator’s credits, Copilot Studio bills the environment, and building with the CLI is not billed. However already running the app locally or live for that matter, is also billed.

If Code Apps does the job and you are licensed for it, use Code Apps. Use Managed Apps when the app needs server-side logic, or when a business user and a developer need to work on the same repo, or when a small data store that follows the app is enough. That rule came from the product team, and I agree with it.

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.

Code Apps had one way in and one host inside Power Platform. Copilot Managed Runtime has one host for every way in, including third-party app builders such as Lovable that publish through the SDK.

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	The repository (platform-managed or your own GitHub)
Server-side logic	Outside the product: flows, Dataverse plug-ins or Azure Functions	Middle tier in the same sandbox (Private)
App-scoped data	None. Dataverse, SharePoint or SQL through connectors	Built-in database (Private), plus the same connectors
Who builds	Developers, Power Apps vibe	Cowork, Copilot Studio, CLI/SDK, Lovable, Copilot Code
Admin home	Power Platform admin center	Microsoft 365 admin center, Apps node
ALM	Dataverse solutions and pipelines	Git-based stages (Preview)
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

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 ms CLI 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.

The rate is 0.1 credit per API call plus a charge per launch, and a user with neither credits nor a Premium plan gets a warning first and then a block after 20 app operations or five minutes.

Status today

Copilot Managed Runtime is in public preview and Microsoft continues to update it. 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.