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

Budibase ist eine Open-Source-Plattform für interne Anwendungen: App-Builder für Datenbank-Oberflächen und Genehmigungsworkflows, Automationen und KI-Anbindung über den Proxy LiteLLM. Diese Anleitung richtet den offiziellen Compose-Stack auf einem Linux-Host ein.

Voraussetzungen

1. Docker Engine >= 20.10 und das Compose-Plugin v2 (docker compose, nicht das veraltete docker-compose); die Installation unter Ubuntu/Debian beschreibt die Docker-Compose-Grundlage.
2. Linux-Host oder VM, amd64 oder arm64 (die Budibase-Images auf Docker Hub gibt es für beide Architekturen).
3. Mindestens 2 CPU-Kerne, 4 GB RAM und 10 GB freier Speicher (Images allein etwa 3 bis 4 GB).
4. Netzwerkzugang zu Docker Hub für den ersten Image-Pull (alle Images einschließlich MinIO kommen seit 3.49 von dort).
5. Für den Zugriff aus dem Netz: Reverse Proxy (Caddy, Traefik oder Nginx) mit HTTPS; Budibase selbst spricht nur HTTP.

Eckdaten auf einen Blick

Schritt 1: Projektordner und Verzeichnisstruktur anlegen

Legen Sie einen eigenen Ordner für den Stack an. Compose-Datei, .env und LiteLLM-Konfiguration liegen hier; der Ordnername budibase bestimmt das Präfix der Volumes (budibase_…).

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

Verifizieren: ls -la /opt/budibase zeigt das leere Verzeichnis ohne „Permission denied“.

Schritt 2: Compose-Datei anlegen

Erstellen Sie /opt/budibase/docker-compose.yaml. Die Datei entspricht der offiziellen hosting/docker-compose.yaml (Stand Version 3.50.0), ergänzt um feste Versionen und Portbindung an 127.0.0.1.

# 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://127.0.0.1:10000 (SSH-Tunnel oder Reverse Proxy)

services:
  app-service:
    restart: unless-stopped
    image: budibase/apps:v3.50.0
    container_name: bbapps
    environment:
      SELF_HOSTED: 1
      AWS_REGION: eu-west-1   # ab 3.50 nötig, sonst Neustartschleife
      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:v3.50.0
    container_name: bbworker
    environment:
      SELF_HOSTED: 1
      AWS_REGION: eu-west-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: budibase/minio:final
    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:
      - "127.0.0.1:${MAIN_PORT}:10000"
    container_name: bbproxy
    image: budibase/proxy:v3.50.0
    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:7
    command: redis-server --requirepass "${REDIS_PASSWORD}"
    volumes:
      - redis_data:/data

  litellm-service:
    restart: unless-stopped
    image: litellm/litellm:main-v1.83.10-stable.patch.3
    ports:
      - "127.0.0.1:${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", "python -c \"import urllib.request; urllib.request.urlopen('http://localhost:4000/health/liveliness')\""]
      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 offizielle Datei zieht budibase/apps, worker und proxy ohne Tag, also latest. Hier sind alle drei auf v3.50.0 festgelegt, damit ein Neustart keine ungeplante Aktualisierung auslöst. Seit 3.49 verweist die offizielle Datei für MinIO auf das eigene Image budibase/minio:final auf Docker Hub. Das früher eingetragene quay.io/minio/minio:RELEASE.2025-09-07T16-13-09Z ließ sich im Test nicht mehr ohne Anmeldung laden (401 UNAUTHORIZED).

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 liegt im selben Verzeichnis wie docker-compose.yaml; fehlt sie, bleiben alle ${VARIABLE}-Referenzen leer. Erzeugen Sie für jedes Secret einen eigenen Zufallswert:

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

Erstellen Sie /opt/budibase/.env und ersetzen Sie alle Platzhalter HIER_AENDERN durch die erzeugten 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=

Diese Werte dürfen nach dem ersten Start nicht mehr wechseln:

Verifizieren:

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

Die Ausgabe muss 0 sein. Sichern Sie die .env zusätzlich außerhalb des Servers.

Schritt 4: litellm_config.yaml anlegen

Der litellm-service bindet ./litellm_config.yaml ein. Fehlt die Datei, legt Docker an ihrer Stelle ein Verzeichnis an und LiteLLM startet nicht. Eine leere Datei reicht ebenfalls nicht: Im Test mit LiteLLM main-v1.83.10-stable.patch.3 lief der Dienst damit in eine Neustartschleife mit Exception: Config cannot be None or Empty. Übernehmen Sie deshalb die Vorlage aus dem Budibase-Repository (hosting/litellm_config.yaml):

curl -fsSL -o /opt/budibase/litellm_config.yaml \
  https://raw.githubusercontent.com/Budibase/budibase/v3.50.0/hosting/litellm_config.yaml

Die Datei enthält nur allgemeine Einstellungen, keine Zugangsdaten:

general_settings:
  store_model_in_db: true
  store_prompts_in_spend_logs: true

litellm_settings:
  drop_params: true
  extra_spend_tag_headers:
    - "x-litellm-tags"
  disable_add_user_agent_to_request_tags: true
  num_retries: 3
  retry_after: 5
  retry_policy:
    RateLimitErrorRetries: 4

Einen LLM-Anbieter (z. B. OpenAI oder ein lokales Ollama) tragen Sie später dort ein und starten danach docker compose restart litellm-service.

Verifizieren: ls -la /opt/budibase/ zeigt die drei Dateien docker-compose.yaml, .env und litellm_config.yaml (keine davon als Verzeichnis).

Schritt 5: Stack starten

Starten Sie alle acht Dienste im Hintergrund:

cd /opt/budibase
docker compose up -d

Beim ersten Start lädt Docker etwa 3 bis 4 GB an Images. Beendet sich ein Dienst dabei, hilft der Eintrag unter „Typische Fehler“.

Verifizieren:

docker compose ps

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

NAME          IMAGE                                          STATUS
bbapps        budibase/apps:v3.50.0                          Up
bbworker      budibase/worker:v3.50.0                        Up
bbproxy       budibase/proxy:v3.50.0                         Up
...           budibase/database:2.1.0                        Up
...           budibase/minio:final                           Up (healthy)
...           redis:7                                        Up
...           litellm/litellm:main-v1.83.10-stable.patch.3   Up (healthy)
...           postgres:16                                    Up (healthy)

Prüfen Sie außerdem, ob der Proxy antwortet und die Ports nur lokal lauschen:

curl -I http://127.0.0.1:10000
sudo ss -ltnp | grep -E ':(10000|4000)\b'

Erwartetes Ergebnis: HTTP/1.1 200 OK oder 302 Found; ss zeigt nur 127.0.0.1:10000 und 127.0.0.1:4000.

Schritt 6: Erst-Einrichtung im Browser

Öffnen Sie von Ihrem Arbeitsplatz einen SSH-Tunnel (ssh -L 10000:127.0.0.1:10000 benutzer@server) und rufen Sie http://localhost:10000 auf. Haben Sie BB_ADMIN_USER_EMAIL und BB_ADMIN_USER_PASSWORD gesetzt, ist das Admin-Konto bereits angelegt; sonst führt ein Setup-Assistent durch die Anlage.

Verifizieren: Die Oberfläche lädt ohne Fehler in der Browser-Konsole (F12), der Login mit dem Admin-Konto funktioniert und das leere App-Dashboard erscheint.

Schritt 7: Reverse Proxy und HTTPS (empfohlen)

Für den Zugriff aus dem Netz setzen Sie einen Reverse Proxy auf demselben Host vor Port 10000, der HTTPS übernimmt und an http://127.0.0.1:10000 weiterleitet. Die Einrichtung beschreiben diese Anleitungen:

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

Hinweis zu LiteLLM: Die offizielle Datei veröffentlicht Port 4000 auf allen Schnittstellen. Diese Anleitung bindet ihn an 127.0.0.1;

Verifizieren: Budibase ist unter Ihrer Domain per HTTPS erreichbar. curl -I https://budibase.beispiel.de liefert HTTP/2 200 oder einen Redirect.

Schritt 8: Updates durchführen und Backup

Sichern Sie vor jedem Update die Volumes bei gestopptem Stack:

# 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

Für ein Update erhöhen Sie danach die Tags von budibase/apps, worker und proxy gemeinsam auf die neue Version (GitHub-Releases) und übernehmen Änderungen der offiziellen Compose-Datei:

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

Update-Benachrichtigungen und eine 3-2-1-Sicherung beschreiben die Anleitungen Docker-Container automatisch aktualisieren: Diun, WUD und Renovate und 3-2-1-Backup-Strategie praktisch umsetzen.

Beim Umstieg von 3.47 auf 3.49 ersetzen Sie zusätzlich das MinIO-Image durch budibase/minio:final und legen, falls noch leer, die litellm_config.yaml aus Schritt 4 an. Im Test lief ein Bestand mit 3.47.0, Admin-Konto und einem zweiten Benutzer nach dem Tausch der drei Tags mit docker compose up -d wieder an: Die Anmeldung funktionierte, beide Konten waren erhalten, ein falsches Passwort wurde abgelehnt, und LiteLLM blieb mit der Vorlage healthy. Neu in 3.48 und 3.49 sind unter anderem Genehmigungsabläufe mit Eskalation und App-Adressen unter /apps statt /builder/apps.

Von 3.49 auf 3.50: Die offizielle hosting/docker-compose.yaml und die litellm_config.yaml sind zwischen beiden Versionen unverändert. Neu ist aber die Variable AWS_REGION bei app-service und worker-service in der Compose-Datei aus Schritt 2. Im Test startete bbapps unter 3.50.0 ohne diese Variable etwa alle 20 Sekunden neu (neun Neustarts in drei Minuten), im Log stand jedes Mal Region is missing aus dem AWS-SDK. Mit AWS_REGION: eu-west-1 lief der Dienst ohne Neustart. Der Wert betrifft nur die interne Objektspeicher-Anbindung an MinIO, Ihre Daten liegen weiter lokal. Laut Release Notes enthält 3.50.0 vor allem Korrekturen, unter anderem verlangen Automationstests jetzt Builder-Rechte und App-Skripte funktionieren wieder für öffentliche Benutzer.

Im Test am 20.10.2026 lief ein Bestand mit 3.49.0, einer App und einem zweiten Benutzer nach dem Tausch der drei Tags und mit AWS_REGION wieder an: Die Anmeldung funktionierte, App und beide Konten waren erhalten, ein falsches Passwort und ein Aufruf der Benutzerliste ohne Anmeldung wurden mit 403 abgewiesen, und nach zwei Minuten meldete bbapps keinen Neustart. Eine Neuinstallation mit 3.49.0 und 3.50.0 zeigte außerdem: Die selbst gehostete Variante ohne Lizenz erlaubt eine App, ab der zweiten antwortet Budibase mit Usage limit exceeded: 'apps'.

Verifizieren: Nach dem Update zeigt docker compose ps alle Dienste als Up mit den neuen Tags, und tar tzf /backup/couchdb-$(date +%Y%m%d).tar.gz | head listet die gesicherten Dateien.

Troubleshooting / Typische Fehler

1. bbapps startet nach dem Update auf 3.50 ständig neu, Log zeigt Region is missing: Es fehlt AWS_REGION bei app-service und worker-service. Ergänzen Sie die Zeile wie in Schritt 2 und führen Sie docker compose up -d aus.
2. „bind: address already in use“ auf Port 10000: Ein anderer Dienst (z. B. Webmin) belegt den Port. Setzen Sie MAIN_PORT=10001 in der .env und führen Sie docker compose up -d aus.
3. litellm-service startet nicht, litellm_config.yaml ist ein Verzeichnis: Die Datei fehlte beim ersten Start. Entfernen Sie das leere Verzeichnis mit rmdir, laden Sie die Vorlage wie in Schritt 4 und führen Sie docker compose up -d aus.
4. litellm-service in Neustartschleife, Log zeigt Config cannot be None or Empty.: Die litellm_config.yaml ist leer. Legen Sie die Vorlage aus Schritt 4 an und starten Sie den Dienst mit docker compose restart litellm-service neu.
5. 401 UNAUTHORIZED beim Pull von quay.io/minio/minio: Ältere Compose-Dateien verweisen noch auf quay.io. Tragen Sie budibase/minio:final ein; das Volume minio_data bleibt unverändert.
6. app-service oder worker-service beenden sich beim ersten Start: depends_on wartet nicht auf die Bereitschaft von CouchDB und MinIO. Warten Sie 30 Sekunden und führen Sie docker compose up -d erneut aus; docker compose logs couchdb-service zeigt den Stand der Initialisierung.
7. Fehler 401 oder Verbindungsfehler zu CouchDB nach Änderung der .env: Die Volumes wurden mit den früheren Secrets angelegt. Stellen Sie die ursprünglichen Werte aus Ihrer Sicherung der .env wieder her und führen Sie docker compose up -d aus. Löschen Sie die Volumes nicht: Das entfernt alle Apps und Daten.
8. Port 10000 antwortet nicht (Connection refused): Prüfen Sie docker compose logs proxy-service; häufig fehlen Werte in der .env. Von anderen Rechnern ist der Port absichtlich nicht erreichbar.
9. LiteLLM-API von außen erreichbar: Sie haben die offizielle Datei mit "${LITELLM_PORT:-4000}:4000" übernommen. Ändern Sie den Eintrag auf 127.0.0.1: wie oben; UFW-Regeln greifen bei veröffentlichten Docker-Ports nicht zuverlässig.
10. Konfigurationsänderung hat keine Wirkung: docker compose restart übernimmt keine neuen Umgebungsvariablen. Verwenden Sie docker compose up -d.

Häufige Fragen

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

Ja. litellm-service ist in der offiziellen Compose-Datei Abhängigkeit von app-service und worker-service und muss auch ohne LLM-Anbieter laufen. Die litellm_config.yaml braucht dafür keinen Anbieter, darf aber nicht leer sein (Vorlage siehe Schritt 4).

Wie erstelle ich den ersten Admin-Account?

Mit BB_ADMIN_USER_EMAIL und BB_ADMIN_USER_PASSWORD legt Budibase das Konto beim ersten Start an. Sonst zeigt der erste Aufruf einen Setup-Assistenten.

Kann ich PostgreSQL, MySQL oder andere externe Datenbanken verwenden?

Ja. Externe Datenquellen (PostgreSQL, MySQL, MSSQL, MongoDB, REST-APIs, Google Sheets) richten Sie im App-Builder ein. CouchDB speichert nur Budibase-interne Daten.

Wie aktiviere ich den Offline-Modus?

Setzen Sie OFFLINE_MODE=1 in der .env und führen Sie docker compose up -d aus. Das ist für isolierte Netze ohne Internetzugang gedacht.

Wie kann ich anonyme Nutzungsdaten deaktivieren?

Ändern Sie im environment-Block des app-service die Zeile ENABLE_ANALYTICS: "true" auf "false" und führen Sie docker compose up -d aus. Ein Eintrag in der .env wirkt nicht, weil die Compose-Datei den Wert fest setzt.

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

budibase/budibase bündelt alle Dienste in einem Container und eignet sich für Tests. Der Compose-Stack trennt Dienste und Volumes und erleichtert Sicherung und Fehlersuche je Dienst.

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

Ja. budibase/apps, worker, proxy und database gibt es auf Docker Hub für amd64 und arm64. Auf einem Raspberry Pi planen Sie mindestens 4 GB RAM ein.

Fazit

Budibase eignet sich für kleine Teams, die interne Apps ohne eigene Entwicklungsabteilung betreiben. Entscheidend sind eigene Secrets vor dem ersten Start, feste Image-Versionen und eine Sicherung der Volumes vor jedem Update.

Verwandte Plattformen für Workflows und KI-Anwendungen: 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.