Teable mit Docker installieren: Postgres-native Airtable-Alternative selbst hosten

Wer strukturierte Daten im Team verwalten will, ohne Programmierkenntnisse zu benötigen und ohne monatliche SaaS-Kosten zu zahlen, stößt früher oder später auf Teable. Die quelloffene Anwendung (AGPL-3.0, 21.300+ GitHub-Stars) bietet ein tabellenkalkulationsähnliches Interface – Grid, Kanban, Galerie, Formular, Kalender – und speichert alle Daten nativ in PostgreSQL. Das bedeutet: direkter SQL-Zugriff, Kompatibilität mit BI-Tools wie Metabase oder Grafana und kein proprietäres Datenbankformat. Für DACH-Unternehmen, die Airtable aus Datenschutzgründen meiden oder schlicht die monatliche Rechnung sparen wollen, ist Teable eine ernsthafte Alternative. Diese Anleitung richtet sich an IT-Admins und ambitionierte Selfhoster, die Teable per Docker Compose auf einem beliebigen Linux-Host (Ubuntu/Debian, VPS, Heimserver oder NAS mit Docker-Support) installieren wollen.

Voraussetzungen

1. Docker Engine >= 24.x und Docker Compose Plugin >= 2.x (docker compose ohne Bindestrich) auf dem Host installiert – falls noch nicht vorhanden, hilft die Anleitung Docker und Docker Compose auf Linux installieren.
2. Linux-Host, VM oder NAS mit Docker-Support (Ubuntu 20.04 LTS oder neuer empfohlen).
3. Mindestens 4 GB RAM und 2 CPU-Kerne; 40 GB freier Speicherplatz. Unter 4 GB RAM drohen OOM-Kills, da PostgreSQL, Redis und die Node.js-App gleichzeitig laufen.
4. Öffentliche IP-Adresse oder Domainname für PUBLIC_ORIGIN; für lokale Tests genügt http://127.0.0.1:3000.
5. openssl für die Generierung sicherer Zufalls-Schlüssel (auf praktisch jedem Linux-System vorhanden).
6. Internetverbindung zum Pullen der Images: Teable (~583 MB), PostgreSQL (~500 MB), Redis (~50 MB).
7. Optional: Reverse Proxy (Caddy, Nginx oder Traefik) für HTTPS/TLS – ohne HTTPS funktioniert die Browser-Clipboard-API (Kopieren/Einfügen) nicht.

Schritt 1: Projektordner anlegen und Secrets generieren

Lege zunächst einen sauberen Projektordner an. Alle Dateien – compose.yaml und .env – gehören in dieses Verzeichnis.

mkdir -p /opt/teable
cd /opt/teable

Generiere jetzt drei Secrets auf einmal. Nur alphanumerische ASCII-Zeichen verwenden – Sonderzeichen wie @, # oder % brechen die Datenbank-URIs und verursachen Verbindungsfehler.

# PostgreSQL-Passwort (32 alphanumerische Zeichen)
openssl rand -base64 24 | tr -dc 'A-Za-z0-9' | head -c 32

# Redis-Passwort (32 alphanumerische Zeichen)
openssl rand -base64 24 | tr -dc 'A-Za-z0-9' | head -c 32

# SECRET_KEY (mind. 32 Zeichen)
openssl rand -base64 32

Notiere die drei Ausgaben – du trägst sie im nächsten Schritt in die .env-Datei ein.

Verifizieren: Führe ls /opt/teable aus – der Ordner ist leer, das ist korrekt. Die drei Secrets wurden im Terminal ausgegeben und sind bereit zum Eintragen.

Schritt 2: .env-Datei anlegen

Erstelle die Datei /opt/teable/.env und trage die generierten Secrets ein. PUBLIC_ORIGIN muss die exakte erreichbare URL enthalten – kein abschließendes Slash, Protokoll und Port inklusive.

# ── PostgreSQL ──────────────────────────────────────────────
POSTGRES_USER=teable
POSTGRES_DB=teable
POSTGRES_PASSWORD=DEIN_POSTGRES_PASSWORT_HIER
POSTGRES_HOST=teable-db
POSTGRES_PORT=5432

# ── Redis ───────────────────────────────────────────────────
REDIS_PASSWORD=DEIN_REDIS_PASSWORT_HIER
REDIS_HOST=teable-cache
REDIS_PORT=6379
REDIS_DB=0

# ── Teable App ──────────────────────────────────────────────
SECRET_KEY=DEIN_SECRET_KEY_MIND_32_ZEICHEN_HIER

# Exakte öffentliche URL – kein abschließendes /
# Lokal:   http://127.0.0.1:3000
# Server:  http://DEINE-IP:3000
# HTTPS:   https://teable.example.com
PUBLIC_ORIGIN=http://127.0.0.1:3000

# ── Verbindungs-URIs (nutzen obige Werte) ───────────────────
PRISMA_DATABASE_URL=postgresql://${POSTGRES_USER}:${POSTGRES_PASSWORD}@${POSTGRES_HOST}:${POSTGRES_PORT}/${POSTGRES_DB}
BACKEND_CACHE_PROVIDER=redis
BACKEND_CACHE_REDIS_URI=redis://default:${REDIS_PASSWORD}@${REDIS_HOST}:${REDIS_PORT}/${REDIS_DB}

# ── Zeitzone ────────────────────────────────────────────────
TIMEZONE=Europe/Berlin

Drei kritische Punkte, die häufig zu Fehlern führen:

1. PRISMA_DATABASE_URL muss das Schema postgresql:// verwenden – postgres:// führt zu einem Startfehler. Einige ältere Community-Anleitungen verwenden fälschlicherweise DATABASE_URL als Variablenname – nur PRISMA_DATABASE_URL ist korrekt.
2. BACKEND_CACHE_REDIS_URI muss den User default enthalten: redis://default:PASSWORT@HOST:PORT/DB – Redis 7.x erwartet dieses Format.
3. PUBLIC_ORIGIN falsch gesetzt (falscher Port, abschließendes Slash, http statt https) führt zu fehlschlagenden Datei-Uploads und leeren Vorschaubildern.

Verifizieren: Prüfe mit docker compose config im Projektordner, ob alle Variablen korrekt aufgelöst werden. Die Ausgabe zeigt die vollständige, interpolierte Konfiguration. Leere Werte bei PRISMA_DATABASE_URL oder SECRET_KEY deuten auf einen Tipp-Fehler in der .env hin.

Schritt 3: compose.yaml anlegen

Erstelle /opt/teable/compose.yaml mit folgendem Inhalt. Der Stack besteht aus drei Diensten: der Teable-App, PostgreSQL 15.4 und Redis 7.2.4. depends_on mit condition: service_healthy stellt sicher, dass Teable erst startet, wenn Datenbank und Cache erfolgreich ihre Healthchecks bestanden haben – ohne diese Bedingung schlägt der Start regelmäßig fehl.

services:
  teable:
    image: ghcr.io/teableio/teable:latest
    restart: always
    ports:
      - "3000:3000"
    volumes:
      - teable-data:/app/.assets:rw
    env_file:
      - .env
    environment:
      - TZ=${TIMEZONE}
    networks:
      - teable-standalone
    depends_on:
      teable-db:
        condition: service_healthy
      teable-cache:
        condition: service_healthy

  teable-db:
    image: postgres:15.4
    restart: always
    ports:
      - "42345:5432"
    volumes:
      - teable-db:/var/lib/postgresql/data:rw
    environment:
      - TZ=${TIMEZONE}
      - POSTGRES_DB=${POSTGRES_DB}
      - POSTGRES_USER=${POSTGRES_USER}
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
    networks:
      - teable-standalone
    healthcheck:
      test: ["CMD-SHELL", "sh -c 'pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}'"]
      interval: 10s
      timeout: 3s
      retries: 3

  teable-cache:
    image: redis:7.2.4
    restart: always
    expose:
      - "6379"
    volumes:
      - teable-cache:/data:rw
    networks:
      - teable-standalone
    command: redis-server --appendonly yes --requirepass ${REDIS_PASSWORD}
    healthcheck:
      test: ["CMD", "redis-cli", "--raw", "incr", "ping"]
      interval: 10s
      timeout: 3s
      retries: 3

networks:
  teable-standalone:
    name: teable-standalone-network
    driver: bridge

volumes:
  teable-data: {}
  teable-db: {}
  teable-cache: {}

Hinweise zur Konfiguration:

1. Das offizielle Image ist ghcr.io/teableio/teable:latest (GitHub Container Registry); alternativ funktioniert teableio/teable:latest von Docker Hub – beide Images sind identisch, die offizielle Dokumentation empfiehlt GHCR.
2. Redis-Port 6379 wird bewusst nur per expose (intern) bereitgestellt, nicht per ports nach außen gemappt – das entspricht der offiziellen Empfehlung und ist sicherer.
3. PostgreSQL ist auf Port 42345 nach außen erreichbar (für direkten DB-Zugriff mit Tools wie DBeaver oder TablePlus); du kannst diesen Port weglassen, wenn du keinen externen Zugriff benötigst.

Verifizieren: Führe erneut docker compose config aus. Die Ausgabe sollte alle drei Services, drei Volumes und das Netzwerk teable-standalone-network anzeigen – ohne Fehler oder Warnungen.

Schritt 4: Stack starten

Starte den Stack aus dem Projektordner heraus. Docker lädt beim ersten Start alle drei Images herunter (~1,1 GB gesamt), legt die Volumes an und startet die Container in der richtigen Reihenfolge.

docker compose up -d

Warte etwa 30–60 Sekunden, damit PostgreSQL initialisiert und Teable die Datenbankmigrationen durchführt. Beobachte den Fortschritt live:

docker compose logs -f teable

Warte auf eine Zeile wie Server running on port 3000 oder Listening on 0.0.0.0:3000. Brich die Log-Ausgabe mit Ctrl+C ab.

Verifizieren: Prüfe den Status aller Container:

docker compose ps

Erwartetes Ergebnis – alle drei Container sollten running (healthy) oder Up zeigen:

NAME             IMAGE                              STATUS
teable           ghcr.io/teableio/teable:latest     Up (healthy)
teable-db        postgres:15.4                      Up (healthy)
teable-cache     redis:7.2.4                        Up (healthy)

Teste zusätzlich per HTTP:

curl -I http://localhost:3000

Erwartet: HTTP/1.1 200 OK oder HTTP/1.1 302 Found (Weiterleitung zur Login-Seite).

Schritt 5: Erst-Einrichtung im Browser

Öffne http://DEINE-IP:3000 bzw. http://127.0.0.1:3000 in deinem Browser. Beim ersten Aufruf zeigt Teable einen Einrichtungsassistenten an, über den du deinen Admin-Account erstellst.

1. Gib E-Mail-Adresse und ein sicheres Passwort ein und bestätige die Registrierung.
2. Lege deine erste Organisation und einen ersten Bereich (Space) an – das ist die oberste Strukturebene in Teable.
3. Erstelle deine erste Datenbank und darin eine oder mehrere Tabellen.

Die Oberfläche ist an Airtable angelehnt: Spalten lassen sich typisieren (Text, Zahl, Datum, Auswahl, Verknüpfung, Formel usw.), Ansichten (Grid, Kanban, Galerie, Formular, Kalender) lassen sich per Klick wechseln. Da Teable PostgreSQL als Backend nutzt, kannst du gleichzeitig mit einem SQL-Client wie DBeaver über Port 42345 direkt auf die Daten zugreifen oder BI-Tools wie Metabase oder Grafana anbinden.

Verifizieren: Nach der Erst-Einrichtung solltest du eine leere Tabelle im Grid-View sehen. Erstelle eine Testspalte und trage einen Wert ein – der Eintrag muss nach einem Browser-Refresh noch vorhanden sein. Das bestätigt, dass PostgreSQL korrekt schreibt und die Daten persistent sind.

Schritt 6: HTTPS mit Reverse Proxy (optional, für Produktion empfohlen)

Für den Produktivbetrieb ist HTTPS aus zwei Gründen notwendig: Die Browser-Clipboard-API (großflächiges Kopieren/Einfügen in Teable) erfordert einen sicheren Kontext, und Passwörter sollten nie unverschlüsselt übertragen werden.

Für automatisches TLS ist Caddy die einfachste Wahl – eine vollständige Anleitung findest du unter Caddy als Reverse Proxy mit automatischem HTTPS. Alternativ eignet sich Traefik als Docker-Reverse-Proxy.

Nach dem Einrichten des Reverse Proxy passt du PUBLIC_ORIGIN in der .env an:

PUBLIC_ORIGIN=https://teable.example.com

Danach den Teable-Container neu starten:

docker compose up -d --force-recreate teable

Wichtig: WebSocket-Support muss im Reverse Proxy konfiguriert sein (Upgrade- und Connection-Header weiterleiten), da Teable WebSockets für die Echtzeit-Kollaboration nutzt.

Verifizieren: Öffne https://teable.example.com im Browser – das Schloss-Symbol in der Adressleiste bestätigt TLS. Öffne zwei Browser-Tabs mit derselben Tabelle und tippe in einem Tab einen Wert ein – er sollte im anderen Tab in Echtzeit erscheinen (WebSocket-Test).

Schritt 7: Updates und Backup

Updates einspielen

Teable führt Datenbankmigrationen automatisch beim Start durch. Vor jedem Update solltest du dennoch ein Backup erstellen. Das Update selbst ist ein Zweizeiler:

docker compose pull
docker compose up -d

Daten sichern

Drei bewährte Methoden:

1. PostgreSQL-Dump (empfohlen, skriptfähig):

docker exec teable-db pg_dump -U teable teable > backup_$(date +%Y%m%d).sql

1. Volume-Backup (komplettes Snapshot):

docker run --rm -v teable-db:/data -v $(pwd):/backup alpine \
  tar czf /backup/teable-db-$(date +%Y%m%d).tar.gz /data

1. Datei-Assets sichern: Volume teable-data enthält alle Uploads – analog sichern.

Wie du ein automatisiertes Backup mit Rotation und Cloud-Sync aufbaust, erklärt die Anleitung MySQL & PostgreSQL Backup automatisieren mit cron. Für eine vollständige Backup-Strategie inklusive Offsite-Kopie empfiehlt sich PostgreSQL pg_dump und pg_restore: Anleitung für Backup und Migration.

Wichtig: Verwende zum Herunterfahren niemals docker compose down -v – das Flag -v löscht alle Named Volumes und damit alle Daten unwiederbringlich. Verwende ausschließlich docker compose down.

Verifizieren: Nach docker compose pull && docker compose up -d zeigt docker compose ps alle Container erneut als Up (healthy). Prüfe docker compose logs teable | head -30 – keine Fehlermeldungen zu Migration oder Datenbankverbindung sollten erscheinen.

Eckdaten auf einen Blick

Troubleshooting / Typische Fehler

1. Teable startet nicht / Datenbank nicht erreichbar: Prüfe mit docker compose logs teable, ob Connection refused oder ECONNREFUSED erscheint. Ursache ist meist depends_on ohne condition: service_healthy. Lösung: compose.yaml wie oben verwenden; docker compose ps muss für alle drei Container healthy zeigen.
2. CSV/Bild-Upload schlägt fehl oder Vorschaubilder bleiben leer: Ursache ist fast immer ein falsch gesetztes PUBLIC_ORIGIN – z.B. falscher Port, http statt https oder ein abschließendes /. Korrigiere den Wert in der .env und starte den Teable-Container neu.
3. Datenbankverbindung schlägt fehl (PRISMA_DATABASE_URL): Sonderzeichen wie @, # oder % im Passwort werden in der URI nicht URL-enkodiert. Lösung: Nur alphanumerische ASCII-Zeichen für Passwörter verwenden.
4. Redis-Authentifizierung schlägt fehl: Pflichtformat der URI: redis://default:PASSWORT@HOST:PORT/DB – der User default darf nicht fehlen.
5. postgres:// URI-Schema-Fehler beim Start: Prisma erfordert zwingend postgresql://. Prüfe mit docker compose config | grep PRISMA.
6. Login schlägt fehl / JWT-Fehler: SECRET_KEY fehlt oder ist leer. Erzeuge mit openssl rand -base64 32 und trage ihn in die .env ein.
7. Kopieren/Einfügen funktioniert nicht: Clipboard-API erfordert HTTPS. Reverse Proxy mit TLS vorschalten und PUBLIC_ORIGIN auf https:// setzen.
8. Datenverlust nach Neustart: docker compose down -v löscht Named Volumes. Immer nur docker compose down (ohne -v) verwenden.
9. OOM-Kill des Teable-Containers: Weniger als 4 GB RAM auf dem Host. Mit docker stats Speicherverbrauch prüfen.

Häufige Fragen

Kann ich eine bereits vorhandene PostgreSQL-Instanz verwenden?

Ja. Entferne den teable-db-Service aus der compose.yaml und passe POSTGRES_HOST auf die IP-Adresse oder den Hostnamen deiner externen PostgreSQL-Instanz an. Wenn die Datenbank auf dem Docker-Host selbst läuft, verwende host.docker.internal statt 127.0.0.1. Achte darauf, dass der Datenbanknutzer die nötigen Rechte (CREATE, SELECT, INSERT, UPDATE, DELETE, ALTER) auf der Zieldatenbank hat und die Datenbank bereits existiert.

Wie aktualisiere ich Teable auf eine neue Version?

Im Projektordner: docker compose pull && docker compose up -d. Teable führt Datenbankmigrationen automatisch beim Start durch. Erstelle vorher immer ein Backup mit pg_dump – automatische Migrationen sind in der Regel stabil, aber ein Rollback ist ohne Backup nicht möglich.

Wie exportiere ich meine Daten?

Zwei Wege: Erstens über die Teable-Oberfläche als CSV oder XLSX direkt im Browser. Zweitens per pg_dump für einen vollständigen Datenbank-Export: docker exec teable-db pg_dump -U teable teable > backup.sql. Der zweite Weg eignet sich für Migrationen oder vollständige Backups und lässt sich gut automatisieren.

Unterstützt Teable ARM64 (z.B. Apple Silicon, Oracle ARM)?

Das offizielle Image ist für amd64 dokumentiert. ARM64-Unterstützung ist auf der GHCR- und Docker-Hub-Seite nicht explizit aufgeführt. Für den Produktivbetrieb wird ein amd64-Server empfohlen; auf Apple-Silicon-Macs läuft das Image unter Rosetta-Emulation, was für lokale Tests ausreicht.

Kann ich Teable hinter Nginx Proxy Manager, Traefik oder Caddy betreiben?

Ja. Teable hört intern auf Port 3000. Aktiviere im Reverse Proxy den WebSocket-Pass-through (Upgrade- und Connection-Header weiterleiten), da die Echtzeit-Kollaboration WebSockets nutzt. Setze PUBLIC_ORIGIN auf die externe HTTPS-URL.

Wie unterscheidet sich Teable von NocoDB?

Beide sind quelloffene No-Code-Datenbankanwendungen. NocoDB unterstützt mehrere Datenbankbackends (MySQL, PostgreSQL, SQLite), während Teable ausschließlich auf PostgreSQL setzt und damit direkten SQL-Zugriff sowie bessere BI-Tool-Kompatibilität bietet. Teable legt den Fokus stärker auf Echtzeit-Kollaboration und Airtable-Kompatibilität. Eine NocoDB-Anleitung für Synology-Nutzer findest du unter NocoDB auf dem Synology NAS installieren.

Fazit

Teable ist eine ausgereifte, aktiv gepflegte No-Code-Datenbankanwendung, die den Nerv vieler KMU-Anforderungen trifft: strukturierte Daten ohne Programmierkenntnisse verwalten, in Echtzeit zusammenarbeiten und dabei die volle Datenkontrolle behalten. Das PostgreSQL-Backend ist kein Marketingversprechen, sondern ein echter technischer Vorteil – direkter SQL-Zugriff, pg_dump-Backups und BI-Tool-Anbindung funktionieren ohne Umwege. Der Docker-Compose-Stack aus drei Containern ist in rund 20 Minuten einsatzbereit und auf jedem Linux-Host lauffähig. Für den Produktivbetrieb solltest du einen Reverse Proxy mit TLS ergänzen und ein automatisiertes Backup der PostgreSQL-Daten einrichten – beides lässt sich mit den verlinkten Anleitungen schnell umsetzen.

Weiterführende Anleitungen und Quellen

1. Docker und Docker Compose auf Linux installieren (Ubuntu/Debian): die Self-Hosting-Grundlage
2. Caddy als Reverse Proxy einrichten: Anfänger-Anleitung mit automatischem HTTPS
3. Traefik als Docker-Reverse-Proxy mit automatischem HTTPS einrichten
4. MySQL & PostgreSQL Backup automatisieren mit cron: mysqldump, pg_dump, Rotation und rclone-Cloud-Sync
5. NocoDB auf dem Synology NAS installieren: Airtable-Alternative auf eigener Datenbank
6. PostgreSQL pg_dump und pg_restore: Anleitung für Backup und Migration per Kommandozeile

Offizielle Quellen: Teable GitHub Repository | Teable Dokumentation – Docker Deployment | Offizielle standalone docker-compose.yaml

Passende Anleitungen auf S-EDV

1. PostgreSQL schließt elf Sicherheitslücken in den Versionen 14 bis 18
2. netcup Local Block Storage bestellen, einrichten und unter Linux einbinden
3. Linux 7.1-rc6 veröffentlicht: Kernel-Entwicklung stabilisiert sich nach KI-bedin