Wer relationale Daten intern verwalten möchte – Inventarlisten, CRM-Kontakte, Projekttracking oder Onboarding-Formulare – steht vor einer Wahl: entweder Airtable mit monatlichen Kosten und US-Cloudabhängigkeit, oder ein eigenes Werkzeug auf eigener Hardware. NocoDB löst dieses Problem elegant: Die Open-Source-Plattform legt eine Spreadsheet-ähnliche Oberfläche über eine PostgreSQL-Datenbank, bietet Kanban-, Galerie-, Formular- und Kalenderansichten und liefert im Hintergrund ein vollständiges REST- und GraphQL-API mit. Mit 63.400+ GitHub-Sternen und monatlichen Releases (aktuell Version 2026.06.0) ist das Projekt ausgereift genug für den produktiven KMU-Einsatz. Diese Anleitung richtet einen kompletten Vier-Container-Stack auf deinem Synology NAS ein – mit PostgreSQL als Datenbankbackend statt SQLite, Redis für stabile Job-Queue und einem dedizierten Worker-Container für CSV-Importe und Automationen.

Voraussetzungen

Synology NAS mit DSM 7.2 oder neuer, Container Manager installiert und aktiv
Mindestens 2 GB freier RAM (empfohlen: 4 GB für den Vollstack mit PostgreSQL, Redis und Worker)
Mindestens 10 GB freier Speicherplatz auf /volume1 für Datenbank und Anhänge
SSH-Zugang zum NAS für Ordneranlage und Rechtevergabe (Anleitung: SSH auf dem Synology NAS aktivieren und verbinden)
Netzwerkzugang für Docker-Pull: nocodb/nocodb:latest, postgres:17.10, redis:7
Optional: Synology DDNS-Domain (*.synology.me) oder eigene Domain für HTTPS via Reverse Proxy

Schritt 1: Ordnerstruktur anlegen und Rechte setzen

NocoDB läuft intern als Non-Root-Prozess. Wenn Docker die Zielordner automatisch anlegt, entstehen sie mit Root-Eigentümerschaft – NocoDB kann dann nicht schreiben. Deshalb legst du die Ordner vorab per SSH an und setzt offene Rechte für den lokalen Betrieb.

Verbinde dich per SSH mit dem NAS und führe aus:

sudo mkdir -p /volume1/docker/nocodb/{data,db,redis}
sudo chmod 777 /volume1/docker/nocodb/{data,db,redis}

Das Ergebnis: Drei Unterordner unter /volume1/docker/nocodb/ – data für NocoDB-Anhänge, db für PostgreSQL-Datenbankdateien und redis für die Redis-Persistenz.

Verifizieren: Prüfe per SSH, ob alle drei Ordner existieren und die Rechte korrekt sind:

ls -la /volume1/docker/nocodb/

Erwartete Ausgabe: Drei Ordner (data, db, redis) mit Rechten drwxrwxrwx. Fehlt ein Ordner oder zeigt er drwx------, wiederhole den mkdir/chmod-Befehl.

Schritt 2: JWT-Secret und Passwörter generieren

Der NC_AUTH_JWT_SECRET ist der wichtigste Konfigurationsparameter: Fehlt er oder wird er bei jedem Neustart neu generiert, verlieren alle angemeldeten Nutzer sofort ihre Session. Generiere einmalig einen 64-Zeichen-Zufallsstring und notiere ihn sicher – er darf sich nach dem ersten Start nie mehr ändern.

openssl rand -hex 32

Dieser Befehl liefert 32 Byte als 64 Hexzeichen, zum Beispiel:

a3f8c2e1d94b67f0123456789abcdef0a3f8c2e1d94b67f0123456789abcdef0

Generiere außerdem ein sicheres Datenbankpasswort (mindestens 16 Zeichen, Groß-/Kleinbuchstaben, Zahlen, Sonderzeichen) und bewahre beide Werte in einem Passwortmanager auf – etwa in Vaultwarden, dem eigenen Passwortmanager auf der Synology.

Verifizieren: Die Ausgabe von openssl rand -hex 32 muss genau 64 Zeichen lang sein und darf nur Hexzeichen (0-9, a-f) enthalten. Länge prüfen:

openssl rand -hex 32 | wc -c

Erwartete Ausgabe: 65 (64 Zeichen + Zeilenumbruch).

Schritt 3: Compose-Datei erstellen und Projekt anlegen

Zum Anlegen eines neuen Compose-Projekts öffnest du DSM, gehst zu Container Manager → Projekte → Erstellen und gibst als Pfad /volume1/docker/nocodb an. Wie das im Detail funktioniert, erklärt die Grundanleitung Container Manager: Docker-Compose-Projekt anlegen, starten und aktualisieren.

Erstelle im Projektordner die Datei compose.yaml mit folgendem Inhalt. Ersetze die Platzhalter (SICHERES_DB_PASSWORT, HIER_64_ZEICHEN_ZUFALLSSTRING_EINSETZEN und die DDNS-URL) durch deine tatsächlichen Werte:

services:

  nocodb:
    image: nocodb/nocodb:latest
    container_name: nocodb
    environment:
      NC_DB: 'pg://db:5432?u=nocodb&p=SICHERES_DB_PASSWORT&d=nocodb'
      NC_REDIS_URL: 'redis://redis:6379'
      NC_SITE_URL: 'https://DEINE-SYNOLOGY-DDNS.synology.me:8631'
      NC_AUTH_JWT_SECRET: 'HIER_64_ZEICHEN_ZUFALLSSTRING_EINSETZEN'
      NC_ADMIN_EMAIL: 'admin@beispiel.de'
      NC_ADMIN_PASSWORD: 'SicheresAdmin!Passwort1'
      NC_DISABLE_TELE: 'true'
      NC_DISABLE_MUX: 'true'
    depends_on:
      db:
        condition: service_healthy
      redis:
        condition: service_healthy
    restart: unless-stopped
    ports:
      - '8631:8080'
    volumes:
      - /volume1/docker/nocodb/data:/usr/app/data
    networks:
      - nocodb-network
    healthcheck:
      test: ['CMD-SHELL', 'wget -q --tries=1 --spider http://localhost:8080/api/v1/health || exit 1']
      interval: 30s
      timeout: 5s
      retries: 5
      start_period: 30s

  worker:
    image: nocodb/nocodb:latest
    container_name: nocodb-worker
    environment:
      NC_DB: 'pg://db:5432?u=nocodb&p=SICHERES_DB_PASSWORT&d=nocodb'
      NC_REDIS_URL: 'redis://redis:6379'
      NC_SITE_URL: 'https://DEINE-SYNOLOGY-DDNS.synology.me:8631'
      NC_AUTH_JWT_SECRET: 'HIER_64_ZEICHEN_ZUFALLSSTRING_EINSETZEN'
      NC_WORKER_CONTAINER: 'true'
    depends_on:
      nocodb:
        condition: service_healthy
    restart: unless-stopped
    volumes:
      - /volume1/docker/nocodb/data:/usr/app/data
    networks:
      - nocodb-network

  db:
    image: postgres:17.10
    container_name: nocodb-db
    environment:
      POSTGRES_USER: nocodb
      POSTGRES_PASSWORD: SICHERES_DB_PASSWORT
      POSTGRES_DB: nocodb
    volumes:
      - /volume1/docker/nocodb/db:/var/lib/postgresql/data
    restart: unless-stopped
    networks:
      - nocodb-network
    healthcheck:
      test: ['CMD-SHELL', 'pg_isready -U nocodb -d nocodb']
      interval: 10s
      timeout: 5s
      retries: 5

  redis:
    image: redis:7
    container_name: nocodb-redis
    volumes:
      - /volume1/docker/nocodb/redis:/data
    restart: unless-stopped
    networks:
      - nocodb-network
    healthcheck:
      test: ['CMD', 'redis-cli', 'ping']
      interval: 10s
      timeout: 5s
      retries: 5

networks:
  nocodb-network:
    driver: bridge

Ein paar wichtige Details zur Konfiguration:

NC_DB-Format: NocoDB verwendet ein eigenes Format pg://HOST:PORT?u=USER&p=PASS&d=DBNAME – das Standard-PostgreSQL-URL-Format (postgresql://user:pass@host/db) funktioniert nicht und führt zu „Invalid database url".
Worker-Volume: Beide Container (nocodb und worker) müssen denselben /usr/app/data-Volume-Mount teilen, damit der Worker auf hochgeladene Anhänge zugreifen kann.
PostgreSQL-Image-Tag: Verwende postgres:17.10 oder postgres:17. Der Tag postgres:18 existiert zum Zeitpunkt dieser Anleitung nicht als stabiles Release.
depends_on mit Healthcheck: Die condition: service_healthy-Abhängigkeiten sind wichtig – ohne sie startet der Worker bevor die API bereit ist und landet in einer Crash-Loop.

Verifizieren: Prüfe per SSH, ob die Compose-Datei korrekt gespeichert wurde:

grep "NC_DB" /volume1/docker/nocodb/compose.yaml

Erwartete Ausgabe: Zwei Zeilen mit NC_DB: 'pg://db:5432?u=nocodb (einmal für nocodb, einmal für worker). Siehst du kein Ergebnis, ist die Datei nicht am richtigen Ort.

Schritt 4: Projekt starten und Container-Status prüfen

Starte das Projekt im Container Manager über die Schaltfläche Erstellen bzw. Starten. Docker lädt zunächst die drei Images herunter – das dauert je nach Verbindung 2–5 Minuten.

Die Startreihenfolge ist durch die Healthchecks geregelt:

nocodb-db (PostgreSQL) und nocodb-redis starten zuerst und parallel.
nocodb startet erst, wenn beide (healthy) melden.
nocodb-worker startet zuletzt, wenn nocodb den Health-Endpoint beantwortet.

Verifizieren: Prüfe per SSH den Status aller vier Container:

sudo docker ps --filter "name=nocodb" --format "table {{.Names}}\t{{.Status}}"

Erwartete Ausgabe nach ca. 60–90 Sekunden:

NAMES             STATUS
nocodb-worker     Up X minutes
nocodb            Up X minutes (healthy)
nocodb-redis      Up X minutes (healthy)
nocodb-db         Up X minutes (healthy)

Zeigt ein Container dauerhaft „Restarting", prüfe die Logs mit sudo docker logs nocodb – häufigste Ursache ist ein falsch formatierter NC_DB-String.

Schritt 5: Erstanmeldung im Dashboard durchführen

Öffne im Browser:

http://NAS-IP:8631/dashboard

Beim ersten Aufruf erscheint entweder direkt die Anmeldemaske (wenn du NC_ADMIN_EMAIL und NC_ADMIN_PASSWORD gesetzt hast) oder ein Registrierungsformular für den ersten Superadmin-Account. Melde dich mit den in der Compose-Datei hinterlegten Zugangsdaten an.

Nach der Anmeldung begrüßt dich der NocoDB-Startbildschirm. Erstelle eine neue Basis (entspricht einem Workspace in Airtable-Sprache), wähle als Typ NocoDB-Datenbank und lege eine erste Testtabelle an.

Verifizieren: Rufe den Health-Endpoint direkt auf, um zu bestätigen, dass die API antwortet:

curl -s http://localhost:8631/api/v1/health

Erwartete Ausgabe:

{"status":"ok"}

Siehst du die NocoDB-Oberfläche im Browser und erhältst {"status":"ok"}, ist der Stack vollständig betriebsbereit.

Schritt 6: Firewall freischalten

Wenn die DSM-Firewall aktiviert ist, ist Port 8631 von außen gesperrt. Schalte ihn frei unter Systemsteuerung → Sicherheit → Firewall → Regeln bearbeiten. Die genaue Vorgehensweise erklärt die Grundanleitung DSM-Firewall: Ports für Docker-Container freigeben.

Für den Produktivbetrieb empfehle ich stattdessen einen Reverse Proxy (etwa Nginx Proxy Manager auf der Synology), der HTTPS terminiert und nur Port 443 öffnet. Trage dann die HTTPS-URL in NC_SITE_URL ein. Wichtig für den Mehrbenutzer-Betrieb: Aktiviere im Reverse Proxy die WebSocket-Unterstützung mit den Headern Upgrade und Connection – sonst frieren geteilte Ansichten bei gleichzeitiger Bearbeitung ein.

Verifizieren: Rufe das Dashboard von einem Gerät außerhalb des lokalen Netzwerks auf (z. B. per Mobilfunk) oder über die externe IP bzw. DDNS-URL. Erscheint die Anmeldemaske, ist die Firewall korrekt konfiguriert.

Schritt 7: CSV-Import testen und API-Token erstellen

Zwei Funktionen lohnt es sich direkt nach der Installation zu prüfen, denn beide hängen vom Worker-Container und Redis ab:

CSV-Import über den Worker

Öffne eine Tabelle in NocoDB, klicke auf das Pluszeichen neben dem letzten Reiter und wähle Import → CSV/Excel/JSON. Lade eine kleine CSV-Testdatei hoch. Nach dem Hochladen erscheint unten rechts ein Fortschrittsbalken – der Worker verarbeitet den Import als Hintergrundjob. Bei einer Datei mit 100 Zeilen ist das in wenigen Sekunden abgeschlossen.

API-Token erstellen

Gehe zu Team & Einstellungen → API-Tokens → + Neues Token, vergib einen sprechenden Namen (z. B. „Inventar-Integration") und kopiere den Token sofort – er wird nur einmalig angezeigt. Die REST-API ist anschließend unter folgendem Pfad erreichbar:

https://DEINE-SYNOLOGY-DDNS.synology.me:8631/api/v1

Die vollständige Swagger-Dokumentation findest du unter /api/v1/swagger. Teste den Token mit einem einfachen API-Aufruf:

curl -s -H "xc-token: DEIN_API_TOKEN" \
  http://localhost:8631/api/v1/meta/tables

Verifizieren: Der CSV-Import ist erfolgreich, wenn nach dem Hochladen alle Zeilen in der Tabelle erscheinen und kein Fehlerbalken aufpoppt. Der API-Aufruf gibt eine JSON-Antwort mit einer Tabellenliste zurück – kein {"msg":"Unauthorized"}. Siehst du dennoch Unauthorized, wurde der Token falsch kopiert.

Troubleshooting / Typische Fehler

„Invalid database url" beim Start: Du verwendest das Standard-PostgreSQL-URL-Format. NocoDB erwartet zwingend pg://HOST:PORT?u=USER&p=PASS&d=DBNAME. Passe NC_DB in der Compose-Datei an und starte den Stack neu.
Worker-Container crasht sofort (Restart-Loop): Redis ist nicht erreichbar oder NC_REDIS_URL fehlt. Prüfe mit sudo docker logs nocodb-worker – du siehst „Redis connection failed". Stelle sicher, dass der Redis-Container läuft und NC_REDIS_URL: 'redis://redis:6379' korrekt gesetzt ist.
Alle Nutzer werden nach Neustart ausgeloggt: NC_AUTH_JWT_SECRET wurde nicht gesetzt. NocoDB generiert dann bei jedem Neustart ein neues Secret. Setze einen festen 64-Zeichen-String und starte den nocodb-Container einmalig neu.
PostgreSQL startet nicht, Fehler „data directory has wrong ownership": Der Ordner hat falsche Rechte oder du hast als Volume-Ziel /var/lib/postgresql statt /var/lib/postgresql/data angegeben. Korrigiere den Volume-Pfad in der Compose-Datei.
Dashboard zeigt „502 Bad Gateway": NocoDB ist noch nicht bereit. Warte 60–90 Sekunden und prüfe mit sudo docker ps, ob der nocodb-Container den Status (healthy) zeigt. Logs unter sudo docker logs nocodb.
E-Mail-Einladungslinks zeigen „localhost": NC_SITE_URL wurde nicht gesetzt oder zeigt auf http://localhost:8080. Trage die tatsächliche externe URL ein, z. B. https://nas.beispiel.de:8631.
CSV-Import hängt oder schlägt lautlos fehl: Redis-Container nicht erreichbar oder Worker-Container nicht gestartet. Überprüfe beide mit sudo docker ps.
Docker Pull schlägt für postgres fehl: Du hast postgres:18 als Image-Tag eingetragen. Dieses Tag existiert nicht als stabiles Release. Verwende postgres:17.10 oder postgres:17.

Häufige Fragen

Kann ich eine bestehende PostgreSQL-Instanz mitnutzen?

Technisch ja: Zeige NC_DB auf den externen Container und stelle sicher, dass beide im selben Docker-Netzwerk erreichbar sind. Empfehlung für den Produktivbetrieb: eine dedizierte PostgreSQL-Instanz für NocoDB, damit Updates und das in der Anleitung PostgreSQL-Performance-Tuning für Einsteiger beschriebene Tuning keine Wechselwirkungen mit anderen Anwendungen erzeugen.

Wie unterscheidet sich NocoDB von Metabase?

Metabase ist primär ein BI- und Reporting-Werkzeug: Dashboards, SQL-Abfragen, Charts. NocoDB ist ein Dateneingabe- und Datenverwaltungswerkzeug mit Spreadsheet-Oberfläche. Beide ergänzen sich gut: Daten in NocoDB erfassen und pflegen, in Metabase auswerten und visualisieren.

Ist die Sustainable Use License wirklich „Open Source"?

Formell nein. Die Sustainable Use License der NocoDB Foundation erlaubt freies Selbsthosting, untersagt aber das Anbieten von NocoDB als kommerziellen Managed Service ohne Lizenzvereinbarung. Für internen KMU-Einsatz auf eigenem NAS gibt es keinerlei Einschränkung.

Wie führe ich ein Update auf eine neue NocoDB-Version durch?

Stoppe im Container Manager das Projekt, führe einen Image-Pull für nocodb/nocodb:latest und postgres:17 aus und starte das Projekt neu. Vor dem Update immer ein Backup des Ordners /volume1/docker/nocodb/db anlegen. NocoDB führt Datenbankmigrationen automatisch beim Start aus.

Kann ich NocoDB mit Odoo verbinden?

Ja, über die NocoDB REST-API oder via Webhooks – ein typisches Szenario für ein NAS, auf dem auch Odoo als ERP/CRM läuft. Alternativ zeigen beide auf dieselbe PostgreSQL-Datenbank über die „External DB"-Funktion von NocoDB.

Was passiert mit den Daten, wenn ich den nocodb-Container neu erstelle?

Alle Nutzdaten liegen in /volume1/docker/nocodb/data (Anhänge) und /volume1/docker/nocodb/db (PostgreSQL). Solange diese Ordner nicht gelöscht werden und NC_AUTH_JWT_SECRET unverändert bleibt, sind nach dem Neuerstellen des Containers alle Tabellen und Datensätze sofort wieder verfügbar.

Fazit

NocoDB ist eine ausgereifte, aktiv gepflegte Airtable-Alternative, die auf dem Synology NAS mit vertretbarem Aufwand produktionsreif betrieben werden kann. Der entscheidende Unterschied zu vereinfachten Zwei-Container-Setups: Mit PostgreSQL als Datenbankbackend, Redis als Job-Queue und dem dedizierten Worker-Container ist der Stack stabil für den Teambetrieb – CSV-Importe, Automationen und Echtzeit-Kollaboration funktionieren zuverlässig. Alle Daten bleiben auf eigener Hardware in deinem Netzwerk, ohne US-Cloud-Abhängigkeit oder monatliche Lizenzkosten. Für interne KMU-Anwendungsfälle wie Inventarverwaltung, CRM-Light oder Projektverfolgung ist das eine überzeugende Kombination aus Datensouveränität und Benutzerfreundlichkeit.

Weiterführende Anleitungen und Quellen

Offizielle Quellen: NocoDB Self-Hosting Environment Variables | NocoDB GitHub Repository | NocoDB auf Docker Hub