Copilot Managed Runtime: Interne Apps per CLI bereitstellen

Was Copilot Managed Runtime genau ist

Copilot Managed Runtime ist eine verwaltete Umgebung für interne Geschäftsanwendungen. Der Code bleibt editierbar, die Versionsverwaltung erfolgt weiterhin mit echtem Git. Microsoft stellt zugleich die gehostete Laufzeit, die Anmeldung über Microsoft Entra, kontrollierte Datenverbindungen, Vorschau- und Deployment-Abläufe sowie ein Admin-Inventar bereit.

Das Prinzip ähnelt einem Bürogebäude mit umfassendem Service. Die Gestaltung der einzelnen Räume bleibt Sache des Mieters; Empfang mit Zugangskontrolle, Versorgung, Sicherheitsregeln, Wartungsprotokoll und Gebäudetechnik sind bereits vorhanden. Das unterscheidet die Plattform von einer KI-Programmieroberfläche, die lediglich den Grundriss entwirft.

Microsoft beschreibt das SDK als Entwicklerschicht für interne Line-of-Business-Apps. Es bietet Entra-Authentifizierung ohne eigenen Identitätscode sowie Zugriff auf mehr als 1,500 Konnektoren aus JavaScript und TypeScript. Welche Konnektoren und Aktionen eine App tatsächlich nutzen darf, bestimmt jedoch die jeweilige Tenant-Richtlinie. Den maßgeblichen Rahmen setzen die Dokumentation zum SDK in der Public Preview und die Ankündigung zum Start.

Dieser Leitfaden behandelt das aktuell verfügbare SDK und die zugehörige CLI. Copilot Code oder Autopilot werden hier nicht als austauschbare Bezeichnungen für diese Toolchain verwendet.

Wo die App tatsächlich liegt

Der Speicher- und Ausführungsort verändert sich im Laufe des Lebenszyklus:

Diese Trennung ist wichtig: Die Vorschau kann sich verändern, während die Live-Version stabil bleibt. Ein fehlgeschlagener Vorschau-Build ersetzt außerdem nicht die letzte erfolgreiche Version.

Vor dem Code kommen die Zugangshürden

Kaum etwas kostet schneller einen Arbeitstag, als erst nach Fertigstellung der App auf eine Tenant- oder Lizenzhürde zu stoßen. Deshalb sollten zunächst diese fünf Punkte geprüft werden.

Abrechnungsmodelle und Admin-Richtlinien brauchen eine eigene Budgetentscheidung. Vor dem Zugriff für eine Pilotgruppe hilft die separate Preisübersicht zu Copilot Managed Runtime. Ein operativer Punkt gehört dennoch hierher: Die lokale Ausführung ist kein kostenloses Schlupfloch. Sie erfordert dieselbe Laufzeitabdeckung wie die Nutzung durch Endanwender.

Was für diesen Leitfaden tatsächlich geprüft wurde

Die Paketprüfung wurde real durchgeführt, der Test in einem Tenant dagegen nicht.

Entsprechend erhebt dieser Artikel keinen Anspruch auf eine gemessene Zeit bis zur ersten lokalen Seite oder zur gehosteten Vorschau. Ebenso wenig wurden hier ein Build-Fehler beobachtet, eine Entra-Identität untersucht, ein Konnektoraufruf ausgeführt, ein Deployment vorgenommen oder Laufzeitkosten abgerechnet. Die folgenden Schritte bilden den von Microsoft dokumentierten Weg ab und sind kein als Praxistest getarnter Ablauf.

Eine kleine Betriebs-App mit der CLI bereitstellen

Als Beispiel dient eine synthetische App namens Ops Intake. Ihre erste Aufgabe ist bewusst überschaubar: Datensätze aus einer einzigen, vom Tenant freigegebenen Quelle in einer schreibgeschützten Warteschlange anzeigen. Mit einem Lesezugriff bleibt die erste Richtlinienprüfung nachvollziehbar. Schreibzugriffe kommen erst hinzu, wenn Identität, Quellberechtigungen, Konnektorrichtlinie und Laufzeitabdeckung nachweislich funktionieren.

Für einen reproduzierbaren Ablauf ist die am 27. September 2026 geprüfte CLI-Version fest vorgegeben. Die im eigenen Projekt eingesetzte Version sollte ebenfalls im Repository dokumentiert sein, damit ein aktualisiertes Vorschaupaket den Pilotbetrieb nicht unbemerkt verändert.

npm install -g @microsoft/managed-apps-cli@0.25.1
ms --version

ms auth login
ms app create ops-intake --display-name "Ops Intake"
cd ops-intake

npm install
ms app dev

ms connector list --search SharePoint
ms connector list-actions --connector <allowed-connector-id> --search list
ms app add data-source --connector <allowed-connector-id>

git add .
git commit -m "first ops intake flow"
git push

ms app play --mode preview
ms app build-status
ms app deploy

Die einzelnen Übergänge bedeuten Folgendes.

1. Anmelden und die kontrollierte App-Hülle anlegen

ms auth login öffnet die Anmeldung über Microsoft Entra. Auf einem Rechner ohne grafische Oberfläche bietet die CLI zusätzlich --device-code an. Mit ms app create werden der App-Eintrag und das Projektgerüst angelegt; standardmäßig kommt ein von der Plattform verwaltetes Git-Repository zum Einsatz. Beim ersten Create- oder Init-Vorgang wird außerdem die identitätsgebundene Entwicklerumgebung des Makers bereitgestellt, sofern das Routing dies zulässt.

Der Repository-Modus sollte bewusst gewählt werden. Plattformverwaltetes Git ermöglicht den schnellsten Einstieg. Als externes Repository werden GitHub.com und GitHub Enterprise Cloud unterstützt. GitHub Enterprise Server, Azure DevOps und andere Anbieter sind für diesen Pfad nicht verfügbar. Der Repository-Modus bleibt während der gesamten Lebensdauer der App unveränderlich. Ein späterer Wechsel erfordert deshalb eine neue App.

2. Lokal starten und die erste aussagekräftige Zeit erfassen

Nach der einmaligen Installation der Abhängigkeiten aus dem Projektgerüst startet ms app dev die App. Der Befehl liest ms.config.json, führt den Entwicklungsprozess des Projekts aus und gibt eine Local Play URL aus. Diese URL sollte im selben Browserprofil geöffnet werden, das auch für den Tenant verwendet wird.

Die Zeitmessung beginnt unmittelbar vor ms app dev und endet, sobald die erste nutzbare Seite erscheint. Unterbrechungen durch Browserberechtigungen werden separat protokolliert. Chrome und Microsoft Edge können den Zugriff eines öffentlichen Ursprungs auf localhost blockieren, bis der Zugriff auf das lokale Netzwerk erlaubt wurde. Das ist eine Browserhürde und kein fehlgeschlagener App-Build.

3. Einen kontrollierten Lesezugriff nachweisen

ms connector list zeigt Konnektor-IDs, Authentifizierungstyp, Unterstützung tabellarischer Daten sowie den Status von Data Loss Prevention und Advanced Connector Policy. Für die jeweilige Umgebung ist diese Ausgabe die maßgebliche Informationsquelle. Die bloße Existenz eines Konnektors im Microsoft-Katalog bedeutet nicht, dass er im eigenen Tenant freigegeben ist.

Für Ops Intake wird eine zulässige SharePoint-Verbindung samt Dataset und Liste ausgewählt, anschließend ein Lese- oder Listen-Vorgang. Der interaktive Ablauf von ms app add data-source erzeugt typisierte TypeScript-Modelle und -Dienste unter generated/. Statt einen eigenen direkten Graph-Token-Flow zu bauen, ruft die App die generierte Lesemethode auf.

Im Browser sind drei Punkte zu prüfen:

1. Der angemeldete Nutzer ist die erwartete Entra-Identität.
2. Der Nutzer sieht ausschließlich Datensätze, die ihm bereits vom Quellsystem erlaubt werden.
3. Verliert derselbe Nutzer den Zugriff auf die Quelle, reagiert die App sicher.

Eine spätere Freigabe der App erteilt keinen Zugriff auf die zugrunde liegenden Daten. Jeder Empfänger braucht weiterhin die passenden Quellberechtigungen und eine eigene Verbindung. Das ist eine Schutzfunktion und kein lästiges Deployment-Detail.

4. Echten Quellcode committen und pushen

Hier gelten die üblichen Git-Befehle. Die Runtime-CLI ersetzt keine Versionsverwaltung. Der Commit sollte sowohl die funktionierende Änderung an der Anwendung als auch die zum Projekt gehörenden, generierten Konnektorbindungen enthalten.

Die entscheidende Falle ist einfach: git push baut die App nicht. Der Befehl aktualisiert lediglich die maßgebliche Remote-Version des Quellcodes.

5. Die gehostete Vorschau öffnen und den Build prüfen

ms app play --mode preview öffnet den stabilen Vorschau-Endpunkt. Existiert für den jüngsten gepushten Commit noch kein Build, wird beim Öffnen der Vorschau einer angestoßen. Gemessen wird die Zeit vom Öffnen bis zur Bereitstellung der neuen Version.

Scheitert der Build, liefert ms app build-status – optional mit --commit <sha> – den vollständigen Grund, der zusammen mit dem Commit gespeichert werden sollte. Während eine neuere Version noch gebaut wird oder fehlgeschlagen ist, zeigt die Vorschau weiterhin den vorherigen erfolgreichen Build. Die Vorschau-URL richtet sich an Entwickler mit Schreibzugriff auf das Repository, nicht an beliebige Tester.

Soll ein Build schon vor dem Öffnen der Vorschau beginnen, steht ms app build zur Verfügung. Für die meisten Teams ist es zunächst sinnvoller, das Standardverhalten kennenzulernen: Quellcode pushen, danach die Vorschau öffnen.

6. Nur die geprüfte Version bereitstellen

ms app deploy übernimmt einen erfolgreichen Build in die Live-App. Die Live-Version ist eine feste Momentaufnahme und folgt nicht automatisch jedem Push oder Vorschau-Build.

Für eine kontrollierte Veröffentlichung werden Commit-SHA und Build-Status dokumentiert, die zugehörige Vorschau geöffnet und genau dieser SHA anschließend mit ms app deploy --commit <sha> bereitgestellt. Dieselbe Option ermöglicht einen sauberen Rollback auf einen früheren erfolgreichen Build, ohne die Git-Historie umzuschreiben.

Die Wirtschaftlichkeit entscheidet sich auf Plattformebene

Die Laufzeit macht Anwendungsarbeit nicht kostenlos. Sie verschiebt vielmehr die Grenze zwischen dem, was ein Team selbst beschaffen oder bauen muss, und dem, was die Plattform übernimmt.

Das vergleichbare Softwarebudget ist durchaus relevant. Laut offizieller Preisübersicht von Retool kostet der Team-Tarif $10 pro Builder und $5 pro internem Nutzer im Monat, der Business-Tarif $50 pro Builder und $15 pro internem Nutzer im Monat. Copilot Managed Runtime unterbietet diese Beträge nicht automatisch. In einer Microsoft-365-Organisation kann die Lösung separate Plattformarbeit einsparen; Laufzeitlizenzen, Credits, Konnektorarbeit und Admin-Zeit bleiben dennoch reale Kosten.

Vor der Behauptung, der Pilot sei günstiger, hilft diese Rechnung:

Pilotkosten = Entwicklungszeit + Admin-Einrichtung + Laufzeitabdeckung + Konnektor- und Datenarbeit.

Am ehesten sinkt der Aufwand für den Plattformaufbau. Die größte Überraschung dürfte dagegen die Laufzeitabdeckung für jeden Nutzer sein, der die App öffnet.

Sieben interne Apps, für die sich diese Laufzeit eignet

Am besten passen interne Workflows, bei denen Identität, kontrollierte Microsoft-365-Daten und gesteuerte Releases wichtiger sind als ein öffentliches Schaufenster.

Jeder Anwendungsfall sollte schreibgeschützt beginnen. Eine Schreibaktion, ein externer Endpunkt, ein Drittanbieter-Konnektor oder eine breit freigegebene App verändert die Prüfung. Die Standardrichtlinie umfasst 18 Microsoft-eigene Konnektoren, nicht den gesamten Katalog. Selbst innerhalb freigegebener Konnektoren blockiert sie bestimmte Aktionen für offene HTTP-Aufrufe, beliebigen Code, beliebige Abfragen und beliebige Plattformen.

Drei Produkte, die auf der Laufzeit aufbauen können

Das stärkste Produktkonzept ist eine Kommandozentrale für das Microsoft-365-Onboarding. Hier trifft die höchste gemessene Nachfrage auf einen Workflow, der naturgemäß Identität, Dokumente, Aufgaben, E-Mail und Teamübergaben verbindet.

1. Eine Kommandozentrale für das Microsoft-365-Onboarding

Die interne App bündelt für HR und IT den freigegebenen Datensatz neuer Beschäftigter, offene Aufgaben, Dokumentlinks und Zuständigkeiten. HR Operations und IT-Service-Teams zahlen für weniger verpasste Übergaben und eine einfachere Prüfspur.

Die Nachfrage ist sichtbar: „employee onboarding software“ kommt in den USA auf rund 590 Suchanfragen pro Monat, mit kommerzieller Suchabsicht und einem Klickpreis von $156.35. Die engere Suchanfrage „best employee onboarding software“ erreicht 90 Suchanfragen pro Monat und verzeichnete in den Vorschlagsdaten ein jährliches Trendwachstum von 180%.

Die kleinste verkaufsfähige Version bedient eine Abteilung, liest eine freigegebene Beschäftigtenliste, zeigt eine Aufgabencheckliste und verknüpft jede Aufgabe mit der zuständigen Person. Konnektoraktionen kommen erst hinzu, nachdem der Lesezugriff die Richtlinien- und Berechtigungstests bestanden hat.

Die Einschränkung wiegt schwer: Personaldaten sind sensibel, Quellberechtigungen werden leicht missverstanden und etablierte Onboarding-Anbieter decken bereits umfassendere HR-Workflows ab. Das Produkt gewinnt nur dann, wenn Microsoft-365-Governance und ein Betrieb direkt im Tenant wichtiger sind als eine lange allgemeine Feature-Liste.

2. Ein kontrolliertes Cockpit für Freigaben

Hier entsteht eine wiederverwendbare Freigabeoberfläche für Finance-, Beschaffungs- oder Betriebsteams, die einen klaren Entscheidungsstatus haben, deren Begleitinformationen aber verstreut liegen. Bezahlt wird für schnellere Prüfungen und einen kontrollierten Release-Prozess – nicht für einen weiteren Formularbaukasten.

„Approval workflow software“ erzielt in den USA rund 320 Suchanfragen pro Monat, mit kommerzieller Suchabsicht, einem Klickpreis von $114.86 und einem jährlichen Trendwachstum von 53% in den Vorschlagsdaten. Diese Kombination weist auf ein aktives Kaufproblem hin und lässt Raum für eine fokussierte Microsoft-365-Implementierung.

Das MVP umfasst einen Anfragetyp, eine freigegebene Quelle, eine schreibgeschützte Prüfoberfläche, den Entscheidungsverlauf und eine einzelne richtlinienkonforme Aktion. Das Entscheidungsmodell bleibt deterministisch. Freigaberegeln gehören nicht versteckt in generierten Fließtext.

Die Hürde liegt in der Konnektorrichtlinie. Ein Konnektor kann freigegeben sein, während eine bestimmte Aktion gesperrt bleibt. Klassische Datenrichtlinien können zudem mit Advanced Connector Policies kombiniert werden; dann gilt das restriktivste Ergebnis.

3. Eine Migrationsanalyse für Managed Apps

Als standardisierte Dienstleistung prüft dieses Angebot eine KI-generierte oder individuell entwickelte interne Web-App darauf, ob sie sich in Copilot Managed Runtime überführen lässt. Zielgruppe sind Microsoft-365-Organisationen mit einem nützlichen Prototyp, die keinen weiteren separaten Stack für Hosting und Governance betreiben möchten.

„Custom business app development“ erreicht in den USA rund 90 Suchanfragen pro Monat, mit kommerzieller Suchabsicht und einem Klickpreis von $84.03. Das Volumen ist kleiner, die Anfrage liegt jedoch nah an einem Dienstleistungskauf.

Das MVP erfasst Repository, Laufzeitannahmen, externe Endpunkte, Identitätscode, Datenquellen und erforderliche Aktionen der App. Daraus entsteht eine Entscheidung nach dem Muster „geeignet“, „ändern“ oder „stoppen“; anschließend wird ein schreibgeschützter Teil in eine Testumgebung portiert.

Die Einschränkung ist die Plattformbindung. Das Ergebnis ist nur für berechtigte Microsoft-365-Tenants relevant, das Verhalten der Public Preview kann sich ändern und nicht unterstützte Quellcodeanbieter oder gesperrte externe Ressourcen können aus einer scheinbar einfachen Migration einen Neubau machen.

Was Copilot Managed Runtime nicht löst

Für kontrollierte interne Apps ist dies ein vielversprechender Weg, aber keine universelle Anwendungsplattform.

• Das Feature befindet sich in der Public Preview und wird in Vorab-Dokumentation beschrieben. Befehlsverhalten und Richtlinienoberflächen können sich ändern.
• Der CLI-Pfad zur App-Erstellung wird nicht automatisch freigeschaltet. Selbst bei einem für die Laufzeit berechtigten Tenant ist er standardmäßig deaktiviert.
• Aus mehr als 1,500 Konnektoren werden nicht automatisch erlaubte Datenquellen. Über den Zugriff entscheiden weiterhin Tenant-Richtlinien, Aktionsrichtlinien für Konnektoren, klassische Datenrichtlinien und Quellberechtigungen.
• Aus einer internen Line-of-Business-App wird kein öffentliches Kundenprodukt. Die Vorschau ist Entwicklern mit Schreibzugriff auf das Repository vorbehalten; der Live-Zugriff wird innerhalb des kontrollierten Modells gezielt freigegeben.
• Nicht jeder Repository-Anbieter wird unterstützt. Externer Quellcode ist auf GitHub.com und GitHub Enterprise Cloud begrenzt, und der Repository-Modus lässt sich nicht nachträglich ändern.
• Die Laufzeitlizenzierung entfällt nicht. Lokale Ausführung und Endnutzerausführung benötigen Power Apps Premium oder finanzierte Managed Application Copilot Credits.
• Administratoren erhalten kein lückenloses forensisches Protokoll. Die Admin-Ansicht umfasst Inventar, Nutzung, Zustand, Konnektoren, Datenquellen und Abhängigkeiten. Laut Microsoft ist sie jedoch keine vollständige Darstellung exakter Ziele, dynamischer Endpunkte, ausgeführter Aktionen oder der effektiv geltenden Quellberechtigungen jedes Nutzers.
• Dieser Artikel weist kein Deployment durch die Redaktion nach. Fehlender Git Credential Manager, eine fehlende Linux-Secret-Store-Bibliothek und das Fehlen eines berechtigten Tenants stoppten den Test vor der Anmeldung.

Die nüchterne Entscheidung ist eng umrissen: Geeignet ist die Plattform, wenn die App intern bleibt, die Organisation bereits in Microsoft 365 arbeitet und die eingesparte Identitäts- und Governance-Arbeit die Akzeptanz einer Vorschauplattform samt Tenant-Kontrollen rechtfertigt. Ein anderer Host ist sinnvoller, wenn ein öffentliches SaaS-Produkt, ein anderer Quellcodeanbieter, Kontrolle über die Infrastruktur oder ein von den Administratoren nicht genehmigungsfähiges Release-Modell erforderlich ist.

Häufig gestellte Fragen

Der nächste Schritt am Montag

Ein Power Platform Administrator aktiviert die CLI-Erstellung für eine einzelne Testgruppe, bestätigt deren Umgebungsroutingregel und stattet zwei Testnutzer mit Laufzeitabdeckung aus. Als Datenbasis dienen eine nicht sensible SharePoint-Liste und genau ein schreibgeschützter Vorgang. Anschließend protokolliert ein Entwickler vier Fakten: CLI-Version, Zeit bis zur ersten lokalen Seite, Zeit bis zur gehosteten Vorschau und Commit-SHA des Deployments. Der Pilot wird gestoppt, sobald Entra-Identität, Quellberechtigungen oder Konnektorrichtlinie vom dokumentierten Sollverhalten abweichen.

Wenn dieser kontrollierte App-Pfad für Ihr Unternehmen konzipiert und umgesetzt werden soll, beginnen Sie mit einer Analyse der KI-Produktionssysteme.