Baserow 2026 selbst hosten: Daten, URLs und Backups aus einer Hand

Ein Baserow-Container kann grün sein, während die für Benutzer wichtige Funktion trotzdem fehlschlägt. Bei Baserow besteht dieser verborgene Fehler meist darin, dass sich die öffentliche URL ändert, nachdem Benutzer bereits Freigabe- und Callback-Links erzeugt haben. In dieser Anleitung gilt folgende Abnahmetest als Maßstab: „Eine Datenbank und eine Ansicht erstellen, eine CSV-Datei importieren, Zeilen aus zwei Sitzungen bearbeiten und eine Datei hochladen, bevor der all-in-one-Stack neu gestartet wird.“ Die Bereitstellung wird von diesem Ergebnis aus rückwärts geplant.

Baserow übernimmt eine bestimmte Rolle im Stack: Airtable-ähnliche Datenbanken auf Basis von Postgres und Redis. Die Frage für den Produktivbetrieb lautet daher nicht, ob Port 80 einmal antwortet, sondern ob Zustand, Abhängigkeiten und öffentliche Adresse nach einem Neustart, Update und Restore weiterhin zusammenpassen.

Wovon Baserow abhängt

Prozessgesundheit und Produktgesundheit sind bei Baserow zwei verschiedene Dinge. Port 80 kann antworten, während die Transaktion aus Sicht des Benutzers weiterhin fehlschlägt. Die lokale Laufzeitanforderung ist ausreichend Arbeitsspeicher für das gebündelte Postgres, Redis, Backend und die Worker. Halte den Lebenszyklus explizit, damit das Verschieben von Baserow zwischen Hosts nicht unbemerkt das Verhalten ändert.

Führe diese Bereitschaftsprüfung nach wichtigen Konfigurationsänderungen durch: Eine Datenbank und eine Ansicht erstellen, eine CSV-Datei importieren, Zeilen aus zwei Sitzungen bearbeiten und eine Datei hochladen, bevor der all-in-one-Stack neu gestartet wird. Halte aufwendige externe Prüfungen aus Liveness-Probes heraus, damit ein Ausfall eines Providers keine Neustartschleife auslöst. Bei der Kapazitätsplanung sollten gebündeltes Postgres, Redis, Celery-Worker, Zeilenanzahl, Importgröße und die Anzahl gleichzeitiger Bearbeiter berücksichtigt werden. Das bildet die tatsächliche Belastung von Baserow besser ab als reine Seitenaufrufe.

Eine Docker-Basis für Baserow

Der folgende Befehl macht die Container-Grenze sichtbar, ohne vorzugeben, jeden externen Dienst bereitzustellen.

docker run -d \
  --name baserow \
  --restart unless-stopped \
  -p 127.0.0.1:80:80 \
  -v baserow-data:/baserow/data \
  -e SECRET_KEY=replace-with-a-long-random-value \
  baserow/baserow:latest

Bevor du den Ingress öffnest, prüfe die aufgelöste Umgebung, Mounts und Listener. Bestätige die lokale Voraussetzung vor der Freigabe: ausreichend Arbeitsspeicher für das gebündelte Postgres, Redis, Backend und die Worker. Ein erfolgreicher Start ist erst erreicht, wenn du eine Datenbank und eine Ansicht erstellen, eine CSV-Datei importieren, Zeilen aus zwei Sitzungen bearbeiten und eine Datei hochladen kannst, bevor der all-in-one-Stack neu gestartet wird – nicht schon dann, wenn docker ps den Status Up ausgibt.

Domains, Proxy-Header und Port 80

Stelle Baserow unter einem einzigen HTTPS-Hostnamen bereit und halte den direkten Zugriff auf Port 80 privat. Setze BASEROW_PUBLIC_URL auf den exakt erreichbaren externen Origin. So verhinderst du, dass Browser und API-Clients zwei konkurrierende Adressen kennenlernen.

Führe von einem sauberen Client aus die bekannte Transaktion durch und untersuche die erste fehlschlagende Anfrage. Wenn DNS oder TLS fehlerhaft sind, verwende die Anleitung für benutzerdefinierte Domains. Behandle „Die öffentliche URL ändert sich, nachdem Benutzer Freigabe- und Callback-Links erzeugt haben“ als separate Diagnose auf Anwendungsebene, sobald die Route nachweislich funktioniert.

Sichere den Zustand, den Baserow nicht wiederherstellen kann

Definiere Recovery Point und Recovery Time für Baserow anhand des gesamten Verzeichnisses /baserow/data und regelmäßiger logischer Datenbankexporte. Binde /baserow/data vor dem Bootstrap ein, schreibe harmlose Beispieldaten und ersetze den Container, um zu beweisen, dass dieser Pfad tatsächlich persistent ist. Ein Named Volume löst die Persistenz bei erneuten Deployments, schützt aber nicht vor einer Kompromittierung oder dem Verlust des Servers.

Baue eine saubere Restore-Umgebung auf, verwende dieselbe festgelegte Anwendungsversion und beweise, dass Tabellen, Ansichten, Benutzer, Automatisierungen und Dateien aus dem vollständigen Backup von /baserow/data wiederhergestellt werden. Dokumentiere Befehle, Anpassungen der Besitzrechte und die benötigte Zeit. Die Backup-Anleitung bietet dafür einen sinnvollen Standard: Ein Backup gilt erst nach einem Restore als vertrauenswürdig, nicht bereits nach dem Upload.

Gib Baserow nicht den gesamten Host

Analysiere die Aktionen, die Baserow ausführt, und nicht nur sein Login-Formular. Der risikoreiche Fehler besteht hier darin, das all-in-one-Image ohne Backup-Plan für die darin gebündelten Dienste zu verwenden. Setze diese Grenze um: Deaktiviere die Registrierung, wenn dies angebracht ist, bewahre SECRET_KEY auf und beschränke öffentliche geteilte Ansichten auf die vorgesehenen Daten.

Generiere SECRET_KEY einmalig, halte den Wert aus Git heraus und bewahre ihn zusammen mit dem Recovery-Manifest auf, da eine Änderung verschlüsselten oder signierten Anwendungszustand ungültig machen kann. Behebe einen Berechtigungsfehler nicht dadurch, dass du den Container als root ausführst oder den Host weitreichend mountest. Auch Ressourcenlimits gehören zum Sicherheitskonzept, wenn gebündeltes Postgres, Redis, Celery-Worker, Zeilenanzahl, Importgröße und die Anzahl gleichzeitiger Bearbeiter von Benutzern beeinflusst werden können.

Logs, die die nächste Frage beantworten

Ein inaktiver Health Check sagt über Baserow nur wenig aus. Beobachte gebündeltes Postgres, Redis, Celery-Worker, Zeilenanzahl, Importgröße und die Anzahl gleichzeitiger Bearbeiter und löse beim Symptom aus, das Benutzer tatsächlich erleben: dem Fehlschlagen der Aktion „Eine Datenbank und eine Ansicht erstellen, eine CSV-Datei importieren, Zeilen aus zwei Sitzungen bearbeiten und eine Datei hochladen, bevor der all-in-one-Stack neu gestartet wird“. Halte Liveness lokal und kostengünstig; Readiness darf Migrationen oder Initialisierung melden, ohne eine Neusturmschleife auszulösen.

Der kritische Bereich bei Upgrades besteht darin, dass das all-in-one-Image mehrere Dienste gemeinsam aktualisiert. Deshalb müssen Datenbank- und Anwendungsmigrationen anhand von Snapshots erprobt werden. Lies die Release Notes, erstelle einen Snapshot des Zustands, stelle die Zielversion gegen eine wiederhergestellte Kopie bereit und wiederhole die Abnahmetransaktion. Wenn sich die öffentliche URL ändert, nachdem Benutzer Freigabe- und Callback-Links erzeugt haben, ordne die Client-Anfrage dem ersten relevanten Anwendungslog zu, statt blind den Zustand zu löschen oder Weiterleitungen hinzuzufügen.

Fünf Prüfungen, die aussagekräftiger sind als der Container-Health-Check

Erstelle vor dem ersten Einsatz durch echte Benutzer ein Release-Arbeitsblatt für Baserow. Es muss das festgelegte Image, Port 80, den kanonischen Origin, persistente Pfade und die zuständige Person für ausreichend Arbeitsspeicher für das gebündelte Postgres, Redis, Backend und die Worker nennen. Füge das erwartete Ergebnis dieser Transaktion hinzu: Eine Datenbank und eine Ansicht erstellen, eine CSV-Datei importieren, Zeilen aus zwei Sitzungen bearbeiten und eine Datei hochladen, bevor der all-in-one-Stack neu gestartet wird.

Verwende das Arbeitsblatt nach einem normalen Austausch des Containers und nach einem sauberen Restore. Die Wiederherstellung gilt nur dann als erfolgreich, wenn Tabellen, Ansichten, Benutzer, Automatisierungen und Dateien aus dem vollständigen Backup von /baserow/data zurückkehren. Erfasse außerdem einen kurzen Ressourcenverlauf für gebündeltes Postgres, Redis, Celery-Worker, Zeilenanzahl, Importgröße und die Anzahl gleichzeitiger Bearbeiter. Bewahre ihn neben dem Release auf, damit künftige Kapazitätsänderungen mit derselben Arbeitslast verglichen werden können.

Füge einen kontrollierten Fehlerfall hinzu: Sende harmlose Eingaben nahe dem Ressourcen- oder Formatlimit, das mit dieser Grenze verbunden ist: Die öffentliche URL ändert sich, nachdem Benutzer Freigabe- und Callback-Links erzeugt haben. Bestätige, dass Baserow das Problem an der richtigen Grenze meldet, stelle die gültige Bedingung wieder her und führe die Transaktion erneut aus. Damit wird die Sichtbarkeit von Fehlern geprüft, nicht nur der Erfolg, und verhindert, dass eine gesund aussehende Oberfläche einen fehlerhaften Worker, Callback oder eine fehlerhafte Datenbankverbindung verbirgt.

Binde Baserow in den Lebenszyklus von Dockup ein

Das One-Click-Deployment von Baserow durch Dockup sollte einen sicheren Austausch ermöglichen: Die Route zeigt weiterhin auf Port 80, Secrets werden nicht in das Image eingebaut und persistente Pfade stehen im neuen Container wieder zur Verfügung. Dasselbe Deployment kann auf Dockup-Compute oder einer angebundenen Maschine ausgeführt werden.

Schließe die anwendungsspezifischen Arbeiten ab, indem du die lokale Voraussetzung bestätigst – ausreichend Arbeitsspeicher für das gebündelte Postgres, Redis, Backend und die Worker –, die kanonische öffentliche Adresse anwendest und diese Abnahmeprüfung ausführst: Eine Datenbank und eine Ansicht erstellen, eine CSV-Datei importieren, Zeilen aus zwei Sitzungen bearbeiten und eine Datei hochladen, bevor der all-in-one-Stack neu gestartet wird. Ergänze das Ergebnis des Restores im Runbook, bevor die ersten echten Benutzer starten.

Häufig gestellte Fragen

Was benötigt Baserow für einen produktiven Betrieb?

Route den Baserow-Container über Port 80 durch einen einzigen HTTPS-Origin. Die lokale Laufzeitanforderung ist ausreichend Arbeitsspeicher für das gebündelte Postgres, Redis, Backend und die Worker. Erkläre Baserow erst dann für bereit, wenn du eine Datenbank und eine Ansicht erstellen, eine CSV-Datei importieren, Zeilen aus zwei Sitzungen bearbeiten und eine Datei hochladen kannst, bevor der all-in-one-Stack neu gestartet wird.

Welche Baserow-Daten gehören in ein Backup?

Sichere /baserow/data persistent und nimm den gesamten Verzeichnisbaum /baserow/data sowie regelmäßige logische Datenbankexporte in dasselbe Recovery-Manifest auf. Ein sauberer Baserow-Restore ist erst dann erfolgreich, wenn Tabellen, Ansichten, Benutzer, Automatisierungen und Dateien aus dem vollständigen Backup von /baserow/data wiederhergestellt werden.

Benötigt Baserow HTTPS hinter einem Reverse Proxy?

Verwende HTTPS für den öffentlichen Baserow-Origin und halte Port 80 auf der internen Route. Wende die Baserow-Einstellung korrekt an: Setze BASEROW_PUBLIC_URL auf den exakt erreichbaren externen Origin. Bei Baserow schützt HTTPS Zugangsdaten oder Benutzerinhalte bei der Übertragung und sorgt dafür, dass das Origin-abhängige Verhalten des Clients konsistent bleibt.

Wie sollte ein Baserow-Upgrade getestet werden?

Stelle den aktuellen Baserow-Zustand in einem isolierten Deployment wieder her, wende die Kandidatenversion an und wiederhole die Abnahmetransaktion. Achte besonders darauf, dass das all-in-one-Image mehrere Dienste gemeinsam aktualisiert. Deshalb müssen Datenbank- und Anwendungsmigrationen anhand von Snapshots erprobt werden. Bewahre das vorherige Baserow-Image auf, bis die Grenzen für Datenmigration und Rollback geklärt sind.