Was ist die beste selbstgehostete Alternative zu Retool?

Unter den Drag-and-Drop-Buildern ist Appsmith die größte Open-Source-Option, gefolgt von ToolJet, Budibase und Lowcoder — alle selbst hostbar. Wer die Drag-and-Drop-Grenze ganz vermeiden will, findet in einer code-zentrierten Plattform, die echte Apps mit enthaltenem Backend (Datenbank, Secrets, Cron, Funktionen) baut, ein anderes Modell, das den Aufwand für eine eigene Datenbank beseitigt. Die Wahl hängt davon ab, ob man einen visuellen Canvas oder echten Code bevorzugt.

Warum ist Retool so teuer?

Weil pro Platz abgerechnet wird und Betrachter mitzählen. Im Business-Plan kostet ein Builder $50/Nutzer/Monat und ein interner Nutzer $15/Nutzer/Monat, zuzüglich gemessener Workflow-Ausführungen, KI-Credits und Agentenstunden. Die Kosten skalieren mit der Zahl der Personen, die die Tools nutzen, nicht nur mit denen, die sie bauen — Erfolg macht sie also teurer.

Benötigen Open-Source-Builder für interne Tools eine eigene Datenbank?

Die meisten schon. Drag-and-Drop-Builder sind eine Schnittstellenschicht, die sich mit Daten verbindet, die anderswo liegen, daher werden Datenbank, Authentifizierung, Secrets und Scheduling separat bereitgestellt und betrieben. Eine Plattform, die eine Datenbank pro App, Secrets und Cron enthält, beseitigt diesen operativen Aufwand vollständig.

Können Low-Code-Tool-Builder echten Quellcode exportieren?

Normalerweise nicht sauber. Die App-Logik steckt im proprietären Format des Builders, und nur wenige können menschenlesbaren Quellcode exportieren, was die Migration mühsam macht. Wenn Vendor-Lock-in vermieden werden soll, empfiehlt sich eine Plattform, bei der das Ergebnis echter Code plus eine Standard-Datenbank ist, die man mitnehmen kann.

Was passiert, wenn man die Grenzen eines Drag-and-Drop-Builders erreicht?

Man greift auf einen Escape Hatch zurück — einen benutzerdefinierten Code-Block —, der oft auf clientseitiges JavaScript, Inline-CSS und eine Workflow-Oberfläche beschränkt ist, die mit wachsender Logik unhandlich wird. Die Grenze zeigt sich typischerweise bei individuellen Datentransformationen, bei Integrationen, die einen gehosteten Server erfordern, und bei UI jenseits der Standardkomponenten. Eine code-zentrierte Plattform stößt nie an diese Grenze, weil sie als Code startet.

Sind Appsmith, ToolJet oder Budibase wirklich kostenlos selbst zu hosten?

Der Open-Source-Kern ist kostenlos, und Self-Hosting erhöht die Limits kostenloser Nutzer (Budibase erlaubt 20 Nutzer gegenüber 5 bei Retool). Einrichtung, Wartung und Skalierung übernimmt man aber selbst, und kostenpflichtige Tiers sperren weiterhin Premium-Funktionen und Creator-Preise. Kostenlos bezieht sich auf die Lizenz, nicht auf die Gesamtbetriebskosten.

Was ist der Unterschied zwischen einem KI-nativen Builder und einem, bei dem KI nachträglich ergänzt wurde?

Ein Builder mit nachträglich aufgesetzter KI fügt einen KI-Knoten und einen Credit-Pool neben einem Canvas hinzu, der vor der KI-Ära entworfen wurde — ausreichend für einfache feldbasierte Aufgaben. Eine KI-native Plattform behandelt den Aufruf eines Modells als erstklassige Primitive im App-Code, sodass KI in die Logik des Tools eingewoben ist, statt in einem separaten Block zu sitzen.

← Resources

By Marcus Okafor — Platform Engineer, Apps · 2026-06-02 · GUIDE

Selbstgehostete Retool-Alternative: interne Tools ohne Kosten pro Platz

Low-Code-Builder für interne Tools sind eine Schnittstellenschicht über Daten, die anderswo liegen, und werden pro Builder-Platz und pro Betrachter-Platz abgerechnet. Diese Anleitung erklärt die Falle der Kosten pro Platz, die Anpassungsgrenze und warum ein code-zentrierter Builder mit enthaltenem Backend die Wirtschaftlichkeit verändert.

Wie Low-Code-Builder für interne Tools wirklich funktionieren

Tools wie Retool, Appsmith, ToolJet und Budibase setzen auf einen visuellen Drag-and-Drop-Canvas: Man fügt vorgefertigte Komponenten zusammen — Tabellen, Formulare, Buttons, Diagramme — und verbindet sie über Abfragen mit Daten. Im Kern sind sie eine Schnittstellenschicht über Daten, die anderswo liegen. Sie verbinden sich mit dem vorhandenen Postgres, MySQL, Snowflake, mit REST-APIs oder Tabellenkalkulationen, statt selbst etwas zu speichern.

Diese Architektur hat eine Konsequenz, die viele unterschätzen: Man muss trotzdem ein eigenes Backend bereitstellen und betreiben. Datenbank, Authentifizierung, Secrets, Scheduling und jegliche serverseitige Logik bleiben in der eigenen Verantwortung und müssen separat gehostet und gewartet werden. Der Builder liefert die Screens, nicht die darunterliegende Laufzeitumgebung.

Die Falle der Kosten pro Platz (und die Überraschung beim Betrachter-Platz)

Retool rechnet pro Platz ab, mit einer Unterteilung in Builder und Betrachter. Im Business-Plan kostet ein Builder $50/Nutzer/Monat (jährlich) und ein interner Nutzer $15/Nutzer/Monat; der Team-Plan liegt bei $10 pro Builder und $5 pro internem Nutzer, und der kostenlose Plan ist auf fünf Nutzer begrenzt. Die Überraschung für die meisten Teams: Auch Betrachter kosten Geld — Personen, die ein Tool nur nutzen, werden pro Platz über dem kostenlosen Kontingent berechnet, sodass die Kosten mit der Größe der Nutzerschaft skalieren, nicht nur mit der Zahl der Entwickler. Obendrauf kommen nutzungsbasierte Komponenten: gemessene Workflow-Ausführungen, nicht übertragbare KI-Credits und separat abgerechnete Agentenstunden.

Das Nettoergebnis: Ein Tool, das alle nutzen sollen, wird genau deshalb teurer, weil alle es nutzen.

Die Drag-and-Drop-Grenze

Visuelle Builder sind schnell — bis sie es nicht mehr sind. Low-Code stößt unweigerlich an eine Anpassungsgrenze, und die Standardlösung ist ein „Escape Hatch“ — ein benutzerdefinierter Code-Block. Das Problem: Dieser Escape Hatch ist häufig eingeschränkt. Manche Builder unterstützen nur clientseitiges JavaScript ohne serverseitige Ausführung, das Styling ist auf Inline-CSS beschränkt, und die flussdiagrammartige Workflow-Oberfläche wird mit wachsender Logik unübersichtlich.

Die Grenze zeigt sich an vorhersehbaren Stellen: individuelle Datentransformationen oder Algorithmen, Integrationen, die einen gehosteten Server erfordern, und UI-Anforderungen jenseits der vorgefertigten Komponenten. Und weil die App-Logik im proprietären Format des Anbieters steckt, können die meisten Builder keinen sauberen, menschenlesbaren Quellcode exportieren — die im Canvas geleistete Arbeit lässt sich daher kaum mitnehmen.

Die Open-Source-Self-Hosting-Option

Es gibt eine Open-Source-Kategorie, die genau dazu da ist, den Kosten pro Platz und dem Vendor-Lock-in zu entkommen. Appsmith ist die größte Lösung (Zehntausende GitHub-Sterne); ToolJet, Budibase, Lowcoder und NocoDB vervollständigen das Feld. Self-Hosting verändert die Wirtschaftlichkeit — Budibase erlaubt etwa 20 Nutzer im kostenlosen Self-Hosted-Tier gegenüber fünf bei Retool, mit enthaltenem SSO und Einbettung.

Aber Self-Hosting ist nicht reibungslos: Man braucht das technische Know-how zum Bereitstellen, Warten und Skalieren, kostenpflichtige Tiers sperren weiterhin Premium-Funktionen, und die meisten dieser Tools behalten dieselbe Drag-and-Drop-Architektur bei — man erbt also sowohl die Grenze als auch den Aufwand für eine eigene Datenbank, nur ohne die Rechnung pro Platz.

KI-nativ versus nachträglich aufgesetzte KI

Die Trennlinie 2025–2026 in diesem Markt verläuft zwischen Plattformen, die rund um KI gebaut sind, und solchen, die KI-Funktionen auf eine bestehende Low-Code-Architektur aufsetzen. Retool hat KI-Agenten und KI-Workflows ergänzt; Budibase hat LLM-verbundene Workflows und einen KI-Cron-Generator hinzugefügt. In beiden Fällen ist KI ein aufgesetzter Knoten mit eigenem Credit-Pool, der neben einem Canvas sitzt, der vor der KI-Ära entworfen wurde. Das funktioniert für einfache Fälle wie „dieses Feld zusammenfassen“, ist aber nicht dasselbe wie eine App, in der der Aufruf eines Modells eine erstklassige Primitive im Code ist.

Wo osFoundry passt

osFoundry kehrt das Low-Code-Modell um. Es baut interne Apps als echten, eigenen Code mit vollständig enthaltenem Backend — Postgres pro App, Secrets, KV, Cron, Serverless-Funktionen und eine Subdomain —, sodass es weder den Aufwand für eine eigene Datenbank noch eine Grenze gibt, der man entkommen müsste, denn der Code selbst ist der Escape Hatch. Es ist KI-nativ statt nachträglich aufgesetzter KI: invokeAI ist ein erstklassiger Aufruf im App-Code, kein separater Credit-Pool. Und die Abrechnung erfolgt nutzungsbasiert, nicht pro Platz, sodass das Hinzufügen von Betrachtern oder Buildern keine Pro-Kopf-Rechnung vervielfacht — genau das ist die Kostenfalle des Platzmodells. Man tauscht einen Drag-and-Drop-Canvas gegen echten Code und bekommt dafür Backend, KI und Daten an einem Ort, den man exportieren kann.

Frequently asked questions

Was ist die beste selbstgehostete Alternative zu Retool?: Unter den Drag-and-Drop-Buildern ist Appsmith die größte Open-Source-Option, gefolgt von ToolJet, Budibase und Lowcoder — alle selbst hostbar. Wer die Drag-and-Drop-Grenze ganz vermeiden will, findet in einer code-zentrierten Plattform, die echte Apps mit enthaltenem Backend (Datenbank, Secrets, Cron, Funktionen) baut, ein anderes Modell, das den Aufwand für eine eigene Datenbank beseitigt. Die Wahl hängt davon ab, ob man einen visuellen Canvas oder echten Code bevorzugt.
Warum ist Retool so teuer?: Weil pro Platz abgerechnet wird und Betrachter mitzählen. Im Business-Plan kostet ein Builder $50/Nutzer/Monat und ein interner Nutzer $15/Nutzer/Monat, zuzüglich gemessener Workflow-Ausführungen, KI-Credits und Agentenstunden. Die Kosten skalieren mit der Zahl der Personen, die die Tools nutzen, nicht nur mit denen, die sie bauen — Erfolg macht sie also teurer.
Benötigen Open-Source-Builder für interne Tools eine eigene Datenbank?: Die meisten schon. Drag-and-Drop-Builder sind eine Schnittstellenschicht, die sich mit Daten verbindet, die anderswo liegen, daher werden Datenbank, Authentifizierung, Secrets und Scheduling separat bereitgestellt und betrieben. Eine Plattform, die eine Datenbank pro App, Secrets und Cron enthält, beseitigt diesen operativen Aufwand vollständig.
Können Low-Code-Tool-Builder echten Quellcode exportieren?: Normalerweise nicht sauber. Die App-Logik steckt im proprietären Format des Builders, und nur wenige können menschenlesbaren Quellcode exportieren, was die Migration mühsam macht. Wenn Vendor-Lock-in vermieden werden soll, empfiehlt sich eine Plattform, bei der das Ergebnis echter Code plus eine Standard-Datenbank ist, die man mitnehmen kann.
Was passiert, wenn man die Grenzen eines Drag-and-Drop-Builders erreicht?: Man greift auf einen Escape Hatch zurück — einen benutzerdefinierten Code-Block —, der oft auf clientseitiges JavaScript, Inline-CSS und eine Workflow-Oberfläche beschränkt ist, die mit wachsender Logik unhandlich wird. Die Grenze zeigt sich typischerweise bei individuellen Datentransformationen, bei Integrationen, die einen gehosteten Server erfordern, und bei UI jenseits der Standardkomponenten. Eine code-zentrierte Plattform stößt nie an diese Grenze, weil sie als Code startet.
Sind Appsmith, ToolJet oder Budibase wirklich kostenlos selbst zu hosten?: Der Open-Source-Kern ist kostenlos, und Self-Hosting erhöht die Limits kostenloser Nutzer (Budibase erlaubt 20 Nutzer gegenüber 5 bei Retool). Einrichtung, Wartung und Skalierung übernimmt man aber selbst, und kostenpflichtige Tiers sperren weiterhin Premium-Funktionen und Creator-Preise. Kostenlos bezieht sich auf die Lizenz, nicht auf die Gesamtbetriebskosten.
Was ist der Unterschied zwischen einem KI-nativen Builder und einem, bei dem KI nachträglich ergänzt wurde?: Ein Builder mit nachträglich aufgesetzter KI fügt einen KI-Knoten und einen Credit-Pool neben einem Canvas hinzu, der vor der KI-Ära entworfen wurde — ausreichend für einfache feldbasierte Aufgaben. Eine KI-native Plattform behandelt den Aufruf eines Modells als erstklassige Primitive im App-Code, sodass KI in die Logik des Tools eingewoben ist, statt in einem separaten Block zu sitzen.