Dolibarr ist ein quelloffenes Warenwirtschafts-, CRM- und Rechnungssystem für kleine Unternehmen, Vereine und Freiberufler. Anders als große ERP-Suiten besteht es aus Modulen, die Sie einzeln einschalten: Kunden, Angebote, Aufträge, Rechnungen, Produkte, Bank. Diese Anleitung betreibt Dolibarr 24.0.1 mit MariaDB und einem eigenen Cron-Container per Docker Compose, einschließlich Sicherung, geprüfter Wiederherstellung und Update.

Voraussetzungen

Im Leerlauf belegten die drei Container zusammen etwa 380 MiB RAM (MariaDB 206, Dolibarr 136, Cron 39). Für kleine Teams reichen 2 Kerne und 4 GB RAM.

Hardware: 2 CPU-Kerne, 4 GB RAM, 10 GB freier Speicher (das Image belegt 1,36 GB, dazu Datenbank und Belege). Architektur x86-64 oder ARM64 (arm64v8), beide stellt das Projekt bereit.
Software: Docker Engine mit Compose-Plugin (Compose v2), Zugriff per SSH, ein freier Port 8080.
Für den Produktivbetrieb: eine Domain und ein Reverse Proxy mit TLS-Zertifikat.

Was Dolibarr kann und wo die Grenzen liegen

Das Projekt ist aktiv: Das GitHub-Repository Dolibarr/dolibarr zeigte am 11.10.2026 rund 7.700 Sterne und einen letzten Push vom 10.10.2026, es ist nicht archiviert. Die aktuelle Version 24.0.1 erschien am 07.09.2026. Das Image dolibarr/dolibarr hat über 1,1 Millionen Pulls. Lizenz ist die GPL v3. Einzelne Zusatzmodule im Marktplatz des Projekts können kostenpflichtig sein.

Dolibarr ist ein modulares ERP für Kleinbetriebe. Wer tiefe Fertigungs- und Lagerlogik braucht, schaut besser auf ERPNext oder Odoo. Wer nur Rechnungen schreiben will, ist mit Invoice Ninja schlanker bedient. Fragen zu GoBD, E-Rechnung und DATEV-Export klären Sie vor dem Produktivbetrieb mit Ihrer Steuerberatung, diese Anleitung behandelt den Betrieb.

Eckdaten	Wert
Anwendung	`dolibarr/dolibarr:24.0.1` (PHP 8.2, Apache 2.4)
Datenbank	`mariadb:11.8`
Port	8080 auf dem Host, 80 im Container
Volumes	`db` (/var/lib/mysql), `documents` (/var/www/documents), `custom` (/var/www/html/custom)
Wichtige Variablen	DOLI_DB_, DOLI_ADMIN_, DOLI_URL_ROOT, DOLI_INSTANCE_UNIQUE_ID, DOLI_ENABLE_MODULES, DOLI_CRON_KEY

Schritt 1: Projektordner und .env anlegen

Alle Zugangsdaten stehen in einer .env. Erzeugen Sie fünf Zufallswerte und tragen Sie diese ein. Verwenden Sie nur Buchstaben und Ziffern.

mkdir -p /opt/dolibarr && cd /opt/dolibarr
for i in 1 2 3 4 5; do openssl rand -base64 36 | tr -dc A-Za-z0-9 | head -c 24; echo; done
nano .env && chmod 600 .env

MYSQL_ROOT_PASSWORD=HIER_ZUFALLSWERT_1
DOLI_DB_NAME=dolidb
DOLI_DB_USER=dolidbuser
DOLI_DB_PASSWORD=HIER_ZUFALLSWERT_2
DOLI_URL_ROOT=http://localhost:8080
DOLI_ADMIN_LOGIN=admin
DOLI_ADMIN_PASSWORD=HIER_ZUFALLSWERT_3
DOLI_COMPANY_NAME=Muster GmbH
DOLI_CRON_KEY=HIER_ZUFALLSWERT_4
DOLI_INSTANCE_UNIQUE_ID=HIER_ZUFALLSWERT_5
DOLI_ENABLE_MODULES=Societe,Product,Propale,Commande,Facture,Banque,Cron

DOLI_URL_ROOT ist die Adresse, unter der Anwender Dolibarr aufrufen (später Ihre https-Adresse). DOLI_ENABLE_MODULES schaltet beim ersten Start Module ein, DOLI_COMPANY_NAME und der Ländercode DE in der Compose-Datei setzen Firma und Land. Die Modulnamen müssen exakt den Klassennamen entsprechen, etwa Societe für Geschäftspartner.

Verifizieren: ls -l .env zeigt -rw-------, und grep -c HIER_ .env liefert 0, sobald alle Platzhalter ersetzt sind.

Schritt 2: compose.yaml erstellen

Die Datei folgt dem Beispiel with-cron aus dem Repository Dolibarr/dolibarr-docker. Abweichend davon sind Image und MariaDB auf feste Tags gesetzt, Zugangsdaten und Instanz-ID kommen aus der .env, Zeitzone und Upload-Grenzen sind angepasst.

x-dolibarr: &dolibarr
  image: dolibarr/dolibarr:24.0.1
  restart: unless-stopped
  volumes:
    - custom:/var/www/html/custom
    - documents:/var/www/documents

services:
  db:
    image: mariadb:11.8
    restart: unless-stopped
    command: >
      --character-set-server=utf8mb4
      --collation-server=utf8mb4_unicode_ci
    environment:
      MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
      MYSQL_DATABASE: ${DOLI_DB_NAME}
      MYSQL_USER: ${DOLI_DB_USER}
      MYSQL_PASSWORD: ${DOLI_DB_PASSWORD}
    volumes:
      - db:/var/lib/mysql
    healthcheck:
      test: ["CMD", "healthcheck.sh", "--connect", "--innodb_initialized"]
      start_period: 60s
      interval: 10s
      timeout: 5s
      retries: 5

  app:
    <<: *dolibarr
    depends_on:
      db:
        condition: service_healthy
    environment:
      WWW_USER_ID: 1000
      WWW_GROUP_ID: 1000
      DOLI_DB_HOST: db
      DOLI_DB_NAME: ${DOLI_DB_NAME}
      DOLI_DB_USER: ${DOLI_DB_USER}
      DOLI_DB_PASSWORD: ${DOLI_DB_PASSWORD}
      DOLI_URL_ROOT: ${DOLI_URL_ROOT}
      DOLI_ADMIN_LOGIN: ${DOLI_ADMIN_LOGIN}
      DOLI_ADMIN_PASSWORD: ${DOLI_ADMIN_PASSWORD}
      DOLI_INSTANCE_UNIQUE_ID: ${DOLI_INSTANCE_UNIQUE_ID}
      DOLI_COMPANY_NAME: ${DOLI_COMPANY_NAME}
      DOLI_COMPANY_COUNTRYCODE: DE
      DOLI_ENABLE_MODULES: ${DOLI_ENABLE_MODULES}
      DOLI_CRON: 0
      DOLI_CRON_KEY: ${DOLI_CRON_KEY}
      DOLI_CRON_USER: ${DOLI_ADMIN_LOGIN}
      PHP_INI_DATE_TIMEZONE: Europe/Berlin
      PHP_INI_UPLOAD_MAX_FILESIZE: 32M
      PHP_INI_POST_MAX_SIZE: 40M
    ports:
      - "8080:80"
    healthcheck:
      test: ["CMD", "curl", "-f", "http://127.0.0.1/"]
      start_period: 300s
      interval: 30s
      timeout: 10s
      retries: 3

  cron:
    <<: *dolibarr
    depends_on:
      app:
        condition: service_healthy
    environment:
      WWW_USER_ID: 1000
      WWW_GROUP_ID: 1000
      DOLI_DB_HOST: db
      DOLI_DB_NAME: ${DOLI_DB_NAME}
      DOLI_DB_USER: ${DOLI_DB_USER}
      DOLI_DB_PASSWORD: ${DOLI_DB_PASSWORD}
      DOLI_URL_ROOT: ${DOLI_URL_ROOT}
      DOLI_ADMIN_LOGIN: ${DOLI_ADMIN_LOGIN}
      DOLI_ADMIN_PASSWORD: ${DOLI_ADMIN_PASSWORD}
      DOLI_INSTANCE_UNIQUE_ID: ${DOLI_INSTANCE_UNIQUE_ID}
      DOLI_CRON: 1
      DOLI_CRON_USER: ${DOLI_ADMIN_LOGIN}
      DOLI_CRON_KEY: ${DOLI_CRON_KEY}

volumes:
  db:
  custom:
  documents:

Die Anwendung läuft als app, ein zweiter Container cron startet dasselbe Image mit DOLI_CRON: 1 und ruft alle fünf Minuten die geplanten Aufgaben auf. Der start_period von 300 Sekunden ist Absicht, mehr dazu im Troubleshooting. Schreiben Sie latest nicht in die Datei: Mit einem festen Tag entscheiden Sie selbst, wann eine neue Hauptversion samt Datenbankmigration kommt.

Verifizieren: docker compose config -q && echo ok gibt ok aus, wenn Syntax und Variablen stimmen.

Schritt 3: Stack starten und die Installation abwarten

Beim ersten Start legt der Container die Datenbank an. In diesem Test importierte er 410 Tabellen und brauchte dafür 4 Minuten und 19 Sekunden, bis Apache lief. Starten Sie im Hintergrund und lesen Sie das Protokoll mit.

docker compose up -d
docker compose logs -f app | grep -v Importing

Fertig ist die Installation, wenn im Protokoll apache2 -D FOREGROUND steht.

Verifizieren: docker compose ps zeigt app und db als healthy und cron als Up. curl -sI http://localhost:8080/ | head -1 liefert einen HTTP-Status 200 oder 302.

Schritt 4: Anmelden und Erstkonfiguration

Öffnen Sie die Adresse im Browser und melden Sie sich mit DOLI_ADMIN_LOGIN und dem Passwort aus der .env an. Die Admin-Zugangsdaten gelten nur für die Erstinstallation, spätere Änderungen erfolgen in der Benutzerverwaltung.

Anmeldeseite von Dolibarr 24.0.1 mit Feldern für Benutzername und Passwort — Anmeldung an Dolibarr 24.0.1.

Die wichtigste Einstellung steht unter Einstellungen, Unternehmen/Institution, ganz unten bei „Art der Umsatzsteuer“. Dolibarr startet mit „Umsatzsteuerbefreit“. Rechnungen entstehen dann mit 0 Prozent Steuer. In diesem Test stand eine Rechnung über 900 Euro netto zuerst mit 900 Euro brutto im System. Stellen Sie auf „Umsatzsteuerpflichtig“ um und tragen Sie Adresse, Postleitzahl und Steuernummer ein. Bei jedem Geschäftspartner muss zusätzlich das Kennzeichen „Umsatzsteuerpflichtig“ gesetzt sein, sonst rechnet Dolibarr für diesen Kunden ohne Steuer.

Dolibarr Firmeneinstellungen mit Abschnitt Art der Umsatzsteuer, Option Umsatzsteuerpflichtig ist gewählt — Umsatzsteuerpflichtig wählen, sonst entstehen Rechnungen ohne Steuer.

Unter Einstellungen, Module/Anwendungen mit dem Filter „Aktiviert“ sehen Sie, was DOLI_ENABLE_MODULES eingeschaltet hat.

Dolibarr Modulübersicht mit Filter Aktiviert: Benutzer, Geschäftspartner, Angebote und Kundenaufträge sind eingeschaltet — Aktivierte Module nach dem ersten Start.

Verifizieren: Die Modulliste zeigt die in der .env genannten Module als aktiv. Im Menü erscheinen Geschäftspartner, Produkte, Rechnung und Banken.

Schritt 5: Kunde, Produkt und erste Rechnung

Legen Sie unter Geschäftspartner, Neuer Geschäftspartner einen Kunden an. Dolibarr vergibt die Kundennummer automatisch (Format CU2610-00001). Danach legen Sie unter Produkte ein Produkt mit Nettopreis und Steuersatz 19 Prozent an. Eine Rechnung entsteht über Rechnung, Neue Rechnung, dann fügen Sie Zeilen hinzu und klicken auf „Freigeben“. Erst mit der Freigabe vergibt Dolibarr die endgültige Rechnungsnummer (IN2610-0001).

Dolibarr Geschäftspartner-Karte mit Kundennummer, Adresse und E-Mail-Adresse — Geschäftspartner mit automatischer Kundennummer.

Freigegebene Dolibarr-Kundenrechnung IN2610-0001 mit Nettobetrag 900 Euro, Umsatzsteuer 171 Euro und Bruttobetrag 1.071 Euro — Freigegebene Rechnung mit 19 Prozent Umsatzsteuer.

Verifizieren: Die Rechnung zeigt Status „nicht bezahlt“ und bei 900,00 Euro netto einen Bruttobetrag von 1.071,00 Euro.

Schritt 6: Geplante Aufgaben prüfen

Wiederkehrende Rechnungen und Erinnerungen laufen über Dolibarrs Cron. Der Container ruft das Skript cron_run_jobs.php mit Ihrem DOLI_CRON_KEY auf. Ob der Schlüssel in der Datenbank steht, hängt am Modul Cron: Ist es beim Erststart nicht aktiv, schreibt der Image-Start den Schlüssel ins Leere, und jeder Lauf scheitert. Deshalb steht Cron in DOLI_ENABLE_MODULES.

docker compose logs cron --since 10m | grep -E 'cron_run_jobs|securitykey'

Verifizieren: Alle fünf Minuten erscheint ein Block cron_run_jobs.php (24.0.1), der Jobs als „not qualified“ überspringt oder ausführt. Eine Zeile mit securitykey provided bedeutet einen falschen oder fehlenden Schlüssel.

Schritt 7: Sicher freigeben

Dolibarr enthält Rechnungen und Kundendaten und gehört nicht ungeschützt ins Internet. Lassen Sie einen Reverse Proxy das TLS-Zertifikat verwalten und binden Sie den Port in der compose.yaml auf 127.0.0.1:8080:80. Setzen Sie DOLI_URL_ROOT auf die https-Adresse und starten Sie app neu. Die conf.php entsteht bei jedem Containerstart neu aus den Variablen. Nutzen Sie starke Passwörter und getrennte Konten je Mitarbeiter.

Verifizieren: docker compose ps zeigt für app den Port 127.0.0.1:8080->80/tcp, von außen ist Port 8080 nicht mehr erreichbar.

Schritt 8: Backup und Wiederherstellung

Gesichert werden drei Dinge: die Datenbank, die Dokumente samt install.lock (PDF-Belege, Anhänge) mit installierten Modulen und die .env mit Instanz-ID und Cron-Schlüssel. Die conf.php brauchen Sie nicht zu sichern, sie entsteht aus der .env.

#!/bin/bash
# backup.sh: Datenbank, Dateien, Konfiguration
set -euo pipefail
cd /opt/dolibarr
STAMP=$(date +%F_%H%M)
mkdir -p backup
docker compose exec -T db sh -c 'mariadb-dump -uroot -p"$MYSQL_ROOT_PASSWORD" --single-transaction --routines --default-character-set=utf8mb4 "$MYSQL_DATABASE"' | gzip > "backup/db_$STAMP.sql.gz"
docker compose exec -T app tar czf - -C /var/www documents html/custom > "backup/files_$STAMP.tar.gz"
cp compose.yaml .env backup/
gzip -t "backup/db_$STAMP.sql.gz" && tar tzf "backup/files_$STAMP.tar.gz" | wc -l
echo "$STAMP" > backup/LATEST

#!/bin/bash
# restore.sh: Datenbank, Dateien, dann Anwendung
set -euo pipefail
cd /opt/dolibarr
STAMP=$(cat backup/LATEST)
docker compose up -d db
until [ "$(docker compose ps db --format '{{.Health}}')" = healthy ]; do sleep 3; done
gunzip -c "backup/db_$STAMP.sql.gz" | docker compose exec -T db sh -c 'mariadb -uroot -p"$MYSQL_ROOT_PASSWORD" "$MYSQL_DATABASE"'
docker compose run --rm -T --no-deps --entrypoint tar app xzf - -C /var/www < "backup/files_$STAMP.tar.gz"
docker compose up -d

Im Test entstand vor dem Backup ein Marker: der Kunde „Restore Marker AG“ in der Datenbank und die Datei restore-marker.txt im Dokumentenordner. Danach löschte docker compose down -v alle Volumes, und restore.sh stellte alles wieder her (77 Sekunden). Beide Marker waren zurück, 410 Tabellen vorhanden, die Anmeldung funktionierte. Die Datei install.lock aus der Sicherung sorgt dafür, dass der Container nicht neu installiert: Install.lock Exists is : yes.

Verifizieren: bash backup.sh endet ohne Fehler, zcat backup/db_*.sql.gz | grep -c 'CREATE TABLE' liefert 410, und ein Probe-Restore auf einem Testhost zeigt Ihre Daten. Kopieren Sie backup anschließend auf ein anderes System.

Schritt 9: Update und Rollback

Der Image-Start migriert die Datenbank automatisch, solange DOLI_INSTALL_AUTO auf 1 steht (Standard). Zuvor muss die Sperrdatei weg, laut Dokumentation ein Schutz gegen versehentliche Installationen. Erstellen Sie vorher ein Backup und tragen Sie das neue Tag in die compose.yaml ein.

bash backup.sh
docker compose exec -T app rm -f /var/www/documents/install.lock
docker compose pull
docker compose up -d
docker compose logs app | grep -E 'Database Version|Files Version'

Im Test lief dieser Ablauf mit identischer Version: Das Protokoll zeigte Install.lock Exists is : no, Database Version is : 24.0.1 und Files Version are : 24.0.1, danach lag die Sperrdatei wieder im Dokumentenordner. Ein Rollback auf ein älteres Image ist nach einer Migration nicht möglich, denn die Datenbank hat dann das neue Schema. Der einzige Weg zurück ist das Backup. Laut Wiki gibt es Migrationsskripte nur zwischen Hauptversionen, springen Sie deshalb nicht über mehrere Hauptversionen hinweg.

Verifizieren: Nach dem Update zeigt die Anmeldeseite die neue Version, und docker compose ps meldet healthy.

Troubleshooting

Symptom	Ursache	Lösung
`dependency failed to start: container ...-app-1 is unhealthy` beim ersten `up -d`	Die Installation dauert länger als der `start_period` (im Test erst mit 120 s zu kurz).	`start_period: 300s` setzen und `docker compose up -d` wiederholen.
Cron-Protokoll: `securitykey provided ... does not match securitykey in setup`	Modul Cron war beim Erststart nicht aktiv, der Schlüssel fehlt in der Datenbank.	Modul Cron aktivieren, Schlüssel unter dem Modul eintragen. Bei Neuinstallation `Cron` in `DOLI_ENABLE_MODULES` aufnehmen.
Rechnungen ohne Umsatzsteuer	Firma steht auf „Umsatzsteuerbefreit“ oder der Kunde ohne Kennzeichen „Umsatzsteuerpflichtig“.	Beides in den Einstellungen und der Kundenkarte korrigieren.
`Activating module Foobar ... FAILED. Unable to load module. Be sure to check the case`	Unbekannter Modulname in `DOLI_ENABLE_MODULES`.	Namen gegen die Dateien `mod*.class.php` prüfen, ohne „mod“ angeben.
Instanz-ID steht auf `myinstanceuniquekey`	`DOLI_INSTANCE_UNIQUE_ID` ist nicht gesetzt. Im Test schrieb der Start dann diesen festen, öffentlich bekannten Wert in die `conf.php`.	Zufallswert in die `.env` eintragen und Container neu erstellen.

Häufige Fragen

Kann ich PostgreSQL statt MariaDB nutzen?

Ja, über DOLI_DB_TYPE=pgsql. Laut README muss Dolibarr dann beim ersten Start manuell über /install installiert werden, auch Updates laufen über die Weboberfläche.

Warum zwei Container aus demselben Image?

Der Cron-Container führt nur geplante Aufgaben aus, sodass lange Jobs keine Webanfragen blockieren.

Wie erhöhe ich das Upload-Limit?

Über PHP_INI_UPLOAD_MAX_FILESIZE und PHP_INI_POST_MAX_SIZE. Im Test lieferte PHP danach 32M und 40M, das Speicherlimit blieb bei 256M.

Fazit

Dolibarr lässt sich mit dem offiziellen Image schnell und reproduzierbar betreiben. Die Stolpersteine liegen nicht im Container, sondern in den Voreinstellungen: Umsatzsteuer, Instanz-ID und Cron-Modul. Wer diese drei Punkte setzt und das Backup einmal real zurückspielt, hat ein belastbares Fundament.

Weiterführende Anleitungen und Quellen

ERPNext als größeres ERP im Vergleich
Invoice Ninja für reine Rechnungsstellung
Odoo für ERP und CRM im Mittelstand
Dolibarr auf GitHub und Release 24.0.1
Dolibarr-Docker-Repository mit README und Beispielen
Image dolibarr/dolibarr auf Docker Hub
Dolibarr-Wiki: Installation und Upgrade
Dolibarr-Wiki: Backups und Restores