Skip to main content
Durch das Self-hosting von Teable werden vier Plattformen in einer bereitgestellt:
  • Eine sichere, skalierbare Agenten-Sandbox — jede KI-Sitzung wird in einem eigenen isolierten Container ausgeführt, bei Bedarf gestartet und nach Ende der Sitzung entfernt.
  • Eine ressourceneffiziente Plattform zur App-Bereitstellung — jede App, die Ihr Team erstellt und veröffentlicht, wird in einem eigenen schlanken, langlebigen Container ausgeführt.
  • Eine KI-Workflow-Engine — Automatisierungen, die durch Änderungen an Datensätzen, Zeitpläne und Webhooks ausgelöst werden, mit KI-Schritten, direkt dort ausgeführt, wo Ihre Daten liegen.
  • Eine umfassende Datenbank-Kollaborationsplattform auf PostgreSQL — Tabellen, Ansichten und API.
Das Self-hosting von Teable bündelt Ihre eigene Rechenleistung in einer agentenfähigen, vollständig kontrollierten Produktivitätsumgebung — und stellt KI allen Mitgliedern Ihres Teams zur Verfügung. Diese Seite erläutert die zugrunde liegenden Dienste und ihr Zusammenspiel. Die bereitstellbaren Ressourcen (Compose-Dateien, Helm-Chart, Werte) befinden sich in teableio/teable-deployment.
KI-Funktionen sind ab dem Self-hosted-Business-Plan verfügbar.

​
Was bei einer Bereitstellung ausgeführt wird

Die letzten vier bilden die Runtime-Ebene. Die Bereitstellungsressourcen installieren all dies als eine Plattform.

​
So passt alles zusammen

Die Teable-App kommuniziert über eine Verbindung mit der Runtime-Ebene: dem Infra Service (TEABLE_INFRA_API_URL / TEABLE_INFRA_API_KEY). Alles dahinter ist intern. Zwei Arten von Workloads erledigen die eigentliche Arbeit — und sie beanspruchen Ihre Maschine:
  • Sandboxes. Jeder KI-Chat bzw. jede App-Builder-Sitzung erhält einen eigenen isolierten Container, der beim Beginn der Sitzung gestartet und nach ihrem Ende entfernt wird. Dies ist die Hauptlast der Plattform und sie tritt schubweise auf: Dimensionieren Sie Ihre Maschine nach der maximalen Anzahl gleichzeitiger KI-Sitzungen, nicht nach der Benutzerzahl (Ressourcenlimits pro Sandbox können in der Systemverwaltung festgelegt werden).
  • Bereitgestellte Apps. Jede App, die jemand veröffentlicht, wird in einem eigenen langlebigen Container ausgeführt, der unter *.app.<domain> bereitgestellt wird. Sandboxes kommen und gehen; bereitgestellte Apps summieren sich und laufen dauerhaft weiter.
Die anderen Dienste unterstützen dies: Das Erstellen erfolgt innerhalb der Sandbox der Sitzung, die Git-Registry und der Objektspeicher bewahren die erzeugten Inhalte (Quellcode und Build-Artefakte) auf, und das Gateway leitet jede Browseranfrage an die richtige Sandbox oder App weiter.

​
Eine Domain, vier DNS-Einträge

Alles wird unter einer Basisdomain bereitgestellt — typischerweise einer Ihrer Subdomains, beispielsweise teable.example.com: Jeder Name ist lediglich ein Standardwert, und jeder Hostname kann individuell überschrieben werden (siehe das Wertebeispiel im Bereitstellungs-Repository).

​
Versionierung

Die Plattform wird als Plattform-Releases (v<year>.<month>.<seq>) des Bereitstellungs-Repositorys veröffentlicht:
  • Ein Release-Tag ist ein verifizierter Snapshot: versions.yaml fixiert die exakte Version jeder Komponente, und die CHANGELOG.md des Repositorys beschreibt, was sich geändert hat und was Sie gegebenenfalls tun müssen.
  • Der Branch main des Repositorys ist die fortlaufend aktualisierte neueste Version.
  • Das enthaltene doctor-Skript vergleicht, was Ihre Bereitstellung tatsächlich ausführt, mit dem Release und meldet eines von drei Ergebnissen: kompatibel, Teable-App aktualisieren oder eine unbekannte (nicht verifizierte) Kombination.
Die Teable-App hat eine eigene Release-Reihe (datumsbasierte Tags; latest ist der stabile Kanal) — siehe Versionsaktualisierung. Jedes Plattform-Release nennt die App-Versionen, mit denen es verifiziert wurde, und doctor prüft dies für Sie. Der Sandbox-Agent hinter den KI-Sitzungen folgt immer eigenständig der Version der App — es gibt nichts Zusätzliches zu aktualisieren oder zu verwalten.

​
Bereitstellen

Beide Wege installieren die gesamte Plattform und werden im Bereitstellungs-Repository durchgängig beschrieben:

Docker-Komplettlösung

Alles auf einer Maschine — erste vollständige Bereitstellung, Modus local oder server.

Kubernetes (Helm)

Ein einzelnes Helm-Chart auf einem vorhandenen Cluster; nur global.baseDomain ist erforderlich.
Sie benötigen noch keine KI? Sie können nur die App mit PostgreSQL, Redis und Speicher — eine eigenständige Bereitstellung (Docker-Bereitstellung) — ausführen und die Runtime-Ebene später mit Ihren vorhandenen Daten verbinden. Verwandte Themen, die alle im Bereitstellungs-Repository gepflegt werden:
  • Teable eigenständig bereits im Einsatz? Ihre Daten bleiben erhalten — die Runtime-Ebene wird daneben installiert: Migrationsleitfaden
  • Unternehmensinterne Zertifikate? Wenn Ihre Domain eine private oder unternehmenseigene CA verwendet, müssen Sandboxes angewiesen werden, ihr zu vertrauen — private-ca.md
  • Dimensionierung, Versionen und Mirrors: VERSIONS.md · images/README.md
  • Wenn etwas fehlschlägt: Führen Sie zuerst doctor aus, anschließend TROUBLESHOOTING.md
Verbinden Sie die Teable-App nach der Bereitstellung über TEABLE_INFRA_API_URL / TEABLE_INFRA_API_KEY mit der Runtime-Ebene (dies wird in den Bereitstellungsanleitungen beschrieben), und legen Sie anschließend Ressourcenlimits in der Systemverwaltung → Sandbox-Agent fest.
Zuletzt geändert am 4. September 2026