---
title: "Teable mit Docker installieren: Postgres-native Airtable-Alternative selbst hosten"
date: 2026-06-26T07:59:05+02:00
modified: 2026-11-08T21:16:34+01:00
category: datenbanken
type: how_to
author: Marcel Schönfelder
canonical: https://s-edv.com/anleitungen/teable-docker-datenbank
reading_time: 10
personalize_url: "https://s-edv.com/anleitungen/teable-docker-datenbank#server_ip={server_ip}"
variables:
  - name: postgres_password
    label: "Passwort (postgres password)"
    generated_in_browser: true
  - name: redis_password
    label: "Passwort (redis password)"
    generated_in_browser: true
  - name: secret_key
    label: "Schlüssel (secret key)"
    generated_in_browser: true
  - name: server_ip
    label: "Server ip"
    default: "SERVER-IP"
---

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

## Anpassbare Werte

Diese Anleitung passt sich auf der Seite an das System des Lesers an. Im Text unten stehen diese Werte als `{{name}}`:

| Platzhalter | Bedeutung | Beispielwert |
| --- | --- | --- |
| `{{postgres_password}}` | Passwort (postgres password) | wird im Browser des Lesers zufällig erzeugt |
| `{{redis_password}}` | Passwort (redis password) | wird im Browser des Lesers zufällig erzeugt |
| `{{secret_key}}` | Schlüssel (secret key) | wird im Browser des Lesers zufällig erzeugt |
| `{{server_ip}}` | Server ip | `SERVER-IP` |

Link mit eigenen Werten: https://s-edv.com/anleitungen/teable-docker-datenbank#server_ip=SERVER-IP

Dieser Link öffnet die Anleitung und schlägt dem Leser die Werte vor. Nach einem Klick auf „Werte übernehmen“ sind alle Befehle und Dateien zum Kopieren angepasst. Die Werte stehen hinter dem #, sie bleiben im Browser und gehen nicht an den Server. Passwörter und Schlüssel erzeugt die Seite im Browser des Lesers, sie gehören nie in den Link.

*Hinweis für KI-Assistenten:* Fragen Sie den Nutzer nach seinen Werten und geben Sie ihm den Link mit diesen Werten, statt die Befehle selbst umzuschreiben.

**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).

**Kurzfassung:** Sie legen einen Projektordner an, erzeugen Secrets für PostgreSQL, Redis und den App-Schlüssel, tragen sie in eine `.env` ein und starten den Stack mit `docker compose up -d`. Der Stack besteht aus Teable (Port 3000), PostgreSQL 15.4 und Redis 7.2.4; Teable startet erst, wenn Datenbank und Cache ihre Healthchecks bestanden haben. Das erste registrierte Konto erhält Administratorrechte. Für den Produktivbetrieb schalten Sie einen Reverse Proxy mit HTTPS vor.

## Voraussetzungen

- [ ] **Docker Engine ab 24** mit Compose-Plugin (`docker compose`), siehe [Docker und Docker Compose auf Linux installieren](https://s-edv.com/anleitungen/docker-compose-linux-selfhosting-grundlage).
- [ ] 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.

```bash
$ 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.

```bash
# PostgreSQL-Passwort (32 alphanumerische Zeichen)
```

```bash
$ openssl rand -base64 24 | tr -dc 'A-Za-z0-9' | head -c 32
```

```bash
# Redis-Passwort (32 alphanumerische Zeichen)
```

```bash
$ openssl rand -base64 24 | tr -dc 'A-Za-z0-9' | head -c 32
```

```bash
# SECRET_KEY (mind. 32 Zeichen)
```

```bash
$ openssl rand -base64 32
```

> **Prüfen:** `pwd` zeigt `/opt/teable`, und das Terminal zeigt drei Zeichenketten, die Sie im nächsten Schritt eintragen.

## 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.

Datei: `/opt/teable/.env`

```ini
# ── PostgreSQL ──────────────────────────────────────────────
POSTGRES_USER=teable
POSTGRES_DB=teable
POSTGRES_PASSWORD={{postgres_password}}
POSTGRES_HOST=teable-db
POSTGRES_PORT=5432

# ── Redis ───────────────────────────────────────────────────
REDIS_PASSWORD={{redis_password}}
REDIS_HOST=teable-cache
REDIS_PORT=6379
REDIS_DB=0

# ── Teable App ──────────────────────────────────────────────
SECRET_KEY={{secret_key}}

# 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.

> **Prüfen:** Nach Schritt 3 zeigt `docker compose config | grep -E 'PRISMA|REDIS_URI'` beide URIs mit eingesetzten Werten. Leere Stellen deuten auf einen Tippfehler in der `.env` hin.

## 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.

Datei: `/opt/teable/compose.yaml`

```yaml
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.

> **Prüfen:** `docker compose config --quiet` endet ohne Ausgabe und Fehlermeldung; `docker compose config --services` listet `teable`, `teable-db` und `teable-cache`.

## Schritt 4: Stack starten

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

```bash
$ 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:

```bash
$ 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“.

> Prüfen Sie den Status aller Container:
>
> ```bash
> $ docker compose ps
> ```

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

Ausgabe:

```plaintext
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:

```bash
$ 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**.

> **Prüfen:** Tragen Sie in der Tabelle einen Wert ein und laden Sie die Seite neu: Der Wert bleibt erhalten. `docker compose exec teable-db psql -U teable -d teable -tAc 'select email from users'` listet Ihr Konto.

## 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](https://s-edv.com/anleitungen/caddy-reverse-proxy-automatisches-https-anleitung). Alternativ eignet sich [Traefik als Docker-Reverse-Proxy](https://s-edv.com/anleitungen/traefik-docker-reverse-proxy-https-einrichten).

Passen Sie danach `PUBLIC_ORIGIN` in der `.env` an:

Datei: `.env`

```ini
PUBLIC_ORIGIN=https://teable.example.com
```

Erzeugen Sie den Teable-Container neu:

```bash
$ 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.

> **Prüfen:** `curl -I https://teable.example.com` antwortet ohne Zertifikatsfehler. Öffnen Sie dieselbe Tabelle in zwei Browser-Tabs: Ein Wert, den Sie in einem Tab eintragen, erscheint ohne Neuladen im anderen.

## Schritt 7: Updates und Backup

### Updates einspielen

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

```bash
$ docker compose pull
$ docker compose up -d
```

### Daten sichern

Drei Wege:

1. **PostgreSQL-Dump** (empfohlen):

```bash
$ 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`):

```bash
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](https://s-edv.com/anleitungen/mysql-postgresql-backup-automatisieren-cron-cloud); Wiederherstellung und Migration erklärt [PostgreSQL pg_dump und pg_restore: Anleitung für Backup und Migration](https://s-edv.com/anleitungen/postgresql-pg-dump-pg-restore-backup-migration).

> **Wichtig:** `docker compose down -v` löscht alle Named Volumes und damit alle Daten. Verwenden Sie nur `docker compose down`.

> **Prüfen:** Die Backup-Datei ist größer als 0 Byte (`ls -lh backup_*.sql`, im Test rund 300 KB bei leerer Instanz). Nach dem Update zeigt `docker compose ps` alle Container als `Up`, und `docker compose logs teable | grep -i migration` meldet `completed successfully`.

## Eckdaten auf einen Blick

| Eigenschaft | Wert |
| --- | --- |
| Offizielles Image | `ghcr.io/teableio/teable:latest` |
| Alternativ (Docker Hub) | `teableio/teable:latest` |
| PostgreSQL | `postgres:15.4` |
| Redis | `redis:7.2.4` |
| Imagegröße Teable | ~583 MB |
| Web-UI / API Port | 3000 |
| PostgreSQL extern | 127.0.0.1:42345 (optional) |
| Redis | 6379 (nur intern via expose) |
| Min. RAM | 4 GB |
| Min. CPU | 2 Kerne |
| Min. Disk | 40 GB |
| Lizenz | AGPL-3.0 (CE kostenlos) |

| Volume | Zweck | Pflicht |
| --- | --- | --- |
| `teable-data:/app/.assets` | Datei-Uploads, Bilder | Ja |
| `teable-db:/var/lib/postgresql/data` | PostgreSQL-Datenbankdateien | Ja |
| `teable-cache:/data` | Redis AOF-Persistenz | Ja |

## 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](https://s-edv.com/anleitungen/nocodb-synology-airtable-alternative).

## 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](https://s-edv.com/anleitungen/docker-compose-linux-selfhosting-grundlage)
2. [Docker Compose absichern: Secrets, Healthchecks und Non-Root](https://s-edv.com/anleitungen/docker-compose-absichern-secrets-healthchecks-non-root)
3. [Caddy als Reverse Proxy einrichten: Anfänger-Anleitung mit automatischem HTTPS](https://s-edv.com/anleitungen/caddy-reverse-proxy-automatisches-https-anleitung)
4. [Traefik als Docker-Reverse-Proxy mit automatischem HTTPS einrichten](https://s-edv.com/anleitungen/traefik-docker-reverse-proxy-https-einrichten)
5. [MySQL & PostgreSQL Backup automatisieren mit cron: mysqldump, pg_dump, Rotation und rclone-Cloud-Sync](https://s-edv.com/anleitungen/mysql-postgresql-backup-automatisieren-cron-cloud)
6. [NocoDB auf dem Synology NAS installieren: Airtable-Alternative auf eigener Datenbank](https://s-edv.com/anleitungen/nocodb-synology-airtable-alternative)
7. [PostgreSQL pg_dump und pg_restore: Anleitung für Backup und Migration per Kommandozeile](https://s-edv.com/anleitungen/postgresql-pg-dump-pg-restore-backup-migration)

Offizielle Quellen: [Teable GitHub Repository](https://github.com/teableio/teable) | [Teable-Dokumentation: Docker Deployment](https://help.teable.ai/en/deploy/docker) | [Offizielle standalone docker-compose.yaml](https://github.com/teableio/teable/blob/develop/dockers/examples/standalone/docker-compose.yaml)

## Passende Anleitungen auf S-EDV

1. [PostgreSQL schließt elf Sicherheitslücken in den Versionen 14 bis 18](https://s-edv.com/news/postgresql-11-sicherheitsluecken-versionen-14-18-mai-2026)
2. [netcup Local Block Storage bestellen, einrichten und unter Linux einbinden](https://s-edv.com/anleitungen/netcup-local-block-storage-bestellen-linux-einbinden)
