Power-Apps-Alternative: Open-Source-Low-Code auf dem eigenen Server, mit lokaler KI

Eine Power-Apps-Alternative auf eigenen Servern

Für interne Formulare, Freigabe-Workflows und Daten-Apps laufen Open-Source-Low-Code-Plattformen wie Appsmith, Budibase, ToolJet, NocoBase und Baserow auf Servern, die das Unternehmen selbst kontrolliert, und ein Sprachmodell auf einer lokalen GPU ergänzt diese Apps um KI-Funktionen ohne Cloud-KI-Dienst. Welche Plattform passt, hängt von drei Dingen ab: ihrer Lizenz, ob ihre KI-Funktionen ein lokales Modell annehmen und welche Funktionen in der freien Edition stecken. Für das Modell hinter den Apps empfehlen wir einer mittelgroßen IT-Abteilung eine Workstation mit einer NVIDIA RTX PRO 5000 Blackwell (48 GB).

Dieser Vergleich richtet sich an IT-Teams, die interne Apps für Einkauf, Personal, Qualität oder Facility Management bauen und sie samt Daten im Firmennetz halten wollen. Power Apps dient als Ausgangspunkt des Vergleichs; jede der Plattformen unten hat ihr eigenes Modell für Daten, Seiten und Berechtigungen. Eine Low-Code-Plattform ist ein Werkzeug, in dem Apps aus fertigen Bausteinen wie Tabellen, Formularen und Schaltflächen zusammengesetzt und mit einer Datenbank verbunden werden, mit Code nur dort, wo er nötig ist. Ein lokales Modell ist ein KI-Sprachmodell, das auf Ihrer eigenen GPU läuft statt in der Cloud eines Anbieters.

Wenn die Apps von Personen außerhalb der IT gebaut werden sollen, indem sie sie einer KI beschreiben, behandelt unser Leitfaden zu internen Tools mit KI ohne Entwickler diesen Weg mit Dyad.

Was Power Apps abdeckt und was ein Ersatz braucht

Die Übersicht von Power Apps, zuletzt aktualisiert am 18. November 2025, beschreibt das Produkt als Sammlung von Apps, Diensten und Konnektoren samt Datenplattform, mit der sich eigene Geschäftsanwendungen schnell entwickeln lassen („a rapid development environment to build custom apps for your business needs“). Sie nennt zwei Arten von Apps, Canvas und modellgesteuert, nutzt Dataverse als Datenplattform und verbindet sich mit weiteren Quellen wie SharePoint und SQL Server. Laut der Übersicht beschreiben Sie mit Copilot die gewünschte App, und die KI entwirft sie.

Ein selbst gehosteter Ersatz für typische interne Apps braucht:

• Daten. Eine eigene Datenbank oder Konnektoren zu PostgreSQL, MySQL, der Datenbank Ihres ERP-Systems oder REST-APIs.
• Formulare, Tabellen und Seiten, die ein Power-User bauen kann, und Code dort, wo die Logik ihn braucht.
• Workflows. Freigaben, Benachrichtigungen und geplante Aufgaben. Workflow-Werkzeuge ohne App-Oberfläche wie n8n oder Dify decken einen Teil davon mit einem lokalen Modell ab.
• Anmeldung und Rollen. Single Sign-on mit den Firmenkonten, rollenbasierte Zugriffe und Audit-Logs. Oft trennen genau diese Funktionen eine freie Edition von einer kostenpflichtigen.
• KI. Funktionen in den Apps, etwa einen Antrag zusammenfassen oder Felder herauslesen, und Hilfe beim Bauen von Apps, beides mit einem Modell, das Sie selbst betreiben.

Fünf selbst gehostete Plattformen im Vergleich

GitHub-READMEs und Lizenzdateien von Appsmith, Budibase, ToolJet, NocoBase und Baserow sowie deren Dokumentation zu KI-Datenquellen, Agenten, LLM-Diensten und KI-Anbietern, gelesen am 30. Oktober 2026.

Appsmith beschreibt sich als Plattform für Admin-Panels, interne Tools und Dashboards („Platform to build admin panels, internal tools, and dashboards“), die laut README mit mehr als 25 Datenbanken und jeder API zusammenarbeitet. Es steht unter der Lizenz Apache 2.0, empfohlen wird die Installation mit Docker. Die eigene Datenquelle Appsmith AI wurde am 30. September 2026 eingestellt („reached end of life“); die Dokumentation verweist stattdessen auf Datenquellen für OpenAI, Anthropic und Google AI, und die OpenAI-Datenquelle nennt als Verbindungseinstellung nur einen API-Schlüssel. Ein lokales Modell erreicht Appsmith deshalb über seine allgemeinen API-Verbindungen, wie jeden anderen HTTP-Dienst.

Budibase steht laut README unter der GPL v3, seine Client- und Komponentenbibliotheken stehen unter MPL, kostenpflichtige Funktionen unter der Business Source License. Seine Agenten können eine Liste von Cloud-Anbietern nutzen oder über „Connect to a custom provider“ einen eigenen Anbieter anbinden, wofür je nach Anbieter laut Dokumentation, aktualisiert am 6. Oktober 2026, eine API-Basis-URL, ein API-Schlüssel oder ein Standardmodell anzugeben ist. Das ist die Einstellung für einen lokalen Modellserver. Welche Editionen Agenten enthalten, sagt die Seite nicht; die Preisseite von Budibase nennt für den kostenlosen, selbst gehosteten Plan unbegrenzt viele Agenten und SSO, Audit-Logs nur für Enterprise.

ToolJet steht unter der AGPL-3.0. Seine Community Edition enthält den visuellen App-Builder, eine eigene Datenbank, mehr als 80 Datenquellen, SSO-Unterstützung sowie JavaScript und Python in Apps. KI-App-Generierung, KI-Abfrage-Builder, KI-Debugging, Agent-Builder, Audit-Logs, rollenbasierte Zugriffskontrolle und Git-Synchronisierung stehen unter ToolJet AI (Enterprise). In der freien Edition erreicht eine App ein Modell über eine Datenquelle, etwa eine API-Verbindung zu Ihrem Modellserver.

NocoBase zeigt auf GitHub Apache 2.0, und seine LICENSE-Datei, aktualisiert am 24. Februar 2026, ergänzt das NocoBase License Agreement. Es erlaubt die kommerzielle Nutzung, verlangt, dass das NocoBase-Branding und die Lizenzhinweise in der Oberfläche bleiben (außer dem Hauptlogo), und verbietet, eine öffentliche No-Code-, Low-Code- oder KI-Plattform darauf anzubieten. Seine KI-Mitarbeiter arbeiten in den Apps mit eigener Rolle und Berechtigungen bis auf Feldebene, und die Einstellungen für LLM-Dienste nennen „Ollama local models“ neben Cloud-Anbietern, mit optionaler Basis-URL; das Plugin ist als „Community Edition+“ gekennzeichnet. Das README nennt außerdem Coding-Agenten, darunter OpenCode, die NocoBase-Apps über das Kommandozeilenwerkzeug von NocoBase bauen und konfigurieren.

Baserow stellt laut README alle Funktionen außerhalb von Premium und Enterprise unter die MIT-Lizenz. Es verbindet eine Datenbank mit einem Application Builder, mit dem sich Anwendungen und Portale erstellen und unter einer eigenen Domain veröffentlichen lassen. Seit Version 2.4 werden KI-Anbieter in den Admin-Werkzeugen eingestellt, mit Feldern für den Ollama-Host und seine Modelle, und Baserow nutzt sie für KI-Felder, Formelvorschläge, KI-Aktionen im Application Builder und in Automationen sowie für seinen Assistenten Kuma. Welche Edition jede KI-Funktion braucht, nennt die Dokumentation nicht.

Ein lokales Modell an die Apps anbinden

Jede der fünf Plattformen erreicht ein Modell über HTTP, entweder über eine eingebaute Einstellung für KI-Anbieter oder über eine allgemeine API-Verbindung, und die üblichen Modellserver bieten eine API im Format von OpenAI. Ollama dokumentiert /v1/chat/completions, /v1/embeddings und weitere Endpunkte; vLLM bietet dieselbe Art von Server. Das Feld „OpenAI-kompatibel“ oder „eigener Anbieter“ einer Plattform zeigt dann auf die Adresse Ihres Modellservers statt auf einen Cloud-Dienst.

Typische KI-Funktionen in internen Apps sind klein und häufig: einen eingehenden Antrag einordnen und an die richtige Freigabe leiten, Lieferant, Betrag und Datum aus einem Text herauslesen, die Antwort auf einen abgelehnten Antrag entwerfen, einen langen Kommentarverlauf für die freigebende Person zusammenfassen. Jede davon ist eine kurze Anfrage an das Modell, deshalb versorgt eine GPU viele Apps.

Zwei Sicherheitspunkte gehören in die Einrichtung. Ollamas Dokumentation sagt zum API-Schlüssel: „The client requires an API key value, but Ollama ignores it.“ Der Modellserver braucht deshalb Netzwerkregeln und ein Gateway, das prüft, wer ihn aufruft. vLLMs --api-key schützt nur die Pfade unter /v1 und einige weitere Präfixe, während Routen wie /metrics, /health und /tokenize ohne Schlüssel antworten, so die Sicherheitsdokumentation von vLLM im Oktober 2026. Nutzen Sie wegen CVE-2026-103663 Ollama 0.35.0 oder neuer. Setzen Sie OLLAMA_NO_CLOUD=1, damit der Modellserver weder Cloud-Modelle noch Websuche anbietet, wie Ollamas FAQ beschreibt. Unser Leitfaden zur Absicherung eines GPU-Servers behandelt den Rest.

Sie können die Workstation allein bestellen, die Einrichtung einer Low-Code-Plattform (Appsmith, Budibase, ToolJet oder Baserow) und des lokalen Modells allein oder beides zusammen: die Workstation mit allem fertig installiert und eingerichtet; schreiben Sie uns, wir schlagen Ihnen die beste Lösung für Ihre Aufgaben und Ihr Budget vor.

KI-App-Generierung mit einem lokalen Modell

Beim Bauen von Apps aus einer Beschreibung unterscheiden sich die Editionen am stärksten. Copilot in Power Apps gehört zum Cloud-Dienst des Herstellers, die KI-App-Generierung von ToolJet zur Enterprise-Edition. Mit einem lokalen Modell funktionieren drei Wege:

• NocoBase mit einem Coding-Agenten. Das README hält fest, dass Coding-Agenten Apps über das Kommandozeilenwerkzeug und die Skills von NocoBase bauen und konfigurieren; OpenCode, einer der genannten Agenten, arbeitet mit einem lokalen Modell, wie unser Leitfaden zu Claude Code mit lokalem Modell erklärt.
• Der Assistent Kuma von Baserow, der Datenbanken und Workflows aus einfacher Sprache anlegt; sein Modell wird unter den KI-Funktionen in den Einstellungen für KI-Anbieter gewählt. Die Dokumentation bestätigt weder, dass ein Ollama-Modell mit Kuma funktioniert, noch nennt sie die Edition, die Kuma enthält; fragen Sie bei Baserow nach und testen Sie es.
• Codebasierte Apps, die ein Coding-Agent auf der Workstation schreibt, für Teams, die reinen Code einer Plattform vorziehen. Unser Leitfaden zur Vibe-Coding-Workstation dimensioniert diesen Fall.

Von einer KI gebaute Apps brauchen weiterhin die Prüfungen aus unserem Leitfaden zur Sicherheit beim Vibe Coding vor dem Livegang: Zugriffsrechte auf dem Server, keine Schlüssel im Frontend, Logging.

Die GPU hinter den Apps dimensionieren

Die Plattformen selbst sind gewöhnliche Webanwendungen in Docker; die GPU ist für das Modell da. Der Speicher entscheidet, wie viele Anfragen es gleichzeitig beantwortet: Das Modell und ein Cache je Anfrage müssen auf die Karte passen. Nach unserer Regel für Nutzer je Karte stehen Modell und Caches 90 Prozent des vom Treiber gemeldeten Speichers abzüglich 3 GiB je Karte zur Verfügung. Den Cache rechnen wir in 16 Bit, der Voreinstellung von Ollama: Für Qwen3.8-27B (Apache 2.0) braucht eine Anfrage von 32K Token etwa 2,1 GiB, eine Sitzung von 128K eines Agenten, der Apps baut, etwa 8,1 GiB, wie unser Qwen-Hardware-Leitfaden berechnet.

Unsere Schätzung nach der Regel für Nutzer je Karte mit nutzbarem Speicher von 25,7, 40,0, 61,5 und 83,0 GiB und den 4-Bit- (18 GB) und 8-Bit-Dateien (30 GB) von Qwen3.8-27B in Ollama und einem 16-Bit-Cache, Stand ollama.com am 30. Oktober 2026; keine Messungen.

Die RTX PRO 5000 mit 48 GB fasst das 8-Bit-Modell, die genauere der beiden Ollama-Versionen, mit fünf gleichzeitigen Anfragen von 32K Token oder einer Agentensitzung von 128K. Die Version mit 72 GB bewältigt fünfzehn kurze Anfragen oder vier Agentensitzungen, genug für App-KI und ein IT-Team, das zugleich mit einem Agenten Apps baut. Diese Zahlen setzen voraus, dass der Kontext auf 32K oder 128K gesetzt und OLLAMA_NUM_PARALLEL erhöht ist: Standardmäßig beantwortet Ollama je Modell eine Anfrage nach der anderen und reserviert auf den Karten mit 72 und 96 GB einen Kontext von 256K. Auf der 96-GB-Karte sind mit vLLM, Qwens FP8-Checkpoint und einem FP8-Cache nach derselben Regel 47 Anfragen von 32K möglich, die Zahl, mit der auch unsere anderen Leitfäden zu Qwen3.8-27B rechnen. Für Apps, die im ganzen Unternehmen genutzt werden, gehört das Modell auf einen Rack-Server mit RTX PRO 6000 Server Edition, der Edition, die wir für den Dauerbetrieb im Rack empfehlen; dort bedient es auch Chat und Dokumentensuche, wie unser Leitfaden zum KI-Server für Firmen mit 10 bis 100 Mitarbeitenden beschreibt.

StorageReview hat Qwen3.8-27B im NVFP4-Format von NVIDIA mit vLLM 0.27.1 in einem Test vom 14. Oktober 2026 gemessen. Bei einer einzelnen Anfrage lag jede Karte, auf der das Modell lief, zwischen 17 und 22 Token pro Sekunde, von der RTX PRO 4500 Blackwell Server Edition und einer L40S bis zu einer RTX PRO 6000 Blackwell Workstation Edition; mit 32 gleichzeitigen Anfragen von je 512 Eingabe- und 512 Ausgabe-Token erzeugte die RTX PRO 6000 Workstation Edition bei 600 W insgesamt 616 Ausgabe-Token pro Sekunde. Eine Klassifizierung, die 50 Token zurückgibt, ist bei diesem Tempo schnell erledigt; eine entworfene Antwort von 300 Token dauert nach unserer Rechnung für eine Anfrage etwa 14 bis 18 Sekunden. Für die RTX PRO 5000 mit diesem Modell haben wir keine veröffentlichte Zahl gefunden. Ihre Speicherbandbreite von 1.344 GB/s, gegenüber 1.792 GB/s bei der RTX PRO 6000 Workstation Edition, setzt die Grenze für eine Anfrage: etwa 47 Token pro Sekunde für das 8-Bit-Modell, nach unserer Schätzung eine Obergrenze, gerechnet wie in unserem Leitfaden zur Vibe-Coding-Workstation.

Nach unserer Schätzung (Karte, ein 350-W-Prozessor und 15 Prozent für den Rest) zieht eine Workstation mit einer RTX PRO 5000 unter Volllast etwa 0,75 kW, ein Server mit zwei RTX PRO 6000 Server Edition etwa 1,8 kW.

Den Umstieg auf selbst gehostete Apps planen

• Mit einem Prozess beginnen. Ein Freigabe-Workflow mit Formular, Tabelle und Benachrichtigung zeigt in einem Projekt, ob die Plattform zu Ihrem Team passt.
• Die Editionen vergleichen. SSO, rollenbasierte Zugriffe und Audit-Logs sind die Punkte, an denen sich Editionen unterscheiden; ToolJet etwa führt SSO in seiner Community Edition und Audit-Logs sowie RBAC unter Enterprise.
• Die Lizenz für Ihren Einsatz lesen. Die Open-Source-Lizenzen aller fünf erlauben die interne Nutzung im Unternehmen; die Vereinbarung von NocoBase ergänzt die Branding-Regel und das Verbot eines öffentlichen Plattformangebots. Wenn Sie den Code einer Plattform ändern wollen, liest Ihre Rechtsberatung vorher deren Lizenz. Unser Artikel zu offenen Modelllizenzen für Unternehmen behandelt die Seite der Modelle.
• Festlegen, wer was betreut. Die IT betreibt Plattform, Datenbank, Sicherungen und Updates; die Fachabteilung verantwortet den Inhalt ihrer Apps.
• Datenregeln schriftlich festhalten. Welche App personenbezogene Daten enthalten darf, wer KI-Funktionen freigibt, die sie lesen, und wie lange Logs aufbewahrt werden; Ihr Datenschutz­beauftragter bestätigt die Einzelheiten. KI-Funktionen in Personal-Apps, die Bewerbungen filtern, Bewerber bewerten, Aufgaben nach persönlichen Merkmalen zuteilen oder Beschäftigte bewerten, zählen nach Anhang III Nummer 4 der KI-Verordnung (Verordnung (EU) 2024/1689) zu den Hochrisiko-Anwendungen; Ihre Rechtsberatung bestätigt, was gilt.

Beschreiben Sie die ersten zwei oder drei geplanten Apps, und wir schlagen das Plattform-Setup und die GPU für ihre KI-Funktionen vor.

FAQ