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

Teable ist eine quelloffene No-Code-Datenbank (AGPL-3.0) mit tabellenähnlicher Oberfläche und den Ansichten Grid, Kanban, Galerie, Formular und Kalender. Die Daten liegen direkt in PostgreSQL: Sie können per SQL darauf zugreifen, BI-Werkzeuge wie Metabase oder Grafana anbinden und mit pg_dump sichern. Damit eignet sich Teable für Unternehmen, die Airtable aus Datenschutzgründen meiden. Diese Anleitung installiert Teable per Docker Compose auf einem Linux-Host (Ubuntu/Debian, VPS, Heimserver oder NAS mit Docker).

Voraussetzungen

• Docker Engine ab 24 mit Compose-Plugin (docker compose), siehe Docker und Docker Compose auf Linux installieren.
• Linux-Host, VM oder NAS mit Docker, x86-64 (amd64) oder ARM64.
• 2 CPU-Kerne und 4 GB RAM empfohlen, 40 GB freier Speicher. Im Test belegte Teable allein rund 900 MB RAM; mit nur einem Kern dauerte der erste Start etwa zehn Minuten.
• IP-Adresse oder Domain für PUBLIC_ORIGIN.
• openssl für Zufalls-Schlüssel und Internetzugang für rund 1,1 GB Images.
• Optional: Reverse Proxy (Caddy, Nginx oder Traefik) für HTTPS; ohne HTTPS funktioniert die Browser-Clipboard-API (Kopieren/Einfügen) nicht.

Schritt 1: Projektordner anlegen und Secrets generieren

Legen Sie einen Projektordner für compose.yaml und .env an.

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

Erzeugen Sie drei Secrets. Verwenden Sie für die Passwörter nur Buchstaben und Ziffern: 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

Schritt 2: .env-Datei anlegen

Erstellen Sie /opt/teable/.env und tragen Sie die Secrets ein. PUBLIC_ORIGIN enthält die exakt erreichbare URL mit Protokoll und Port, ohne abschließenden Schrägstrich.

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

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

# ── Teable App ──────────────────────────────────────────────
SECRET_KEY=IHR_SECRET_KEY_MIND_32_ZEICHEN

# Exakte öffentliche URL – kein abschließendes /
# Lokal:   http://127.0.0.1:3000
# Server:  http://SERVER-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

Häufige Fehlerquellen:

1. PRISMA_DATABASE_URL muss das Schema postgresql:// verwenden; postgres:// führt zu einem Startfehler. Der Variablenname lautet PRISMA_DATABASE_URL, nicht DATABASE_URL.
2. BACKEND_CACHE_REDIS_URI muss den User default enthalten: redis://default:PASSWORT@HOST:PORT/DB.
3. Ein falsches PUBLIC_ORIGIN (Port, Schrägstrich am Ende, http statt https) führt zu fehlschlagenden Uploads und leeren Vorschaubildern.

Schritt 3: compose.yaml anlegen

Erstellen Sie /opt/teable/compose.yaml. Die Datei folgt dem offiziellen Standalone-Beispiel; depends_on mit condition: service_healthy startet Teable erst, wenn Datenbank und Cache bereit sind. Abweichend vom Original ist der PostgreSQL-Port nur an 127.0.0.1 gebunden.

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:
      - "127.0.0.1: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 liegt unter ghcr.io/teableio/teable, gleichlautend auch als teableio/teable auf Docker Hub (amd64 und arm64). :latest wechselt mit jedem Release; für reproduzierbare Updates schreiben Sie einen Release-Tag fest, z. B. release.2026-09-27T13-21-53Z.3275.
2. Redis ist nur per expose im internen Netz erreichbar, nicht vom Host.
3. PostgreSQL ist über 127.0.0.1:42345 für lokale SQL-Clients erreichbar, z. B. per SSH-Tunnel mit DBeaver. Ohne Bedarf lassen Sie den ports-Eintrag weg.

Schritt 4: Stack starten

Starten Sie den Stack im Projektordner. Docker lädt beim ersten Start rund 1,1 GB Images.

$ docker compose up -d

Teable führt beim Start die Datenbankmigrationen aus. Das dauert auf 2 Kernen einige Minuten, auf einem Kern im Test rund zehn. Verfolgen Sie den Fortschritt:

$ docker compose logs -f teable

Nach Database migration completed successfully folgen die Meldungen des Next.js-Servers und WsGateway (SockJS) initialized. Beenden Sie die Ausgabe mit Strg+C. Die Warnung SANDBOX_JWT_SECRET is not set behandelt der Abschnitt „Typische Fehler“.

$ docker compose ps

Erwartet (der Teable-Container hat keinen eigenen Healthcheck und zeigt nur Up):

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

Testen Sie zusätzlich per HTTP:

$ curl -I http://localhost:3000
$ curl http://localhost:3000/health

Erwartet: HTTP/1.1 307 Temporary Redirect (Weiterleitung zur Anmeldung) und {"status":"ok",…}. Solange die Migrationen laufen, meldet curl „Connection refused“ oder „Empty reply“.

Schritt 5: Erst-Einrichtung im Browser

Öffnen Sie die unter PUBLIC_ORIGIN eingetragene Adresse, z. B. http://SERVER-IP:3000. Teable leitet zur Anmeldung weiter.

1. Registrieren Sie sich mit E-Mail-Adresse und sicherem Passwort. Das erste Konto erhält Administratorrechte; registrieren Sie es deshalb sofort nach dem Start.
2. Legen Sie einen Bereich (Space) an, die oberste Strukturebene in Teable.
3. Erstellen Sie darin eine Datenbank (Base) mit einer oder mehreren Tabellen.

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

Im Produktivbetrieb brauchen Sie HTTPS: Die Zwischenablage-API des Browsers (Kopieren/Einfügen größerer Bereiche) funktioniert nur in einem sicheren Kontext, und Passwörter gehören nicht unverschlüsselt ins Netz.

Automatisches TLS liefert Caddy, siehe Caddy als Reverse Proxy mit automatischem HTTPS. Alternativ eignet sich Traefik als Docker-Reverse-Proxy.

Passen Sie danach PUBLIC_ORIGIN in der .env an:

PUBLIC_ORIGIN=https://teable.example.com

Erzeugen Sie den Teable-Container neu:

$ docker compose up -d --force-recreate teable

Leiten Sie im Reverse Proxy die Upgrade- und Connection-Header weiter: Teable nutzt WebSockets für die gemeinsame Bearbeitung in Echtzeit.

Schritt 7: Updates und Backup

Updates einspielen

Teable migriert die Datenbank beim Start automatisch. Erstellen Sie vorher ein Backup, dann:

$ docker compose pull
$ docker compose up -d

Daten sichern

Drei Wege:

1. PostgreSQL-Dump (empfohlen):

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

1. Volume-Backup (Container vorher mit docker compose stop anhalten; Compose stellt dem Volume-Namen den Projektnamen voran, prüfen Sie ihn mit docker volume ls):

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, sichern Sie es auf dieselbe Weise.

Automatisierte Backups mit Rotation und Cloud-Sync beschreibt MySQL & PostgreSQL Backup automatisieren mit cron; Wiederherstellung und Migration erklärt PostgreSQL pg_dump und pg_restore: Anleitung für Backup und Migration.

Eckdaten auf einen Blick

Troubleshooting / Typische Fehler

Teable startet nicht / Datenbank nicht erreichbar

Prüfen Sie mit docker compose logs teable, ob Connection refused oder ECONNREFUSED erscheint. Ursache ist meist depends_on ohne condition: service_healthy; übernehmen Sie die compose.yaml von oben.

CSV/Bild-Upload schlägt fehl oder Vorschaubilder bleiben leer

Ursache ist ein falsches PUBLIC_ORIGIN. Korrigieren Sie den Wert in der .env und erzeugen Sie den Container mit docker compose up -d --force-recreate teable neu.

Datenbankverbindung schlägt fehl (PRISMA_DATABASE_URL)

Sonderzeichen im Passwort brechen die URI. Lösung: Passwörter nur aus Buchstaben und Ziffern.

Redis-Authentifizierung schlägt fehl

Die URI muss den Benutzer default enthalten: redis://default:PASSWORT@HOST:PORT/DB.

postgres:// URI-Schema-Fehler beim Start

Prisma erfordert zwingend postgresql://. Prüfen Sie mit docker compose config | grep PRISMA.

Login schlägt fehl / JWT-Fehler

SECRET_KEY fehlt oder ist leer. Erzeugen Sie ihn mit openssl rand -base64 32 und tragen Sie ihn in die .env ein.

Kopieren/Einfügen funktioniert nicht

Die Zwischenablage-API braucht HTTPS, siehe Schritt 6.

Datenverlust nach Neustart

Ursache ist docker compose down -v, siehe Schritt 7.

OOM-Kill oder minutenlang keine Antwort auf Port 3000

Zu wenig RAM oder CPU. Prüfen Sie mit docker stats; Teable belegt im Leerlauf rund 900 MB.

Log-Warnung SANDBOX_JWT_SECRET is not set

Neuere Images starten die Code-Sandbox sonst mit einem öffentlich bekannten Standardschlüssel. Erzeugen Sie laut Log-Hinweis einen Wert mit openssl rand -base64 32, tragen Sie ihn als SANDBOX_JWT_SECRET=… in die .env ein und erzeugen Sie den Container neu.

Häufige Fragen

Kann ich eine bereits vorhandene PostgreSQL-Instanz verwenden?

Ja. Entfernen Sie den Dienst teable-db samt depends_on-Eintrag und setzen Sie POSTGRES_HOST auf Adresse oder Hostnamen der vorhandenen Instanz. Läuft sie auf dem Docker-Host, verwenden Sie host.docker.internal (unter Linux zusätzlich extra_hosts: ["host.docker.internal:host-gateway"]) statt 127.0.0.1. Die Datenbank muss existieren, der Nutzer braucht dort volle Rechte.

Wie aktualisiere ich Teable auf eine neue Version?

Wie in Schritt 7: Backup mit pg_dump, dann docker compose pull && docker compose up -d. Die Migration läuft automatisch; ein Zurück gibt es nur über das Backup.

Wie exportiere ich meine Daten?

Einzelne Tabellen exportieren Sie in der Oberfläche als CSV. Die vollständige Datenbank sichern Sie per pg_dump wie in Schritt 7.

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

Ja. Die Release-Tags auf Docker Hub (teableio/teable) enthalten Images für amd64 und arm64, damit läuft Teable nativ auf ARM-Servern und Apple Silicon.

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

Ja. Leiten Sie auf Port 3000 weiter, aktivieren Sie die WebSocket-Weiterleitung und setzen Sie PUBLIC_ORIGIN auf die externe HTTPS-URL. Im Nginx Proxy Manager heißt die Option „Websockets Support“.

Wie unterscheidet sich Teable von NocoDB?

Beide sind quelloffene No-Code-Datenbankanwendungen. NocoDB arbeitet mit mehreren Datenbanken (MySQL, PostgreSQL, SQLite), Teable nur mit PostgreSQL und legt den Schwerpunkt auf Echtzeit-Zusammenarbeit. Eine NocoDB-Anleitung für Synology finden Sie unter NocoDB auf dem Synology NAS installieren.

Fazit

Teable verwaltet strukturierte Daten ohne Programmierung, erlaubt gemeinsame Bearbeitung in Echtzeit und lässt die Daten in Ihrer eigenen PostgreSQL-Datenbank. Rechnen Sie mit 2 Kernen und 4 GB RAM und einem ersten Start von einigen Minuten. Für den Produktivbetrieb ergänzen Sie einen Reverse Proxy mit TLS, ein automatisches Backup und einen festen Release-Tag.

Weiterführende Anleitungen und Quellen

1. Docker und Docker Compose auf Linux installieren (Ubuntu/Debian): die Self-Hosting-Grundlage
2. Docker Compose absichern: Secrets, Healthchecks und Non-Root
3. Caddy als Reverse Proxy einrichten: Anfänger-Anleitung mit automatischem HTTPS
4. Traefik als Docker-Reverse-Proxy mit automatischem HTTPS einrichten
5. MySQL & PostgreSQL Backup automatisieren mit cron: mysqldump, pg_dump, Rotation und rclone-Cloud-Sync
6. NocoDB auf dem Synology NAS installieren: Airtable-Alternative auf eigener Datenbank
7. 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