ERPNext mit Docker auf einem VPS selbst betreiben

Was Sie sich mit dem Betrieb verpflichten

ERPNext auf einem VPS selbst zu betreiben, ist eine Betriebsaufgabe und keine Installation mit einem einzigen Befehl. Der offizielle Docker-Compose-Stack besteht aus elf Containern und enthält Ihr Hauptbuch sowie Ihre Kundendaten. Das setzt für alles Folgende einen höheren Maßstab: Eine Sicherung ist erst dann eine Sicherung, wenn Sie sie wiederhergestellt haben. Ein nicht fest angegebener Image-Tag ist eine bevorstehende Schema-Migration.

Im gesamten Text werden einige Bezeichnungen verwendet. ERPNext ist die Geschäftsanwendung. Frappe ist das zugrunde liegende Python-Framework. Bench ist das Kommandozeilenwerkzeug zur Verwaltung von Sites und bereits in den Containern installiert. Eine Site ist ein Mandant: eine MariaDB-Datenbank zusammen mit einem Verzeichnis für hochgeladene Dateien. Fast jeder Befehl in diesem Text wird bench im Container backend für eine Site mit einem bestimmten Namen ausgeführt.

Diese Anleitung verwendet das Repository frappe_docker, das vom Projekt für diesen Einsatz gepflegt wird. Jeder folgende Befehl wurde im August 2026 gegen dieses Repository geprüft. Wenn Docker Compose für Sie neu ist, behandelt Docker Compose auf einem VPS ausführen die Grundlagen, die diese Anleitung voraussetzt.

Wie viel VPS benötigt ERPNext?

[
  {
    "label": "Evaluation",
    "vcpu": 2,
    "ram_gb": 4,
    "disk_gb": 40
  },
  {
    "label": "Small production",
    "vcpu": 4,
    "ram_gb": 8,
    "disk_gb": 100
  },
  {
    "label": "Room to grow",
    "vcpu": 4,
    "ram_gb": 16,
    "disk_gb": 160
  }
]

Die veröffentlichten Empfehlungen beginnen bei 2 vCPU und 4 GB RAM, bevor sich auch nur ein Benutzer anmeldet. Das ist die Evaluierungsstufe. Diese Werte sind Ausgangspunkte und keine Messwerte aus diesem Leitfaden. Die tatsächliche Größe hängt vom Umfang Ihrer Dokumente ab. Die letzte Zeile ist überhaupt kein veröffentlichtes Minimum. Sie beschreibt ungefähr den Bereich, in dem der Arbeitsspeicher nicht mehr ständig berücksichtigt werden muss.

Seien Sie bei kleinen Tarifen realistisch. Ein VPS mit 1 GB oder 2 GB RAM startet den Stack, fällt aber beim ersten Import oder beim ersten umfangreichen Bericht aus. Neun lang laufende Container, der Buffer Pool von MariaDB und ein Python-Worker, der einen Bericht erstellt, passen nicht in diesen Arbeitsspeicher. Der Ausfall erfolgt nicht kontrolliert. Der OOM-Killer des Kernels beendet einen Container. docker inspect darauf zeigt dann "OOMKilled": true mit Exit-Code 137. Wenn ein Worker während eines Jobs beendet wird, bleibt ein übermitteltes Dokument mit unvollständig ausgeführter Hintergrundverarbeitung zurück.

Für ein Unternehmen, das ERPNext täglich nutzt, sind 8 GB RAM, 4 vCPU und 100 GB SSD der realistische Mindestumfang. Der Arbeitsspeicher ist zuerst erschöpft. Der belegte Speicherplatz wächst schneller als erwartet, weil jeder Anhang und jedes lokale Backup auf demselben Volume wie die Datenbank gespeichert wird.

Die elf Container und ihre jeweiligen Aufgaben

Führen Sie docker compose ps aus, sobald der Stack gestartet ist und neun Container laufen. Zwei weitere Container, configurator und create-site, führen ihre Aufgabe einmalig aus und werden anschließend beendet. Daher ergibt sich die Gesamtzahl von elf Containern.

• backend führt die Frappe-Anwendung unter gunicorn aus. Dort läuft bench.
• frontend ist nginx. Der Container stellt statische Ressourcen bereit und leitet alle übrigen Anfragen an das Backend weiter.
• queue-short und queue-long sind RQ (Redis Queue)-Worker. Sie führen Hintergrundaufgaben wie den Versand von E-Mails, Importe und die Erstellung von Berichten aus.
• scheduler führt zeitgesteuerte Aufgaben aus, darunter geplante Berichte und automatisch wiederholte Dokumente.
• websocket ist der socket.io-Prozess hinter den Live-Aktualisierungen im Browser.
• db ist MariaDB.
• redis-cache und redis-queue sind zwei getrennte Redis-Instanzen: eine für den Cache und eine für die Job-Warteschlange.

Diese Aufteilung sollten Sie verstehen, weil sie zeigt, welches Log Sie prüfen müssen. Eine festhängende E-Mail ist ein Problem des Queue-Workers. Daher ist docker compose logs -f queue-short der richtige Befehl. Eine Seite, die geladen wird, aber das Benachrichtigungs-Badge nie aktualisiert, weist auf ein Websocket-Problem hin. Wenn Sie für eines dieser Probleme die Logs von backend lesen, verlieren Sie damit einen Nachmittag.

Installation mit den Produktions-Compose-Dateien, nicht mit der Demo

Das Repository enthält pwd.yml, und die README formuliert es eindeutig: „Dieses Setup ist nur für eine kurzfristige Evaluierung vorgesehen. Sie können in diesem Setup keine benutzerdefinierten Apps installieren.“ Verwenden Sie es, um ERPNext einen Nachmittag lang zu testen. Betreiben Sie damit kein Unternehmen.

sudo apt update && sudo apt install -y git
curl -fsSL https://get.docker.com | bash
git clone https://github.com/frappe/frappe_docker
cd frappe_docker
mkdir -p ~/gitops
cp example.env ~/gitops/erpnext.env

Öffnen Sie ~/gitops/erpnext.env und ändern Sie vier Werte. ERPNEXT_VERSION legt den Image-Tag fest. DB_PASSWORD wird in der Beispieldatei als 123 bereitgestellt. SITES_RULE ist die Traefik-Routing-Regel, und LETSENCRYPT_EMAIL empfängt Zertifikatswarnungen.

ERPNEXT_VERSION=v16.32.1
DB_PASSWORD=<a long random password>
SITES_RULE=Host(`erp.example.com`)
LETSENCRYPT_EMAIL=ops@example.com

Erzeugen Sie jetzt eine Compose-Datei und starten Sie sie anschließend.

docker compose --project-name erpnext \
  --env-file ~/gitops/erpnext.env \
  -f compose.yaml \
  -f overrides/compose.mariadb.yaml \
  -f overrides/compose.redis.yaml \
  -f overrides/compose.https.yaml \
  config > ~/gitops/erpnext.yaml

docker compose --project-name erpnext -f ~/gitops/erpnext.yaml up -d

config startet nichts. Der Befehl führt die Basisdatei mit den Überschreibungen zusammen und gibt das Ergebnis aus, wobei bereits alle Variablen ersetzt sind. Anschließend führen Sie diese erzeugte Datei aus. Dieser zusätzliche Schritt ist sinnvoll: Der laufende Stack steht in einer einzigen Datei, die Sie lesen und in das Repository übernehmen können. Dadurch kann sich die Konfiguration nicht unbemerkt ändern, wenn jemand die env-Datei bearbeitet oder Sie das Repository aktualisieren. wie mehrere Docker-Compose-Dateien zusammengeführt werden erläutert die Regeln für Überschreibungen im Detail.

Warten Sie, bis db gestartet und configurator beendet wurde. Das dauert einige Sekunden. Erstellen Sie anschließend die Site.

docker compose --project-name erpnext exec backend \
  bench new-site --mariadb-user-host-login-scope=% \
  --db-root-password '<your DB_PASSWORD>' \
  --install-app erpnext \
  --admin-password '<a strong admin password>' \
  erp.example.com

Prüfen Sie das Ergebnis:

docker compose --project-name erpnext ps
docker compose --project-name erpnext exec backend bench --site erp.example.com list-apps

list-apps sollte frappe und erpnext mit den jeweiligen Versionen ausgeben. Ein gesunder ps zeigt neun Services im Zustand running und keinen im Zustand restarting.

Hier treten häufig zwei Probleme auf. --mariadb-user-host-login-scope=% ist unter Docker nicht optional. Der App-Container erreicht MariaDB über das Docker-Netzwerk und verbindet sich daher von einem entfernten Host. Ein Datenbankbenutzer, der auf localhost beschränkt ist, kann sich von dort nicht anmelden. Die Erstellung der Site schlägt dann mit einem MariaDB-Fehler wegen verweigerter Zugriffsberechtigung fehl, der den Benutzer root nennt. Der Bereich % gewährt dem Benutzer der neuen Site Zugriff von jedem Host in diesem privaten Netzwerk.

Das zweite Problem ist der Site-Name. Das Frontend wählt standardmäßig anhand des HTTP-Headers Host aus, welche Site ausgeliefert wird. Eine als erpnext erstellte Site ist daher unter erp.example.com nicht erreichbar, obwohl beide vorhanden sind. Benennen Sie die Site wie oben nach der Domain oder setzen Sie FRAPPE_SITE_NAME_HEADER in der env-Datei auf den Site-Namen und erzeugen Sie die Compose-Datei erneut.

HTTPS und was vor dem Betrieb erfüllt sein muss

Der Override compose.https.yaml führt Traefik auf Port 443 aus, leitet Port 80 dorthin um und fordert Zertifikate bei Let's Encrypt an. TLS (Transport Layer Security) sorgt dafür, dass eine Rechnung und ein Session-Cookie nicht im Klartext über das Netzwerk übertragen werden.

Zwei Voraussetzungen müssen erfüllt sein, sonst wird kein Zertifikat ausgestellt. Der DNS-A-Record für erp.example.com muss bereits auf den VPS zeigen. Die Ports 80 und 443 müssen aus dem Internet erreichbar sein, weil Let's Encrypt mit einer HTTP-01-Challenge auf Port 80 nachweist, dass Sie den Namen kontrollieren. Prüfen Sie die Netzwerk-Firewall Ihres Providers ebenso wie die Firewall auf dem Server. Das sind getrennte Kontrollen. Die Firewall im Provider-Panel wird häufig übersehen.

Die Zertifikate werden im Volume cert-data unter /letsencrypt/acme.json gespeichert. Wenn der Browser statt Ihres Zertifikats ein Standardzertifikat anzeigt, ermitteln Sie den Namen des Proxy-Dienstes in docker compose --project-name erpnext ps und lesen Sie dessen Logs auf den ACME-Fehler (Automatic Certificate Management Environment) hin. Betreiben Sie weitere Webanwendungen auf demselben Server? Eine Traefik-Instanz vor mehreren Docker-Compose-Anwendungen zeigt, wie Sie den Proxy gemeinsam nutzen, statt um Port 443 zu konkurrieren.

Ausgehende E-Mails, sonst verlassen die Rechnungen den Server nie

Dies ist der Schritt, den die meisten ERPNext-Anleitungen überspringen. Er entscheidet darüber, ob das System tatsächlich nutzbar ist. Ohne funktionierende ausgehende E-Mails erreicht keine Rechnung einen Kunden, keine E-Mail zum Zurücksetzen eines Passworts kommt an und kein geplanter Bericht wird zugestellt. Der Stack enthält keinen Mailserver.

Versuchen Sie nicht, E-Mails direkt vom VPS über Port 25 zu senden. Die meisten Anbieter blockieren ausgehenden Port 25 bei neuen Konten. E-Mails, die trotzdem versendet werden, werden abgelehnt oder als Spam abgelegt, weil die Adresse eines neuen VPS noch keine Reputation als Absender hat. Verwenden Sie ein authentifiziertes Relay über Port 587.

Der unterstützte Weg führt über den Bildschirm Email Account in der ERPNext-Oberfläche. Dort wird das Passwort verschlüsselt gespeichert. Sie können die Schlüssel auch in die Site-Konfiguration schreiben:

docker compose --project-name erpnext exec backend \
  bench --site erp.example.com set-config mail_server smtp.example.com

docker compose --project-name erpnext exec backend \
  bench --site erp.example.com set-config mail_port 587 --parse

docker compose --project-name erpnext exec backend \
  bench --site erp.example.com set-config use_tls 1 --parse

docker compose --project-name erpnext exec backend \
  bench --site erp.example.com set-config mail_login 'erp@example.com'

docker compose --project-name erpnext exec backend \
  bench --site erp.example.com set-config auto_email_id 'erp@example.com'

--parse speichert 587 als Zahl statt als Zeichenfolge "587". Lesen Sie die Datei erneut ein und bestätigen Sie, dass diese beiden Werte nicht in Anführungszeichen stehen:

docker compose --project-name erpnext exec backend \
  cat sites/erp.example.com/site_config.json

Legen Sie mail_password über den Bildschirm Email Account fest und nicht über die Befehlszeile. Dadurch wird der Wert verschlüsselt gespeichert und gelangt nicht in den Verlauf Ihrer Shell.

Senden Sie anschließend eine echte Nachricht. Erstellen Sie eine Sales Invoice, senden Sie sie per E-Mail an eine Adresse, auf die Sie Zugriff haben, und überwachen Sie dabei die Warteschlange:

docker compose --project-name erpnext logs -f queue-short

Ausgehende E-Mails werden als Hintergrundauftrag verarbeitet. Eine Nachricht, die nie ankommt, erscheint daher normalerweise als fehlgeschlagener Auftrag in diesem Log und nicht als Fehler im Browser. Veröffentlichen Sie außerdem SPF- (Sender Policy Framework) und DKIM- (DomainKeys Identified Mail) Einträge für die Absenderdomain. Ergänzen Sie anschließend eine DMARC-Richtlinie. Ohne diese Einträge landet auch eine technisch korrekte Rechnung weiterhin im Spam-Ordner des Kunden. Wenn Sie den gesamten Versandweg selbst betreiben möchten, bietet Ihnen ein selbst gehosteter Mailcow-Mailserver ein Relay, das Sie kontrollieren und auf einem separaten Server vom ERP betreiben können.

Backups, die sich tatsächlich wiederherstellen lassen

Ein Datenbank-Dump allein ist kein Backup von ERPNext. Anhänge und private Dateien liegen im Sites-Verzeichnis, nicht in MariaDB. Wenn Sie nur die Datenbank wiederherstellen, ist jeder hochgeladene Bestellbeleg nur noch ein defekter Link.

docker compose --project-name erpnext exec backend \
  bench --site erp.example.com backup --with-files

Damit werden vier Dateien in sites/erp.example.com/private/backups innerhalb des Volumes sites geschrieben:

• ein -database.sql.gz-Dump
• ein -files.tar-Archiv der öffentlichen Dateien
• ein -private-files.tar-Archiv der privaten Dateien
• eine -site_config_backup.json-Kopie der Site-Konfiguration

Die vierte Datei wird häufig verworfen. Genau das verursacht später Probleme. Sie enthält encryption_key, den Schlüssel, den Frappe zur Verschlüsselung gespeicherter Passwörter verwendet: Zugangsdaten für E-Mail-Konten, Schlüssel für Payment-Gateways und alle Secrets von Integrationen. Wenn Sie eine Datenbank ohne den passenden Schlüssel wiederherstellen, wird die Site normal geladen. Der E-Mail-Versand schlägt jedoch mit folgender Fehlermeldung fehl:

frappe.exceptions.ValidationError: Encryption key is invalid! Please check site_config.json

Bewahren Sie immer alle vier Dateien zusammen auf.

Anschließend müssen Sie sie vom Server übertragen. Ein Backup innerhalb des Volumes übersteht den Ausfall des Servers nicht. Außerdem löscht bench standardmäßig Backups, die in diesem Verzeichnis älter als 24 Stunden sind.

docker compose --project-name erpnext cp \
  backend:/home/frappe/frappe-bench/sites/erp.example.com/private/backups \
  ~/erpnext-backups

Führen Sie diesen Befehl über cron aus. Übertragen Sie das Verzeichnis anschließend an einen Speicherort, den Sie nicht selbst administrieren. Verschlüsselte restic-Backups in einen externen Speicher sind dafür das richtige Werkzeug, weil restic die Daten vor dem Upload verschlüsselt und restic check bestätigt, dass das Repository weiterhin lesbar ist. Ein ERP-Backup ist eine Kopie Ihres gesamten Hauptbuchs. Es muss daher verschlüsselt auf einem Speichermedium liegen, das sich nicht auf diesem Server befindet.

Stellen Sie die Wiederherstellung vor dem Ernstfall auf die Probe

Ein nicht getestetes Backup ist eine Vermutung. Testen Sie es auf demselben Server in einer zweiten Site, niemals in der Live-Site.

docker compose --project-name erpnext exec backend \
  bench new-site --mariadb-user-host-login-scope=% \
  --db-root-password '<your DB_PASSWORD>' \
  --admin-password '<a strong admin password>' \
  restore-test.example.com

docker compose --project-name erpnext exec backend \
  bench --site restore-test.example.com --force restore \
  sites/erp.example.com/private/backups/<stamp>-erp.example.com-database.sql.gz \
  --with-public-files sites/erp.example.com/private/backups/<stamp>-erp.example.com-files.tar \
  --with-private-files sites/erp.example.com/private/backups/<stamp>-erp.example.com-private-files.tar \
  --db-root-password '<your DB_PASSWORD>'

Kopieren Sie den Verschlüsselungsschlüssel aus der gesicherten Konfiguration in die wiederhergestellte Site. Andernfalls funktionieren deren Integrationen weiterhin nicht:

docker compose --project-name erpnext exec backend \
  bench --site restore-test.example.com set-config encryption_key '<value from site_config_backup.json>'

Prüfen Sie die Wiederherstellung nun so, wie es ein Buchhalter tun würde. Öffnen Sie den Bericht zu den Forderungen und vergleichen Sie den Endsaldo mit der Live-Site. Öffnen Sie eine kürzlich erstellte Eingangsrechnung und laden Sie deren Anhang herunter. Eine Site, die ihre Anmeldeseite anzeigt, beweist überhaupt nichts.

Entfernen Sie die Test-Site, sobald Sie fertig sind:

docker compose --project-name erpnext exec backend \
  bench drop-site restore-test.example.com

Warum das Festsetzen der Version bei ERPNext wichtiger ist

Bei einer statischen Website bedeutet ein nicht festgelegter Image-Tag einen unerwarteten Neustart. Bei ERPNext bedeutet er eine Schema-Migration. bench migrate schreibt Datenbanktabellen neu und kann Dokumentdaten ändern. Dies kann nicht rückgängig gemacht werden. Ein Rollback erfolgt durch eine Wiederherstellung aus dem Backup, nicht durch einen docker compose down.

Legen Sie den Tag daher fest. ERPNEXT_VERSION=v16.32.1 war die im Repository-eigenen pwd.yml im August 2026 festgelegte Version. Übernehmen Sie diese Nummer nicht ungeprüft. Die aktuellen Releases sind auf der Releases-Seite von frappe/erpnext aufgeführt. Die vorhandenen Image-Tags finden Sie auf Docker Hub. Lesen Sie die Hinweise zur Version, auf die Sie aktualisieren möchten, bevor Sie das Update durchführen.

Das Upgrade selbst beginnt mit einem Backup und dem Wartungsmodus.

docker compose --project-name erpnext exec backend \
  bench --site erp.example.com backup --with-files

docker compose --project-name erpnext exec backend \
  bench --site erp.example.com set-maintenance-mode on

Bearbeiten Sie ERPNEXT_VERSION in ~/gitops/erpnext.env. Rendern Sie anschließend die Konfiguration, laden Sie das Image herunter und führen Sie die Migration aus.

docker compose --project-name erpnext \
  --env-file ~/gitops/erpnext.env \
  -f compose.yaml \
  -f overrides/compose.mariadb.yaml \
  -f overrides/compose.redis.yaml \
  -f overrides/compose.https.yaml \
  config > ~/gitops/erpnext.yaml

docker compose --project-name erpnext -f ~/gitops/erpnext.yaml pull
docker compose --project-name erpnext -f ~/gitops/erpnext.yaml up -d

docker compose --project-name erpnext exec backend \
  bench --site erp.example.com migrate

docker compose --project-name erpnext exec backend \
  bench --site erp.example.com set-maintenance-mode off

Der Wartungsmodus ist wichtig, weil migrate während der Ausführung das Schema ändert. Wenn ein Benutzer ein Dokument gegen eine teilweise migrierte Tabelle übermittelt, müssen Sie Datensätze möglicherweise manuell reparieren.

Aktualisieren Sie jeweils nur um eine Hauptversion und erstellen Sie zwischen den einzelnen Schritten ein Backup. Der Migrationscode eines Releases ist für das Upgrade vom vorherigen Release ausgelegt. Beim Überspringen von Hauptversionen werden Migrationen in einer Kombination ausgeführt, die niemand getestet hat.

Das Repository liefert außerdem overrides/compose.migrator.yaml aus. Dieser Container führt bei jedem Start bench --site all migrate aus. Das ist praktisch. Es bedeutet aber auch, dass ein docker compose up mit einem geänderten Tag Ihre Produktionsdatenbank migriert, ohne dass jemand den Vorgang überwacht. Führen Sie migrate bei einem Geschäftssystem nur aus, wenn Sie diese Entscheidung an diesem Morgen bewusst getroffen haben.

Eine Umgebung mit Kundendaten absichern

Ändern Sie das Administratorpasswort bei der ersten Anmeldung. Die Compose-Datei für die Evaluierung verwendet admin als Passwort. Diese Gewohnheit wird sonst in die Produktion übernommen.

Ändern Sie DB_PASSWORD und ersetzen Sie den 123 in example.env. Dieser Wert steht im gerenderten ~/gitops/erpnext.yaml im Klartext. Sichern Sie chmod 600 und halten Sie die Datei aus jedem Git-Repository heraus. Für eine stärkere Lösung liest overrides/compose.mariadb-secrets.yaml das Passwort aus einer Docker-Secret-Datei statt aus einer Umgebungsvariablen. Umgebungsdateien und Secrets in Docker Compose verwalten erläutert die jeweiligen Vor- und Nachteile.

Veröffentlichen Sie nur die benötigten Ports. Mit dem HTTPS-Override sind nur die Ports 80 und 443 erreichbar. Fügen Sie dem db-Service kein ports-Mapping hinzu, nur damit sich ein Datenbankclient leichter verbinden kann. Dadurch wäre MariaDB aus dem öffentlichen Internet erreichbar. Verwenden Sie stattdessen docker compose --project-name erpnext exec backend bench mariadb. Erlauben Sie auf dem Host die Ports 22, 80 und 443, sperren Sie alle übrigen Ports und prüfen Sie zusätzlich die separate Netzwerk-Firewall des Providers.

Aktivieren Sie in den Systemeinstellungen für jedes Konto mit der Rolle System Manager die Zwei-Faktor-Authentifizierung. Diese Rolle kann jedes Dokument lesen und jede Tabelle exportieren. Behandeln Sie sie daher wie ein Administratorkonto und nicht wie eine Komfortfunktion. Wenn Sie mehrere selbst gehostete Anwendungen betreiben, ist Authentik als selbst gehosteter Single-Sign-On-Provider besser als ein weiteres Passwort pro Anwendung.

Installieren Sie Patches auf dem Host und führen Sie bei Kernel-Updates einen Reboot durch. Prüfen Sie vor dem produktiven Einsatz, ob der Stack wieder startet. Kontrollieren Sie dazu in der gerenderten Datei, ob für jeden Service eine restart-Richtlinie gesetzt ist. Ohne diese Richtlinie bleibt ein Stack nach dem Reboot heruntergefahren. einen Docker-Compose-Stack nach einem Reboot wieder starten erläutert die systemd-Konfiguration.

Wenn ERPNext auf einem einzelnen VPS nicht mehr ausreicht

Ein VPS kann ein kleines Unternehmen lange Zeit tragen. Folgende Anzeichen zeigen, dass das nicht mehr der Fall ist:

• Hintergrundaufträge stauen sich. E-Mails und Importe treffen daher Minuten oder Stunden verspätet ein.
• docker inspect meldet Container mit "OOMKilled": true oder dem Exit-Code 137.
• Berichte, deren Erstellung zwei Sekunden dauerte, benötigen nun dreißig Sekunden. MariaDB belegt dabei die CPU.
• Backups laufen so lange, dass sich ein Lauf mit dem nächsten geplanten Lauf überschneidet.

Geben Sie MariaDB zunächst Ressourcen, die es nicht mit anderen Diensten teilen muss. Die Datenbank und die Python-Worker konkurrieren um denselben Arbeitsspeicher. Der Buffer Pool benötigt dabei typischerweise mehr Speicher. Ein größerer Anwendungsserver bringt weniger als erwartet. Die Datenbank in Docker oder auf dem Host betreiben behandelt diese Entscheidung. Speicherlimits in Docker Compose festlegen verhindert, dass ein Container die anderen aushungert, während Sie die Konfiguration anpassen.

Fügen Sie anschließend Queue-Worker hinzu, statt die Webkapazität zu erhöhen. Die langsamen Aufgaben in ERPNext laufen im Hintergrund: die Berichtserstellung und umfangreiche Importe. Zusätzliche Worker-Container kosten weniger als ein größerer Server. Außerdem beheben sie genau das Problem, über das sich Benutzer beschweren.

FAQ

Wie viel RAM benötigt ERPNext auf einem VPS?

Die veröffentlichten Empfehlungen beginnen bei 4 GB mit 2 vCPU. Diese Größenordnung ist jedoch nur für Evaluierungen vorgesehen. Für ein Unternehmen, das ERPNext täglich nutzt, sollten Sie 8 GB RAM, 4 vCPU und 100 GB SSD-Speicher einplanen. Bei weniger RAM beendet der Out-of-Memory-Killer des Kernels unter Last Container. docker inspect meldet dies als "OOMKilled": true mit dem Exit-Code 137. Diese Werte sind Ausgangspunkte und keine Messwerte. Überwachen Sie daher im ersten Monat die tatsächliche Speichernutzung.

Kann ich pwd.yml in der Produktion ausführen?

Nein. Die README des Projekts beschreibt die Datei ausschließlich für kurzzeitige Evaluierungen. Außerdem weist sie darauf hin, dass darin keine benutzerdefinierten Apps installiert werden können. Verwenden Sie compose.yaml mit den Overrides für MariaDB, Redis und HTTPS, führen Sie sie mit docker compose config zu einer einzelnen Datei zusammen und führen Sie diese Datei aus.

Warum ist meine ERPNext-Site direkt nach ihrer Erstellung nicht erreichbar?

Das Frontend wählt standardmäßig anhand des HTTP-Host-Headers aus, welche Site bereitgestellt wird. Der Site-Name muss daher mit der Domain im Browser übereinstimmen. Eine als erpnext erstellte Site wird nicht unter erp.example.com bereitgestellt. Erstellen Sie die Site entweder mit der Domain als Namen oder setzen Sie FRAPPE_SITE_NAME_HEADER in der env-Datei auf den Site-Namen. Rendern Sie die Compose-Datei anschließend erneut und starten Sie den Stack neu.

Was muss in einem ERPNext-Backup enthalten sein?

Vier Dateien müssen zusammen aufbewahrt werden: der -database.sql.gz-Dump, die Archive -files.tar und -private-files.tar sowie die Konfigurationskopie -site_config_backup.json. bench --site erp.example.com backup --with-files erstellt alle vier Dateien. Die Konfigurationskopie enthält encryption_key. Ohne diese Kopie können gespeicherte Passwörter für Integrationen nicht entschlüsselt werden. Das zeigt sich als Encryption key is invalid! Please check site_config.json.

Wie aktualisiere ich ERPNext, ohne meine Daten zu beschädigen?

Erstellen Sie mit --with-files ein Backup, aktivieren Sie den Wartungsmodus, ändern Sie ERPNEXT_VERSION in Ihrer env-Datei, rendern Sie die Compose-Datei erneut, führen Sie den Pull aus, starten Sie den Stack und führen Sie anschließend bench --site erp.example.com migrate aus. Deaktivieren Sie danach den Wartungsmodus. Aktualisieren Sie jeweils nur um eine Hauptversion und lesen Sie vorher die Release Notes. migrate schreibt das Schema und die Dokumentdaten ohne Rückgängig-Funktion um. Für ein Rollback müssen Sie das zu Beginn erstellte Backup wiederherstellen.