🇩🇪 SeaTable 6.0 Beta: Jetzt verfügbar für Self-Hoster!

Schon lange ist SeaTable eine smarte Lösung. Mit Version 6.0 wird SeaTable intelligent!

Das neue Major Release verbindet SeaTables bewährte Self-Hosting-No-Code-Plattform mit moderner künstlicher Intelligenz (KI). Als “the world’s leading AI-powered self-hosted no-code solution” bietet SeaTable in der neuen Version innovative KI-Funktionen ohne Abstriche bei Datensouveränität und Datenschutz.

Natürlich bleibt die Version 6.0 auch an anderer Stelle nicht hinter den Erwartungen an ein Major Release zurück und bietet zahlreiche Verbesserungen und neue Funktionen. Eine komplette Liste der Änderungen gibt’s - wie immer - im Changelog.

KI-Funktionen in Automationen

Der Automations-Wizard wurde grundlegend überarbeitet: intuitive
Bedienung, mehr Komfort und als Highlight der neue “Run AI”-Schritt.

Damit integriert Ihr KI direkt in eure Workflows – etwa zur Informationsextraktion aus Dokumenten, Inhaltszusammenfassungen oder Übersetzungen. Alle Funktionen sind so gestaltet, dass sie auch für KI-Neulinge problemlos nutzbar sind.

Datenschutz: KI made in Europe

Datenschutz wird bei SeaTable groß geschrieben. Für SeaTable Cloud werden wir unseren eigenen KI-Server bei Hetzner in Deutschland betreiben. So landen garantiert keine Daten bei US-Anbietern wie Google oder OpenAI. Natürlich könnt Ihr das auch! Wer SeaTable selbst hostet, kann praktisch jedes beliebige LLM anbinden und behält so die volle Kontrolle darüber, wer die eigenen Daten verarbeiten darf.

Im Blogartikel KI unterstützte Automationen: Das Highlight von SeaTable Cloud v6.0 gehen wir detaillierter auf Motivation, Umsetzung und Ausblick ein.

Weitere Highlights

Doch das ist bei weitem nicht alles. Freut euch auf viele weitere Neuerungen:

  • Neue Ansichtenstypen Kanban, Kalender und Galerie: Teile Kanbanboards, Kalender und Bilderübersichten wie jede andere Ansicht
  • Neuer Spaltentyp Telefonnummer: Speichere Telefonnummern genauso einfach wie E-Mail-Adressen und URLs
  • Vereinfachte Dateneingabe in Datumsfelder: Spare Zeit durch die verkürzte Eingabe von Datumsangaben
  • Big-Data-Export Option: Exportiere Deine Big-Data-Daten mitsamt Deiner Base und genauso einfach
  • Komplexe Filter im App Builder: Filtere Deine Daten wie nie zuvor – jetzt auch in den voreingestellten Filtern, auf der Tabellenseite und in den Einstellungen für Verknüpfungen
  • Schreibgeschützte Spalten auf allen Seitentypen: Stelle eine oder mehrere Spalten auf nur-lesen, egal ob auf einer Tabellen-, Kanban, Kalender-, oder Zeitstrahlseite

Gestaffelter Release: Was ändert sich?

Neu: Wir splitten den Rollout in zwei Phasen.

Ab sofort ist SeaTable 6.0 als Beta für alle Self-Hoster inklusive aktualisierter Admin- und API-Doku verfügbar (inkl. Anleitung zur eigenen KI-Server-Installation).

Das Update von SeaTable Cloud auf SeaTable 6.0 folgt in ca. zwei Wochen. Das gestaffelte Vorgehen ermöglicht schnelleren Support für Self-Hoster, gibt uns die Chance, eure Rückmeldungen direkt in die Cloud-Version einfließen zu lassen und erlaubt uns eine bessere Abstimmung der internen Aktivitäten. Das Cloud-Release ist für Mitte Oktober geplant.

Wichtig: Zum Start sind die neuen KI-Funktionen Enterprise-Kunden vorbehalten. Ab Version 6.1 werden Automationen (inklusive KI-Funktionen) in begrenztem Umfang auch Plus- und Free-Accounts zur Verfügung stehen.


Feedback und Diskussionen zum neuen Release sind wie immer herzlich
willkommen! Testet die Beta, teilt Erfahrungen und Fragen gerne direkt hier im Forum.

5 Likes

Eine klasse Arbeit! Wir sind sehr gespannt, welche Möglichkeiten uns das eröffnen wird!

3 Likes

Moin, ich kann python Scripte die mit 5.x.x noch liefen nicht mit 6.0.6 Enterprise starten.

Log

==> logs/dtable_web.log <==
[2025-10-03 20:41:35] [WARNING] log.py[line:246] Forbidden: /api/v2.1/dtable/12b267de-8e48-4f36-830d-04959394b10d/run-script/KYC1.py/

Bist du dem empfohlene Update-Ablauf gefolgt und hast die yml Dateien aktualisiert? Wahrscheinlich nicht.
Es gibt eine neue env variable in seatable-server.yml:

- ENABLE_PYTHON_SCRIPT=${ENABLE_PYTHON_SCRIPT:-true}

Füge diese hinzu und Python Skripte sollten wieder gehen.

ENABLE_PYTHON_SCRIPT ist auf true gesetzt. Das mit einem Bugfix Update ein Breaking Change mitkam hatten wir in dem anderen Topic bereits erfasst.

Ich finde offen gesagt echt mies wie ihr Updates veröffentlicht. Ich möchte kein Caddy verwenden, muss es aber. Alternativ habe ich keinen echten Support, weil eigene Update Methode. Das verstehe ich auch, weil ihr könnt ja nicht alles supporten. Jetzt muss ich vor jedem Update die Files im Detail prüfen um festzustellen ob da wieder Breaking Changes drin sind, da ihr das nicht sauber kommuniziert.

Ich finde Seatable großartig, das was ihr bei Updates macht aber gar nicht.

Sorry. Ich musste das mal loswerden. Nachher werde ich mich mit Caddy beschäftigen (müssen).

Ich kann deine Kritik nicht nachvollziehen. Wir liefern bei einem Update aktualisierte YML Dateien aus und sämtliche Änderungen lassen sich zu jeder Zeit über das Repository nachvollziehen: History for compose/seatable-server.yml - seatable/seatable-release · GitHub.

Wie du siehst, gab es genau vier Commits auf seatable-server.yml zwischen 5.3 und 6.0.

Weiterhin kannst du jeden beliebigen Reverse Proxy verwenden, den du möchtest. Die Details sind alle im Admin-Handbuch im Bereich Custom Reverse Proxy beschrieben.


Wie sollen wir deiner Meinung nach die Updates ausliefern? Gerne kannst du deine Verbesserungsvorschläge hier im Forum posten oder mir per PM schicken.

Hallo,

vielen Dank für die Umsetzung der Version 6.0 – wir haben diese bereits erfolgreich im Einsatz.

Gerne möchten wir den neuen Spaltentyp Telefonnummer auf eine bestehende Spalte anwenden. Beim Versuch erhalten wir jedoch folgende Fehlermeldung: Die Operation ist nicht möglich, weil die Größe der Operation das Limit übersteigt.

Können Sie uns bitte dabei unterstützen bzw. eine Lösungsmöglichkeit aufzeigen?

Vielen Dank im Voraus!

Ich kann dieses Problem nicht nachstellen.

  • Wieviele Zeilen hat die Tabelle in der Sie das tun wollen?

Als Workaround kann ich aber folgendes anbieten:

  • neue Hilfstelefonspalte anlegen
  • Werte von alter Spalte in neue Spalte kopieren (evtl. in mehreren Teilschritten)
  • Ursprungsspalte leeren und dann umwandeln
  • Werte wieder zurückkopieren
  • Hilfstelefonspalte löschen

Vielen Dank, das war die Lösung!

Wie sollen wir deiner Meinung nach die Updates ausliefern?

  1. So, dass ein Bugfix kein Breaking Change mitbringt. ( updated to 5.3.12 · seatable/seatable-release@5e10479 · GitHub )
  2. Gerne auch ohne harte dependencies (Caddy)
  3. Vielleicht Image und compose trennen? Dann wäre im Image sicherlich aufgefallen, dass die env var nun vorhanden sein muss.

Ich brauche keine Unmengen an docker compose files die ich sowieso nicht verwende. Das funktioniert gut für kleine Selbsthoster die ein schweißer Taschenmesser möchten und die sich wenig Gedanken machen möchten. Aktuell ist es keine echte Enterprise Software für On-Prem.

Was mache ich, wenn ich mal in K8s laufen möchte? Wenn ich skalieren möchte? Valkey anstatt Redis? GaleraDB? Das wäre alles irgendwie möglich, jedoch durch die Art wie ihr updates veröffentlicht bringt das einen unfassbar großen Aufwand mit. Wenn man diesen Aufwand geht bewegt man sich sicherlich außerhalb des supporteten Deployments.

Das soll kein Rant sein. Ich finde die Software großartig. Ich denke das habe ich durch diverse Beiträge hier im Forum auch gezeigt.

Übrigens funktionieren die Python Scripte immer noch nicht. Die Fehlermeldung steht ja hier bereits im Thread. Die Variable ist gesetzt.

Können wir so nicht nachvollziehen. Lag vielleicht - wie auch Dein aktuelles Problem - an Deinem Custom Setup.

Caddy ist keine harte Dependency. Wie kommst Du drauf? Wir haben dem Thema eine eigene Seite im Handbuch gewidmet: Custom Reverse Proxy - SeaTable Admin Manual Wir müssen - wie Du selbst sagst - den Spagat schaffen. Das Deployment muss einfach, aber auch skalier- und anpassbar sein. Das wir es nicht allen recht machen können, liegt in der Natur der Sache.

Wenn Du hier einen guten Vorschlag machst, dann können wir uns das anschauen. Aktuell verstehe ich nicht, was Du meinst.

Finally:

Das ist der springende Punkt! Wir sind kein Microsoft. Wir können das ganze nur managen, indem wir Komplexität hart reduzieren. Wie es mit SeaTable 10.0 aussieht, bleibt abzuwarten.

1 Like

Das Image wurde von 5.3.10 auf 5.3.12 aktualisiert. Das darf kein Breaking Change nach semver sein. Richtig wäre es gewesen, eine nicht existente Variable im Image als true zu interpretieren wie es vorher der Fall war. Der Fehler war in meinem Deployment, lag aber nicht an mir. Dieses Mal ebenfalls nicht. log.py darf da wohl etwas nicht. Siehe die Fehlermeldung die ich gepostet habe.

Caddy ist keine harte Dependency. Wie kommst Du drauf?

Teste ich. Mich stören die Massen an Caddy Labels.

Wenn Du hier einen guten Vorschlag machst, dann können wir uns das anschauen.

Image Update ist Image Update. Deployment Update ist Deployment Update. Warum müssen die beide gemeinsam aktualisiert werden?

Wir können das ganze nur managen, indem wir Komplexität hart reduzieren.

Genau da ist auch mein Punkt. Nur, wenn ihr Image und Deployment trennt, könnt ihr überhaupt saubere Software bauen die Bulletproof läuft, in jeder Umgebung.

Das Stable Release wurde am 4. November 2025 bereitgestellt.

Mehr Informationen zu SeaTable 6.0 unter SeaTable 6.0 out now!

@vqui ich bin weit davon entfernt, mich Deiner Kritik in ihrem generellen Scope und auch in der Heftigkeit anzuschließen. Im Gegenteil sehe ich - auch im persönlichen Aufwand bei den Updates - eine stetige Verbesserung bei den Deployments. Perfektion erwarte ich aber nicht, dazu ist Seatable zu jung und zu dynamisch.

Ich fühle mich Dir aber verbunden, als Enterprise-Level Self-Hoster mit dem Anspruch, dass die Architektur einer Software auf unsere Infrastruktur passen muss. Inklusive der Tatsachen, dass wir Traefik statt Caddy verwenden, eine interne CA, eine Corporate Firewall u.v.m.

Ich versuche mal, aus Deinen Kommentaren das Konstruktive rauszuziehen - oder das, was ich verstanden habe, weil ich bei einigen der Schlagworte auch nicht verstehe, was genau Du meinst. Kannst Du mir Rückmeldung geben, ob das so passt? Der angesprochene Aspekt ist mir wichtig genug, um das nicht untergehen zu lassen.

Mich stören die Massen an Caddy Labels.

Kann ich nicht nachvollziehen. Wir haben dieselbe Anzahl von Traefik-Labels, die wir hinzufügen. Die Caddies stören mich nicht. Ob ich die drin lasse und ignoriere, oder durch Traefik ersetze, ist eine Frage des Handlings unserer Deployment-Pipeline.

Image Update ist Image Update. Deployment Update ist Deployment Update.

Ich lese das im Zusammenhang mit dem Hinweis auf den “Breaking Change“ (Python-Scripte) so, dass neue ENV-Variablen sinnvolle non-breaking Defaults im Image (und nicht etwa in der Compose-Datei) enthalten soll? Kann ich nachvollziehen, wenn die Interpretation stimmt.

Ich sehe eine (guten) Trend weg von Config-Files zur Konfiguration (@rdb stimmt das?) per Environment. Der Weg ist noch nicht zuende, aber gerade beim Update von 4 auf 5 hat sich da enorm was getan.

Meine Wunschvorstellung wäre (heißt nicht, dass es nicht schon in Teilen vorhanden ist)

  • Konfiguration der Container komplett übers Environment
  • Konfigurationsvariablen umfangreich und explizit dokumentiert, inklusive Defaults, Breaking Changes, und Kennzeichnung von obsoleten / neuen Variablen
  • Sinnvolle (man kann es nicht jedem recht machen) Defaults im Image hinterlegt, und Log-Ausgabe im Container, wenn eine Variable nicht explizit konfiguriert ist (“VAR not configured, using default x“)

Momentan habe ich beim Update einiges an Aufwand, manuell die offizielle Compose mit meiner abzugleichen. Das ist aber auch der Tatsache geschuldet, dass ich in Git nicht versiert genug bin, um den Abgleich zu automatisieren. Mal schauen, wie es demnächst bei der 6.x läuft.

Aber Seatable braucht detailliertes Feedback aus Enterprise-Umgebungen, um auf die Bedürfnisse einzugehen. Ich hoffe, das wird als solches wahrgenommen.

2 Likes

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.