Hasura mit Docker installieren: sofortige Echtzeit-GraphQL-API für bestehende Datenbanken

Wer eine REST- oder GraphQL-API über eine bestehende Datenbank bauen will, verbringt normalerweise Tage damit, Resolver, Typdefinitionen und Berechtigungslogik von Hand zu schreiben. Hasura GraphQL Engine dreht dieses Verhältnis um: Du verbindest das Tool per Verbindungs-URL mit einer PostgreSQL-Datenbank – und bekommst sofort vollständige Queries, Mutations und Echtzeit-Subscriptions, ohne eine Zeile Backend-Code zu schreiben. Feingranulare Row- und Column-Level-Berechtigungen, Webhook-Trigger auf Datenbankevents, Remote-Schema-Stitching und eine eingebaute Web-Console machen Hasura zum zentralen API-Gateway moderner Datenarchitekturen. Mit über 32.000 GitHub-Stars und aktivem Release-Rhythmus (aktuell v2.49.2, Stand Juni 2026) ist das Projekt produktionsreif und per Docker Compose in unter zehn Minuten auf jedem Linux-Host lauffähig.

Voraussetzungen

1. Docker Engine >= 20.10 und Docker Compose v2 (Pflicht für condition: service_healthy): Falls noch nicht installiert, siehe Docker und Docker Compose auf Linux installieren.
2. Linux-Host, VM oder NAS mit laufendem Docker-Daemon (x86_64 oder arm64 – beide Architekturen werden unterstützt).
3. Freie Ports 8080 (Hasura Web-Console + GraphQL-Endpoint) und optional 8081 (Data Connector Agent) auf dem Host.
4. Mindestens 1 GB RAM, empfohlen 2 GB; PostgreSQL + GraphQL-Engine + Data-Connector-Agent zusammen benötigen im Leerlauf ca. 400–600 MB.
5. Netzwerkzugang zu Docker Hub für den initialen Image-Pull (hasura/graphql-engine:v2.49.2, postgres:15, hasura/graphql-data-connector:v2.49.2).
6. Für den Produktionsbetrieb: ein Reverse Proxy mit TLS (z. B. Traefik oder Nginx Proxy Manager) – dazu am Ende der Anleitung mehr.

Schritt 1: Eckdaten und Stack-Überblick

Bevor der erste Befehl läuft, lohnt ein kurzer Blick auf die Bausteine des Stacks. Die folgende Tabelle fasst alle relevanten Eckdaten zusammen:

Der Stack besteht aus drei Services: postgres speichert sowohl die Hasura-Metadaten (Berechtigungen, Relationships, Actions) als auch optionale Applikationsdaten. graphql-engine ist die eigentliche API-Middleware, die auf Port 8080 lauscht. data-connector-agent ist nur nötig, wenn du Nicht-Postgres-Datenbanken (MySQL 8, Oracle, Snowflake, Athena, MariaDB) anbinden willst – für reine PostgreSQL-Setups kann er weggelassen werden.

Verifizieren: Kein Befehl nötig – überprüfe, ob docker --version und docker compose version ohne Fehler antworten und mindestens Docker 20.10 bzw. Compose 2.x ausgeben.

docker --version
docker compose version

Erwartete Ausgabe: Docker version 26.x.x und Docker Compose version v2.x.x.

Schritt 2: Projektordner anlegen

Alle Dateien des Stacks kommen in ein gemeinsames Verzeichnis. Verwende einen Pfad unter /opt/ für systemweite Dienste oder unter deinem Home-Verzeichnis für persönliche Instanzen:

mkdir -p /opt/hasura
cd /opt/hasura

Optionale Unterordner für automatische Migrationen (nur relevant mit dem cli-migrations-v3-Image-Variant):

mkdir -p migrations metadata

Verifizieren:

ls -la /opt/hasura

Erwartete Ausgabe: das Verzeichnis existiert und gehört deinem Systembenutzer.

Schritt 3: .env-Datei mit Secrets anlegen

Secrets niemals direkt in die compose.yaml schreiben. Lege stattdessen eine .env-Datei im Projektordner an und schütze sie mit restriktiven Rechten:

# /opt/hasura/.env

# Passwort für den lokalen PostgreSQL-Container
POSTGRES_PASSWORD=einSicheresPasswortHier

# Admin-Secret für Hasura – sichert alle Endpoints ab
# Mindestens 32 zufällige Zeichen, z. B. per: openssl rand -hex 32
HASURA_ADMIN_SECRET=ersetze-dies-durch-ein-langes-zufaelliges-geheimnis
chmod 600 /opt/hasura/.env

Das Admin-Secret sichert sowohl die Web-Console als auch den /v1/graphql-Endpoint ab. Ohne gesetztes Secret sind alle Endpoints ohne Authentifizierung erreichbar – auch in Entwicklungsumgebungen sollte dieses Secret immer gesetzt sein.

Verifizieren:

stat -c "%a %n" /opt/hasura/.env

Erwartete Ausgabe: 600 /opt/hasura/.env.

Schritt 4: compose.yaml erstellen

Die folgende compose.yaml enthält alle drei Services mit Healthchecks, damit Hasura erst startet, wenn PostgreSQL wirklich bereit ist – ein häufiger Fallstrick ohne diese Absicherung:

services:
  postgres:
    image: postgres:15
    restart: always
    volumes:
      - db_data:/var/lib/postgresql/data
    environment:
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:-postgrespassword}
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      timeout: 5s
      retries: 5

  graphql-engine:
    image: hasura/graphql-engine:v2.49.2
    ports:
      - "8080:8080"
    restart: always
    depends_on:
      postgres:
        condition: service_healthy
      data-connector-agent:
        condition: service_healthy
    environment:
      HASURA_GRAPHQL_METADATA_DATABASE_URL: postgres://postgres:${POSTGRES_PASSWORD:-postgrespassword}@postgres:5432/postgres
      PG_DATABASE_URL: postgres://postgres:${POSTGRES_PASSWORD:-postgrespassword}@postgres:5432/postgres
      HASURA_GRAPHQL_ENABLE_CONSOLE: "true"
      HASURA_GRAPHQL_DEV_MODE: "true"
      HASURA_GRAPHQL_ADMIN_SECRET: ${HASURA_ADMIN_SECRET:-changeme_in_production}
      HASURA_GRAPHQL_ENABLED_LOG_TYPES: startup, http-log, webhook-log, websocket-log, query-log
      HASURA_GRAPHQL_METADATA_DEFAULTS: '{"backend_configs":{"dataconnector":{"athena":{"uri":"http://data-connector-agent:8081/api/v1/athena"},"mariadb":{"uri":"http://data-connector-agent:8081/api/v1/mariadb"},"mysql8":{"uri":"http://data-connector-agent:8081/api/v1/mysql"},"oracle":{"uri":"http://data-connector-agent:8081/api/v1/oracle"},"snowflake":{"uri":"http://data-connector-agent:8081/api/v1/snowflake"}}}}'

  data-connector-agent:
    image: hasura/graphql-data-connector:v2.49.2
    restart: always
    ports:
      - "8081:8081"
    environment:
      QUARKUS_LOG_LEVEL: ERROR
      QUARKUS_OPENTELEMETRY_ENABLED: "false"
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8081/api/v1/athena/health"]
      interval: 5s
      timeout: 10s
      retries: 5
      start_period: 5s

volumes:
  db_data:

Wichtige Design-Entscheidungen in dieser Datei: Der postgres-Service bekommt einen Healthcheck mit pg_isready; graphql-engine wartet über depends_on: condition: service_healthy darauf, dass sowohl PostgreSQL als auch der Data-Connector-Agent bereit sind. Das db_data-Volume ist ein named Volume, das Docker automatisch anlegt und persistent hält.

Hinweis für reine PostgreSQL-Setups: Wenn du ausschließlich PostgreSQL nutzt, kannst du den data-connector-agent-Service und die entsprechende depends_on-Bedingung in graphql-engine weglassen. Das vereinfacht den Stack und spart Ressourcen.

Verifizieren:

docker compose -f /opt/hasura/compose.yaml config --quiet && echo "Syntax OK"

Erwartete Ausgabe: Syntax OK ohne Fehler.

Schritt 5: Stack starten

Wechsle in den Projektordner und starte den Stack im Hintergrund:

cd /opt/hasura
docker compose up -d

Beim ersten Start werden die Images von Docker Hub heruntergeladen (ca. 175 MB für die Engine, plus PostgreSQL und Connector). Das dauert je nach Internetverbindung zwei bis fünf Minuten. Danach starten die Container in der richtigen Reihenfolge: zuerst PostgreSQL (wartet auf Healthcheck), dann der Data-Connector-Agent, dann die GraphQL-Engine.

Verifizieren:

cd /opt/hasura
docker compose ps

Erwartete Ausgabe – alle drei Services müssen den Status running (healthy) zeigen:

NAME                         IMAGE                                        STATUS
hasura-postgres-1            postgres:15                                  Up X minutes (healthy)
hasura-graphql-engine-1      hasura/graphql-engine:v2.49.2               Up X minutes
hasura-data-connector-agent-1 hasura/graphql-data-connector:v2.49.2     Up X minutes (healthy)

Zeigt ein Service restarting oder exited, prüfe die Logs:

docker compose logs graphql-engine --tail=50

Schritt 6: Healthcheck und ersten API-Aufruf testen

Hasura bietet einen dedizierten Healthcheck-Endpoint, der auch für Monitoring und Load-Balancer geeignet ist:

curl -s http://localhost:8080/healthz

Erwartete Ausgabe:

OK

Teste anschließend den GraphQL-Endpoint direkt – mit dem Admin-Secret im Header:

curl -s -X POST http://localhost:8080/v1/graphql \
  -H "Content-Type: application/json" \
  -H "x-hasura-admin-secret: DEIN_ADMIN_SECRET" \
  -d '{"query": "{ __typename }"}'

Erwartete Ausgabe:

{"data":{"__typename":"query_root"}}

Verifizieren: Beide curl-Aufrufe antworten ohne Fehlermeldung. Ein HTTP 401 beim zweiten Aufruf deutet darauf hin, dass das Admin-Secret in der .env-Datei nicht korrekt eingelesen wurde – prüfe mit docker compose exec graphql-engine env | grep HASURA_GRAPHQL_ADMIN_SECRET.

Schritt 7: Web-Console öffnen und erste Tabelle anlegen

Öffne im Browser die Hasura-Console:

http://localhost:8080/console

Beim ersten Aufruf fragt die Console nach dem Admin-Secret. Gib den Wert aus deiner .env-Datei ein. Du landest auf dem Dashboard mit dem Tab „Data".

So verbindest du die PostgreSQL-Datenbank und legst eine erste Tabelle an:

1. Klick auf Data → Manage: Die Datenbank default (PostgreSQL) ist bereits als Datenquelle registriert, weil PG_DATABASE_URL gesetzt ist.
2. Klick auf default → Create Table: Lege z. B. eine Tabelle users mit den Spalten id (Integer, PK, autoincrement) und name (Text) an.
3. Wechsle in den Tab API (GraphiQL): Hasura hat automatisch Queries und Mutations generiert. Teste:

query {
  users {
    id
    name
  }
}

Verifizieren: Die GraphiQL-Oberfläche zeigt eine leere Liste [] – das ist korrekt für eine neue Tabelle. Fehlermeldungen wie „table not found" deuten darauf hin, dass die Tabelle noch nicht mit Hasura verknüpft (tracked) wurde. Klick auf „Track" neben der Tabelle im Data-Tab.

Schritt 8: Echtzeit-Subscriptions testen

Einer der größten Vorteile von Hasura ist, dass GraphQL Subscriptions ohne jede zusätzliche Konfiguration funktionieren. Für PostgreSQL nutzt Hasura intern LISTEN/NOTIFY, was echte Push-Semantik ohne Polling bedeutet.

Öffne in der GraphiQL-Console zwei Browser-Tabs. Im ersten Tab läuft eine Subscription:

subscription {
  users {
    id
    name
  }
}

Im zweiten Tab füge einen neuen Datensatz per Mutation ein:

mutation {
  insert_users_one(object: { name: "Alice" }) {
    id
    name
  }
}

Verifizieren: Das Subscription-Tab aktualisiert sich in Echtzeit und zeigt den neuen Datensatz ohne Seiten-Reload. Dies bestätigt, dass WebSocket-Verbindungen korrekt funktionieren.

Schritt 9: Externe Datenbank anbinden (optional)

Hasura kann mit einer bereits vorhandenen Datenbank verbunden werden, ohne deren Daten zu berühren. Hasura liest nur das Schema über INFORMATION_SCHEMA aus und schreibt seine Metadaten ausschließlich in die konfigurierte Metadata-Datenbank – nicht in die Applikationsdatenbank.

Klick in der Console auf Data → Connect Database und wähle den Datenbanktyp. Für PostgreSQL gibst du die Verbindungs-URL ein:

postgres://benutzer:passwort@host:5432/datenbankname

Für MySQL, Oracle, Snowflake, Athena oder MariaDB wird der data-connector-agent als Vermittler genutzt – er ist bereits im Stack konfiguriert. Wähle in der Console den passenden Connector-Typ und trage die Verbindungsdaten ein.

Wichtig für externe Datenbanken: Der Datenbankbenutzer benötigt mindestens USAGE auf dem Schema und SELECT auf den gewünschten Tabellen. Für Event-Trigger sind zusätzlich TRIGGER-Rechte erforderlich.

Verifizieren: Nach dem Verbinden erscheint die neue Datenquelle im Data-Tab. Klick auf Track All, um alle Tabellen sofort als GraphQL-Typen zu registrieren. Im API-Tab sollten die Tabellen sofort als Queries auftauchen.

Schritt 10: Berechtigungen konfigurieren (Row-Level Security)

Hasura implementiert feingranulare Zugriffskontrolle direkt in der Console – ohne SQL-Trigger oder externe Middleware. Klick auf eine Tabelle → Tab Permissions:

1. Rolle anlegen: z. B. user als Rolle definieren.
2. Row-Level-Filter: Definiere einen JSON-Filter, der bestimmt, welche Zeilen eine Rolle sehen darf – z. B. {"owner_id": {"_eq": "X-Hasura-User-Id"}}.
3. Column-Level: Wähle, welche Spalten für die Rolle sicht- oder schreibbar sind.

Diese Berechtigungen werden als Hasura-Metadaten in PostgreSQL gespeichert und beim Containerstart automatisch geladen. Für JWT-basierte Authentifizierung (Auth0, Keycloak etc.) wird HASURA_GRAPHQL_JWT_SECRET in der .env gesetzt.

Verifizieren: Teste einen Aufruf ohne Admin-Secret und mit der Rolle user im Header:

curl -s -X POST http://localhost:8080/v1/graphql \
  -H "Content-Type: application/json" \
  -H "x-hasura-role: user" \
  -d '{"query": "{ users { id name } }"}'

Erwartete Ausgabe: Nur die Zeilen, die dem konfigurierten Filter entsprechen (oder eine leere Liste, falls keine Zeilen passen).

Schritt 11: Produktion absichern

Für den Produktionsbetrieb sind folgende Anpassungen in der .env-Datei und der compose.yaml notwendig:

# Produktions-Ergänzungen für .env

# Console deaktivieren – Schema-Änderungen nur per CLI/Migrations
HASURA_GRAPHQL_ENABLE_CONSOLE=false

# Dev-Mode deaktivieren – keine internen Fehlerdetails in API-Antworten
HASURA_GRAPHQL_DEV_MODE=false

# query-log aus den Log-Typen entfernen (sehr großes Log-Volumen unter Last)
HASURA_GRAPHQL_ENABLED_LOG_TYPES=startup, http-log, webhook-log, websocket-log

# CORS auf erlaubte Domains einschränken
HASURA_GRAPHQL_CORS_DOMAIN=https://meine-app.example.com

Für TLS und HTTPS stelle Hasura hinter einen Reverse Proxy. Eine bewährte Lösung ist Traefik mit automatischem Let's-Encrypt-Zertifikat – die Grundkonfiguration erklärt Traefik als Docker-Reverse-Proxy mit automatischem HTTPS. Alternativ funktioniert auch Caddy, wie in Caddy als Reverse Proxy einrichten beschrieben.

Den Port 8081 des Data-Connector-Agents solltest du in Produktion nicht auf dem Host exponieren – entferne das ports-Mapping aus dem data-connector-agent-Service in der compose.yaml.

Verifizieren:

cd /opt/hasura
docker compose down && docker compose up -d
curl -s http://localhost:8080/console

Mit HASURA_GRAPHQL_ENABLE_CONSOLE=false antwortet /console mit HTTP 404. Der /v1/graphql-Endpoint ist weiterhin erreichbar (nur mit Admin-Secret oder gültigem JWT).

Schritt 12: Updates und Backup

Um Hasura auf eine neue Version zu aktualisieren, ändere den Image-Tag in der compose.yaml (z. B. auf v2.50.0) und führe aus:

cd /opt/hasura
docker compose pull
docker compose up -d

Das laufende System wird dabei kurz unterbrochen. Für Zero-Downtime-Updates ist eine Orchestrierung mit Kubernetes oder Docker Swarm notwendig.

Das einzige, was du zwingend sichern musst, ist das db_data-Volume: Es enthält sowohl die PostgreSQL-Applikationsdaten als auch die Hasura-Metadaten (Berechtigungen, Relationships, Actions, Event-Trigger). Nutze pg_dump für konsistente Datenbankbackups, wie in PostgreSQL pg_dump und pg_restore: Backup und Migration beschrieben.

Warnung: Lösche niemals das db_data-Volume, ohne vorher hasura metadata export (Hasura CLI) ausgeführt zu haben. Sonst verlierst du alle konfigurierten Berechtigungen, Relationships und Actions.

Verifizieren:

docker compose ps
curl -s http://localhost:8080/healthz

Erwartete Ausgabe: alle Services running (healthy), Healthcheck antwortet mit OK.

Troubleshooting / Typische Fehler

1. „could not connect to server" beim Start: graphql-engine startet, bevor PostgreSQL bereit ist. Ursache: fehlendes oder falsch konfiguriertes healthcheck im postgres-Service. Lösung: Die compose.yaml aus dieser Anleitung enthält den korrekten pg_isready-Healthcheck mit depends_on: condition: service_healthy.
2. HTTP 401 bei allen API-Aufrufen: HASURA_GRAPHQL_ADMIN_SECRET ist gesetzt, aber der Header fehlt im Request. Lösung: Header x-hasura-admin-secret: DEIN_SECRET zum API-Call hinzufügen.
3. „Metadata inconsistency" nach Neustart: Das db_data-Volume wurde gelöscht oder falsch gemountet. Lösung: Volume-Persistenz sicherstellen; prüfe mit docker volume ls | grep db_data.
4. Data Connector Agent nicht erreichbar: graphql-engine startet, bevor der Agent healthy ist. Lösung: Den start_period im Healthcheck des data-connector-agent erhöhen (auf ARM-Systemen ggf. auf 15–30 Sekunden).
5. CORS-Fehler im Browser: HASURA_GRAPHQL_CORS_DOMAIN enthält nicht die exakte Origin der Frontend-App. Lösung: Vollständige URL mit Schema und Port angeben, z. B. https://app.example.com:3000.
6. „permission denied" bei externer Datenbank: Der DB-User hat keine ausreichenden Rechte. Für Read-Only genügen USAGE auf dem Schema und SELECT auf den Tabellen. Event-Trigger benötigen zusätzlich TRIGGER-Rechte.
7. Subscriptions funktionieren nicht mit MySQL/MSSQL: Echtzeit-Subscriptions per LISTEN/NOTIFY sind PostgreSQL-exklusiv. Für andere Datenbanken nutzt Hasura Polling; das Intervall ist über HASURA_GRAPHQL_LIVE_QUERIES_MULTIPLEXED_REFETCH_INTERVAL konfigurierbar.
8. Sehr großes Log-Volumen in Produktion: query-log in HASURA_GRAPHQL_ENABLED_LOG_TYPES aktiviert. Lösung: query-log aus den aktivierten Log-Typen in der Produktions-.env entfernen.

Häufige Fragen

Kann ich Hasura mit einer bereits vorhandenen Datenbank verbinden, ohne Daten zu verlieren?

Ja, uneingeschränkt. Hasura schreibt keine Daten in die Applikationsdatenbank und ändert keine bestehenden Tabellen oder Daten. Hasura liest nur das Schema über INFORMATION_SCHEMA aus und speichert seine eigenen Metadaten (Berechtigungen, Relationships, Actions) ausschließlich in der separat konfigurierten Metadata-Datenbank. Du fügst die bestehende Datenbank einfach als neue Datenquelle über die Console hinzu.

Was ist der Unterschied zwischen Hasura v2 und Hasura v3 (DDN)?

Hasura v2 ist die etablierte, stabile Version für Self-Hosted-Docker-Deployments und wird aktiv gepflegt. Hasura v3 (DDN, Data Delivery Network) ist eine neu architekturierte Version mit Supergraph-Konzept, ebenfalls Open Source (Apache 2.0), hat aber einen anderen Setup-Flow und CLI-Workflow. Für einfache Docker-Compose-Deployments ist v2 der empfohlene und dokumentierte Einstieg – genau das, was diese Anleitung zeigt.

Benötige ich den data-connector-agent für reine PostgreSQL-Setups?

Nein. Der data-connector-agent wird nur benötigt, wenn du Nicht-Postgres-Datenbanken (MySQL 8, Oracle, Snowflake, Athena, MariaDB) anbinden willst. Für reine PostgreSQL-Setups entferne den Service aus der compose.yaml und passe das depends_on in graphql-engine entsprechend an. Das vereinfacht den Stack erheblich.

Wie sichere ich Hasura für den Produktionsbetrieb ab?

Die Mindestmaßnahmen: (1) HASURA_GRAPHQL_ADMIN_SECRET auf einen langen Zufallswert setzen, (2) HASURA_GRAPHQL_ENABLE_CONSOLE=false in Produktion, (3) HASURA_GRAPHQL_DEV_MODE=false, (4) JWT- oder Webhook-Auth für Endnutzer konfigurieren, (5) HASURA_GRAPHQL_CORS_DOMAIN auf erlaubte Domains einschränken, (6) Port 8080 hinter einem Reverse Proxy mit TLS betreiben, (7) Port 8081 des Data-Connector-Agents nicht auf dem Host exponieren.

Wie funktionieren automatische Datenbankmigrationen mit Hasura?

Das cli-migrations-v3-Image-Variant führt beim Container-Start automatisch SQL-Migrationen aus dem gemounteten Verzeichnis /hasura-migrations aus und wendet Metadaten aus /hasura-metadata an. Migrationen werden mit der Hasura CLI per hasura migrate create erstellt und versioniert in Git gespeichert. Das ermöglicht vollständig code-basierte, reproduzierbare Deployments – ideal für CI/CD-Pipelines.

Kann Hasura als Read-Only-API vor einer Produktionsdatenbank betrieben werden?

Ja. Erstelle einen dedizierten Datenbankbenutzer mit ausschließlich SELECT-Rechten auf die gewünschten Schemas und Tabellen, konfiguriere diesen in PG_DATABASE_URL, und definiere in Hasura ausschließlich Query-Berechtigungen für die entsprechenden Rollen. Mutations und Subscriptions können pro Rolle und Tabelle gezielt deaktiviert werden.

Fazit

Hasura ist eines der produktivsten Werkzeuge für Entwickler und Teams, die schnell eine typsichere GraphQL-API über bestehende oder neue Datenbanken aufbauen wollen. Der Docker-Compose-Stack aus dieser Anleitung ist in unter zehn Minuten lauffähig und produziert sofort vollständige Queries, Mutations und Echtzeit-Subscriptions. Die feingranulare Berechtigungslogik direkt in der Console – ohne SQL-Trigger oder externe Middleware – ist dabei ein echter Produktivitätsgewinn gegenüber manuell geschriebenen Resolvern.

Die wichtigsten Punkte für den produktiven Einsatz: Admin-Secret immer setzen, Console in Produktion deaktivieren, den Stack hinter einen Reverse Proxy mit TLS stellen und das db_data-Volume regelmäßig sichern. Wer Hasura für reine PostgreSQL-Setups nutzt, kann den Data-Connector-Agent weglassen und spart dabei Ressourcen und Komplexität. Für Teams, die auf Code-basierte Deployments setzen, lohnt sich der Blick auf das cli-migrations-v3-Image und die Hasura CLI – damit lassen sich Schema-Änderungen und Berechtigungen versioniert und reproduzierbar verwalten.

Weiterführende Anleitungen und Quellen

1. PostgreSQL pg_dump und pg_restore: Backup und Migration per Kommandozeile – für konsistente Datenbankbackups des Hasura-Metadaten-Stores.
2. Traefik als Docker-Reverse-Proxy mit automatischem HTTPS einrichten – empfohlener Weg, um Hasura mit TLS abzusichern.
3. Docker Compose absichern: Secrets, Healthchecks, Non-Root und Read-Only für den Produktivbetrieb – weitergehende Härtung des Compose-Setups.
4. Directus mit Docker installieren: Verwandelt jede bestehende SQL-Datenbank in eine API – Alternative zu Hasura für REST-first-Ansätze und Content-Management.

Offizielle Quellen: Hasura Getting Started mit Docker | Hasura GitHub Repository | Hasura Docker Hub Image