Budibase mit Docker installieren: Operations-Plattform für interne Apps und Automationen

Interne Tools bauen kostet in klassischen Projekten Wochen – Budibase halbiert diese Zeit erheblich. Die Open-Source-Plattform bietet einen visuellen App-Builder für CRUD-Anwendungen, Dashboards und Genehmigungsworkflows, einen Automations-Designer mit Trigger-Logik sowie einen integrierten KI-Agenten-Layer über LiteLLM. Mit über 28.000 GitHub-Stars und mehr als einer Million Docker-Hub-Pulls ist Budibase eine der aktivsten Self-Hosted-No-Code-Plattformen im KMU-Umfeld. Diese Anleitung zeigt dir, wie du den vollständigen Compose-Stack auf einem beliebigen Linux-Host aufsetzt, Secrets sicher konfigurierst und die Installation Schritt für Schritt verifizierst.

Voraussetzungen

1. Docker Engine >= 20.10 und das Compose-Plugin v2 (docker compose, nicht das veraltete docker-compose) – wie du beides auf Ubuntu/Debian installierst, erklärt die Docker-Compose-Grundlage.
2. Linux-Host, VM oder NAS mit Docker-Unterstützung; x86_64 (amd64) offiziell unterstützt – auf ARM-Hosts (z. B. Raspberry Pi) ggf. testen, da arm64 nicht explizit dokumentiert ist.
3. Mindestens 4 GB RAM (2 GB absolutes Minimum, mit LiteLLM knapp) und 10 GB freier Speicher (Images allein ca. 3–4 GB).
4. Netzwerkzugang zu Docker Hub und ghcr.io für den ersten Image-Pull.
5. Optional: Reverse Proxy (Nginx, Traefik oder Caddy) für HTTPS-Terminierung – Budibase selbst läuft intern über HTTP.

Eckdaten auf einen Blick

Schritt 1: Projektordner und Verzeichnisstruktur anlegen

Lege einen dedizierten Ordner für den Budibase-Stack an. Alle Compose-Dateien, die .env und die LiteLLM-Konfiguration landen hier.

sudo mkdir -p /opt/budibase
cd /opt/budibase

Auf einem Heimserver oder NAS kannst du auch ~/budibase verwenden – der Pfad ist beliebig, solange Docker darauf zugreifen darf.

Verifizieren: ls -la /opt/budibase zeigt das leere Verzeichnis. Kein Fehler, kein „Permission denied".

Schritt 2: Compose-Datei anlegen

Erstelle die Datei /opt/budibase/docker-compose.yaml mit folgendem Inhalt. Die Struktur entspricht der offiziellen hosting/docker-compose.yaml aus dem Budibase-GitHub-Repository.

version: "3"

# Budibase Self-Hosted Docker Compose Stack
# Quelle: https://github.com/budibase/budibase/blob/master/hosting/docker-compose.yaml
# Vor dem Start: .env anlegen und alle Secrets ersetzen!
# Start: docker compose up -d
# Web-UI: http://<server-ip>:10000

services:
  app-service:
    restart: unless-stopped
    image: budibase/apps
    container_name: bbapps
    environment:
      SELF_HOSTED: 1
      COUCH_DB_URL: http://${COUCH_DB_USER}:${COUCH_DB_PASSWORD}@couchdb-service:5984
      WORKER_URL: http://worker-service:4003
      MINIO_URL: http://minio-service:9000
      MINIO_ACCESS_KEY: ${MINIO_ACCESS_KEY}
      MINIO_SECRET_KEY: ${MINIO_SECRET_KEY}
      INTERNAL_API_KEY: ${INTERNAL_API_KEY}
      BUDIBASE_ENVIRONMENT: ${BUDIBASE_ENVIRONMENT}
      PORT: 4002
      API_ENCRYPTION_KEY: ${API_ENCRYPTION_KEY}
      JWT_SECRET: ${JWT_SECRET}
      LOG_LEVEL: info
      ENABLE_ANALYTICS: "true"
      REDIS_URL: redis-service:6379
      REDIS_PASSWORD: ${REDIS_PASSWORD}
      REDIS_USERNAME: ${REDIS_USERNAME:-}
      LITELLM_URL: http://litellm-service:4000
      LITELLM_MASTER_KEY: ${LITELLM_MASTER_KEY}
      BB_ADMIN_USER_EMAIL: ${BB_ADMIN_USER_EMAIL}
      BB_ADMIN_USER_PASSWORD: ${BB_ADMIN_USER_PASSWORD}
      PLUGINS_DIR: ${PLUGINS_DIR}
      OFFLINE_MODE: ${OFFLINE_MODE:-}
    depends_on:
      - worker-service
      - redis-service
      - litellm-service
    # Fuer Plugins: Auskommentierung entfernen und Pfad anpassen
    # volumes:
    #   - /pfad/zu/plugins:/plugins

  worker-service:
    restart: unless-stopped
    image: budibase/worker
    container_name: bbworker
    environment:
      SELF_HOSTED: 1
      PORT: 4003
      CLUSTER_PORT: ${MAIN_PORT}
      API_ENCRYPTION_KEY: ${API_ENCRYPTION_KEY}
      JWT_SECRET: ${JWT_SECRET}
      MINIO_ACCESS_KEY: ${MINIO_ACCESS_KEY}
      MINIO_SECRET_KEY: ${MINIO_SECRET_KEY}
      MINIO_URL: http://minio-service:9000
      APPS_URL: http://app-service:4002
      COUCH_DB_USERNAME: ${COUCH_DB_USER}
      COUCH_DB_PASSWORD: ${COUCH_DB_PASSWORD}
      COUCH_DB_URL: http://${COUCH_DB_USER}:${COUCH_DB_PASSWORD}@couchdb-service:5984
      INTERNAL_API_KEY: ${INTERNAL_API_KEY}
      REDIS_URL: redis-service:6379
      REDIS_PASSWORD: ${REDIS_PASSWORD}
      REDIS_USERNAME: ${REDIS_USERNAME:-}
      LITELLM_URL: http://litellm-service:4000
      LITELLM_MASTER_KEY: ${LITELLM_MASTER_KEY}
      OFFLINE_MODE: ${OFFLINE_MODE:-}
    depends_on:
      - redis-service
      - minio-service
      - litellm-service

  minio-service:
    restart: unless-stopped
    image: minio/minio
    volumes:
      - minio_data:/data
    environment:
      MINIO_ACCESS_KEY: ${MINIO_ACCESS_KEY}
      MINIO_SECRET_KEY: ${MINIO_SECRET_KEY}
      MINIO_BROWSER: "off"
    command: server /data --console-address ":9001"
    healthcheck:
      test: "timeout 5s bash -c ':> /dev/tcp/127.0.0.1/9000' || exit 1"
      interval: 30s
      timeout: 20s
      retries: 3

  proxy-service:
    restart: unless-stopped
    ports:
      - "${MAIN_PORT}:10000"
    container_name: bbproxy
    image: budibase/proxy
    environment:
      - PROXY_RATE_LIMIT_WEBHOOKS_PER_SECOND=10
      - PROXY_RATE_LIMIT_API_PER_SECOND=50
      - APPS_UPSTREAM_URL=http://app-service:4002
      - WORKER_UPSTREAM_URL=http://worker-service:4003
      - MINIO_UPSTREAM_URL=http://minio-service:9000
      - COUCHDB_UPSTREAM_URL=http://couchdb-service:5984
      - RESOLVER=127.0.0.11
    depends_on:
      - minio-service
      - worker-service
      - app-service
      - couchdb-service

  couchdb-service:
    restart: unless-stopped
    image: budibase/database:2.1.0
    environment:
      - COUCHDB_PASSWORD=${COUCH_DB_PASSWORD}
      - COUCHDB_USER=${COUCH_DB_USER}
      - TARGETBUILD=docker-compose
      - DATA_DIR=/data
    volumes:
      - couchdb3_data:/data

  redis-service:
    restart: unless-stopped
    image: redis
    command: redis-server --requirepass "${REDIS_PASSWORD}"
    volumes:
      - redis_data:/data

  litellm-service:
    restart: unless-stopped
    image: ghcr.io/berriai/litellm:main-v1.83.10-stable
    ports:
      - "${LITELLM_PORT:-4000}:4000"
    volumes:
      - ./litellm_config.yaml:/app/config.yaml
    environment:
      DATABASE_URL: "postgresql://${LITELLM_DB_USER}:${LITELLM_DB_PASSWORD}@litellm-db:5432/${LITELLM_DB_NAME}"
      STORE_MODEL_IN_DB: "True"
      LITELLM_REASONING_AUTO_SUMMARY: "true"
      LITELLM_MASTER_KEY: ${LITELLM_MASTER_KEY}
      LITELLM_SALT_KEY: ${LITELLM_SALT_KEY}
    command: ["--config", "/app/config.yaml"]
    depends_on:
      - litellm-db
    healthcheck:
      test: ["CMD-SHELL", "wget --no-verbose --tries=1 http://localhost:4000/health/liveliness || exit 1"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 40s

  litellm-db:
    restart: unless-stopped
    image: postgres:16
    environment:
      POSTGRES_DB: ${LITELLM_DB_NAME}
      POSTGRES_USER: ${LITELLM_DB_USER}
      POSTGRES_PASSWORD: ${LITELLM_DB_PASSWORD}
    volumes:
      - litellm_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -d ${LITELLM_DB_NAME} -U ${LITELLM_DB_USER}"]
      interval: 1s
      timeout: 5s
      retries: 10

volumes:
  couchdb3_data:
    driver: local
  minio_data:
    driver: local
  redis_data:
    driver: local
  litellm_data:
    driver: local

Wichtig: Die Budibase-eigenen Images (budibase/apps, budibase/worker, budibase/proxy) verwenden bewusst keinen gepinnten Tag und ziehen damit immer latest. Nur budibase/database:2.1.0 und das LiteLLM-Image sind auf konkrete Versionen gepinnt. Das entspricht der offiziellen Compose-Datei im GitHub-Repository.

Verifizieren: docker compose config --quiet im Projektordner darf keinen YAML-Syntaxfehler ausgeben. Ohne .env erscheinen Warnungen zu nicht gesetzten Variablen – das ist an dieser Stelle normal.

Schritt 3: .env-Datei mit sicheren Secrets anlegen

Die .env-Datei muss im selben Verzeichnis wie docker-compose.yaml liegen. Ohne sie werden alle ${VARIABLE}-Referenzen als leer interpretiert, was zu Authentifizierungsfehlern beim Start führt.

Generiere zunächst sichere Zufallswerte für alle kritischen Secrets:

openssl rand -hex 32  # je einmal ausfuehren fuer JWT_SECRET, API_ENCRYPTION_KEY,
                      # INTERNAL_API_KEY, COUCH_DB_PASSWORD, MINIO_SECRET_KEY,
                      # REDIS_PASSWORD, LITELLM_MASTER_KEY, LITELLM_SALT_KEY

Erstelle dann /opt/budibase/.env mit folgendem Inhalt und ersetze alle Platzhalter HIER_AENDERN durch die generierten Werte:

# ============================================================
# Budibase .env – VOR dem ersten Start alle Secrets ersetzen!
# Standardwerte (testsecret/budibase) sind NICHT produktionsreif.
# ============================================================

# --- Pflicht-Secrets (sichere Zufallswerte verwenden!) ---
JWT_SECRET=HIER_AENDERN
API_ENCRYPTION_KEY=HIER_AENDERN
INTERNAL_API_KEY=HIER_AENDERN

# --- CouchDB ---
COUCH_DB_USER=budibase
COUCH_DB_PASSWORD=HIER_AENDERN

# --- MinIO ---
MINIO_ACCESS_KEY=budibase
MINIO_SECRET_KEY=HIER_AENDERN

# --- Redis ---
REDIS_PASSWORD=HIER_AENDERN
REDIS_USERNAME=

# --- LiteLLM (KI-Proxy) ---
LITELLM_MASTER_KEY=HIER_AENDERN
LITELLM_SALT_KEY=HIER_AENDERN
LITELLM_DB_NAME=litellm
LITELLM_DB_USER=llmproxy
LITELLM_DB_PASSWORD=HIER_AENDERN

# --- Port-Konfiguration ---
MAIN_PORT=10000
LITELLM_PORT=4000

# --- Betrieb ---
BUDIBASE_ENVIRONMENT=PRODUCTION
BB_ADMIN_USER_EMAIL=admin@beispiel.de
BB_ADMIN_USER_PASSWORD=HIER_AENDERN
PLUGINS_DIR=
OFFLINE_MODE=

Folgende Variablen sind sicherheitskritisch und müssen vor dem ersten Start geändert werden:

Verifizieren:

grep -c "HIER_AENDERN" /opt/budibase/.env

Die Ausgabe muss 0 sein – kein Platzhalter darf noch stehen.

Schritt 4: litellm_config.yaml anlegen

Der litellm-service erwartet einen Bind Mount auf ./litellm_config.yaml. Fehlt diese Datei, bricht der Container mit „no such file or directory" ab. Für den Start reicht eine leere Datei:

touch /opt/budibase/litellm_config.yaml

Möchtest du direkt einen LLM-Provider anbinden (z. B. OpenAI oder ein lokales Ollama), kannst du die Konfiguration später ergänzen und den Stack mit docker compose down && docker compose up -d neu starten.

Verifizieren: ls -la /opt/budibase/ zeigt drei Dateien: docker-compose.yaml, .env und litellm_config.yaml. Alle drei müssen vor dem nächsten Schritt vorhanden sein.

Schritt 5: Stack starten

Wechsle in den Projektordner und starte alle acht Dienste im Hintergrund:

cd /opt/budibase
docker compose up -d

Beim ersten Start lädt Docker alle Images herunter (ca. 3–4 GB). Das dauert je nach Verbindung 5–15 Minuten. Anschließend initialisieren CouchDB und MinIO ihre Datenverzeichnisse – das braucht weitere 10–30 Sekunden.

Bekannte Stolperfalle: depends_on prüft nur, ob Container gestartet sind, nicht ob die Dienste bereit sind. CouchDB und MinIO benötigen einige Sekunden zur Initialisierung. Stürzt app-service oder worker-service beim ersten Versuch ab, führe einfach docker compose up -d ein zweites Mal aus.

Verifizieren:

docker compose ps

Erwartete Ausgabe (alle Dienste in Spalte STATUS als Up oder Up (healthy)):

NAME          IMAGE                                          STATUS
bbapps        budibase/apps                                  Up
bbworker      budibase/worker                                Up
bbproxy       budibase/proxy                                 Up
...           budibase/database:2.1.0                        Up
...           minio/minio                                    Up (healthy)
...           redis                                          Up
...           ghcr.io/berriai/litellm:main-v1.83.10-stable  Up (healthy)
...           postgres:16                                    Up (healthy)

Prüfe außerdem, ob der Proxy antwortet:

curl -I http://localhost:10000

Erwartetes Ergebnis: HTTP/1.1 200 OK oder HTTP/1.1 302 Found (Redirect zum Setup-Wizard).

Schritt 6: Erst-Einrichtung im Browser

Rufe im Browser http://<server-ip>:10000 auf. Falls du BB_ADMIN_USER_EMAIL und BB_ADMIN_USER_PASSWORD in der .env gesetzt hast, wurde der Admin-Account bereits automatisch angelegt – du kannst dich direkt einloggen. Andernfalls begrüßt dich ein Setup-Wizard, der dich durch die Admin-Erstellung führt.

Nach dem Login siehst du das Budibase-Dashboard. Von hier aus erstellst du deine erste App über „Create new app", verbindest externe Datenquellen (PostgreSQL, MySQL, REST-APIs, Google Sheets) und baust Formulare, Tabellen und Automationen per Drag-and-drop zusammen.

Verifizieren: Die Budibase-Oberfläche lädt vollständig, ohne Konsolfehler im Browser (F12 → Console). Der Login mit den Admin-Credentials funktioniert, und du siehst das leere App-Dashboard.

Schritt 7: Reverse Proxy und HTTPS (empfohlen)

Für den Produktivbetrieb sollte Budibase nicht direkt über HTTP erreichbar sein. Stelle einen Reverse Proxy vor Port 10000 und lass ihn die TLS-Terminierung übernehmen. Budibase selbst läuft intern über HTTP – das ist korrekt so.

Setze in der .env den internen Port (z. B. MAIN_PORT=10000) und weise deinen Reverse Proxy an, HTTPS-Anfragen an http://127.0.0.1:10000 weiterzuleiten. Wie du Caddy, Traefik oder Nginx als Reverse Proxy mit automatischem HTTPS einrichtest, zeigen unsere Anleitungen:

1. Caddy als Reverse Proxy mit automatischem HTTPS einrichten
2. Traefik als Docker-Reverse-Proxy mit automatischem HTTPS

Hinweis zu LiteLLM: Der litellm-service exponiert Port 4000 standardmäßig nach außen. Wenn du KI-Features intern halten möchtest, schütze diesen Port mit einer Firewall-Regel oder entferne den ports-Eintrag für LiteLLM aus der Compose-Datei.

Verifizieren: Nach der Reverse-Proxy-Konfiguration erreichst du Budibase unter deiner Domain über HTTPS. curl -I https://budibase.beispiel.de liefert HTTP/2 200 oder einen Redirect.

Schritt 8: Updates durchführen und Backup

Da die Budibase-Images den latest-Tag verwenden, reicht ein einfaches Pull-and-Restart für Updates:

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

Erstelle vor jedem Update ein Backup der Named Volumes. Die Daten liegen unter Linux in /var/lib/docker/volumes/:

# Stack stoppen, Volumes sichern, Stack wieder starten
docker compose stop
docker run --rm \
  -v budibase_couchdb3_data:/data \
  -v /backup:/backup \
  alpine tar czf /backup/couchdb-$(date +%Y%m%d).tar.gz /data
docker run --rm \
  -v budibase_minio_data:/data \
  -v /backup:/backup \
  alpine tar czf /backup/minio-$(date +%Y%m%d).tar.gz /data
docker compose start

Konfigurationsänderungen (neue Env-Vars, Port-Wechsel) erfordern einen vollständigen Neustart: docker compose down && docker compose up -d. Ein einfaches docker compose restart übernimmt keine Umgebungsvariablen-Änderungen.

Wie du Container-Updates automatisieren und Backups in eine 3-2-1-Strategie einbetten kannst, beschreiben die Anleitungen Docker-Container automatisch aktualisieren: Diun, WUD und Renovate und 3-2-1-Backup-Strategie praktisch umsetzen.

Verifizieren: Nach dem Update zeigt docker compose ps erneut alle Dienste als Up. Prüfe im Budibase-UI unter „Settings → About", ob die neue Version angezeigt wird.

Troubleshooting / Typische Fehler

1. „bind: address already in use" auf Port 10000: Ein anderer Dienst (z. B. Webmin oder Synology DSM) belegt diesen Port bereits. Lösung: MAIN_PORT=10001 (oder einen freien Port) in der .env setzen, dann docker compose down && docker compose up -d.
2. „no such file or directory" beim litellm-service: Die Datei litellm_config.yaml fehlt im Compose-Verzeichnis. Lösung: touch /opt/budibase/litellm_config.yaml, dann Stack neu starten.
3. app-service oder worker-service crashen beim ersten Start: CouchDB oder MinIO waren noch nicht bereit. Lösung: 20–30 Sekunden warten, dann docker compose up -d nochmals ausführen. Mit docker compose logs couchdb-service kannst du prüfen, ob CouchDB vollständig initialisiert ist.
4. Login schlägt fehl mit 401 / „Invalid credentials": Wahrscheinlich wurden Volumes aus einer früheren Installation mit anderen Secrets angelegt. Lösung für einen sauberen Neustart: docker compose down -v (Achtung: löscht alle Daten!), dann neue Secrets in .env setzen und Stack neu starten.
5. Port 10000 antwortet nicht (curl: Connection refused): Prüfe mit docker compose logs proxy-service, ob der Nginx-Proxy gestartet ist. Häufige Ursache: Fehlende oder leere Umgebungsvariablen durch unvollständige .env.
6. LiteLLM-API von außen erreichbar: Port 4000 ist standardmäßig nach außen exponiert. Wenn KI-Features intern bleiben sollen, die ports-Sektion des litellm-service aus der Compose-Datei entfernen oder mit UFW sperren: sudo ufw deny 4000.
7. Konfigurationsänderung hat keine Wirkung: Ein einfaches docker compose restart übernimmt keine neuen Env-Vars. Immer docker compose down && docker compose up -d verwenden.

Häufige Fragen

Brauche ich LiteLLM, wenn ich keine KI-Features nutzen will?

Ja – litellm-service ist in der offiziellen Compose-Datei als Abhängigkeit von app-service und worker-service definiert. Der Dienst muss laufen, auch wenn du keinen LLM-Provider anbindest. Die litellm_config.yaml darf dabei leer bleiben. Der Overhead ist gering: LiteLLM wartet einfach auf Verbindungen.

Wie erstelle ich den ersten Admin-Account?

Entweder du setzt BB_ADMIN_USER_EMAIL und BB_ADMIN_USER_PASSWORD in der .env vor dem ersten Start – dann wird der Account automatisch angelegt. Oder du lässt beide Variablen leer: Budibase zeigt beim ersten Aufruf von http://<server-ip>:10000 einen Setup-Wizard.

Kann ich PostgreSQL, MySQL oder andere externe Datenbanken verwenden?

Ja – und das ist eine der Stärken von Budibase. Externe Datenquellen (PostgreSQL, MySQL, MSSQL, SQLite, Oracle, MongoDB, REST-APIs, Google Sheets) werden als Verbindungen in der App-Builder-UI konfiguriert. Sie werden nicht im Compose-Stack mitgeliefert. CouchDB im Stack ist ausschließlich für Budibase-interne Metadaten (App-Definitionen, User, Automations-Logs).

Wie aktiviere ich den Offline-Modus?

Setze OFFLINE_MODE=1 in der .env und starte den Stack neu. Das deaktiviert externe Verbindungen für Telemetrie und Template-Updates – sinnvoll für isolierte Netzwerke ohne Internetzugang.

Wie kann ich anonyme Nutzungsdaten deaktivieren?

Setze in der .env – oder direkt im environment-Block des app-service – ENABLE_ANALYTICS=false. Danach docker compose down && docker compose up -d.

Was ist der Unterschied zwischen dem All-in-One-Image und dem Compose-Stack?

budibase/budibase:latest (1,1 GB) ist ein einzelner Container, der alle Dienste intern bündelt. Er ist ideal für schnelle Tests und Evaluierungen. Für den Produktivbetrieb empfiehlt Budibase den Multi-Service-Compose-Stack: Er erlaubt individuelle Skalierung, separate Volume-Verwaltung und ein sauberes Upgrade-Management pro Dienst.

Funktioniert Budibase auf ARM-Hardware (Raspberry Pi, Apple Silicon)?

Auf Docker Hub ist arm64-Unterstützung für die Budibase-Images nicht explizit dokumentiert. Auf Apple-Silicon-Macs (mit Docker Desktop und Rosetta) funktioniert es in der Regel, auf einem Raspberry Pi ist das Ergebnis uneinheitlich. Im Zweifel einfach testen: docker compose up -d starten und docker compose logs auf „exec format error" prüfen.

Fazit

Budibase ist eine ausgereifte Operations-Plattform für KMU-Teams, die interne Apps und Automationen schnell produktiv haben wollen, ohne eine Entwicklungsabteilung zu beschäftigen. Der Docker-Compose-Stack ist mit acht Diensten zunächst imposant – aber die Arbeitsteilung ist klar: CouchDB und MinIO sind Pflicht, LiteLLM ist optional und Redis ist schlank. Der einzige nach außen sichtbare Zugangspunkt ist Port 10000 über den Nginx-Proxy-Service, was die Angriffsfläche minimal hält.

Die wichtigste Takeaway dieser Anleitung: Secrets vor dem ersten Start ändern. Wer den Stack mit den Standardwerten hochfährt und vergisst, die .env anzupassen, hat eine trivial kompromittierbare Instanz. Mit openssl rand -hex 32 ist das in zwei Minuten erledigt.

Für den nächsten Schritt empfiehlt sich ein Blick auf ähnliche Low-Code- und Workflow-Plattformen, die sich gut mit Budibase ergänzen: n8n für KI-Workflows und Automatisierung oder Dify als Plattform für KI-Apps und Agenten.

Weiterführende Anleitungen und Quellen

1. Docker und Docker Compose auf Linux installieren (Ubuntu/Debian)
2. Docker Compose absichern: Secrets, Healthchecks, Non-Root
3. n8n mit Docker: KI-Workflows und Automatisierung self-hosted
4. Dify mit Docker: Plattform für KI-Apps und Agenten (LLMOps)

Offizielle Quellen: Budibase hosting/docker-compose.yaml (GitHub), hosting/.env (GitHub), Docker Hub – budibase/budibase.