ERPNext mit Docker auf einem VPS selbst hosten

Wofür Sie sich beim Betrieb entscheiden

ERPNext selbst auf einem VPS zu hosten, 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. Dadurch gelten für alle folgenden Schritte höhere Anforderungen: Ein Backup ist erst dann ein Backup, wenn Sie es wiederhergestellt haben. Ein nicht festgelegter Image-Tag kann jederzeit eine Schema-Migration auslösen.

Im gesamten Text werden einige Bezeichnungen verwendet. ERPNext ist die Geschäftsanwendung. Frappe ist das zugrunde liegende Python-Framework. Bench ist das Befehlszeilenwerkzeug zur Verwaltung von Sites und bereits in den Containern installiert. Eine Site ist ein Mandant: eine MariaDB-Datenbank und ein Verzeichnis mit hochgeladenen Dateien. Fast jeder Befehl in diesem Text wird bench innerhalb des Containers backend für eine bestimmte Site ausgeführt.

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

Wie viel VPS-Ressourcen 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 ein einzelner 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 markiert ungefähr den Punkt, an dem der Arbeitsspeicher nicht mehr der limitierende Faktor ist.

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 längeren Bericht aus. Neun dauerhaft 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 Out-of-Memory-Killer des Kernels beendet einen Container. docker inspect zeigt dann darin "OOMKilled": true mit Exit-Code 137. Wird ein Worker während eines Jobs beendet, bleibt ein übermitteltes Dokument mit unvollständig ausgeführten Hintergrundaufgaben zurück.

Für ein Unternehmen, das ERPNext täglich verwendet, sind 8 GB RAM, 4 vCPU und 100 GB SSD die realistische Untergrenze. 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 einmal aus und werden anschließend beendet. Daher ergibt sich die Gesamtzahl von elf Containern.

• backend führt die Frappe-Anwendung unter gunicorn aus. Hier 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-Worker (Redis Queue). Sie führen Hintergrundaufgaben wie den Versand ausgehender 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 für 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 Jobwarteschlange.

Diese Aufteilung ist wichtig, weil sie zeigt, welches Log Sie prüfen müssen. Eine festhängende E-Mail ist ein Problem des Queue-Workers. Dafür ist docker compose logs -f queue-short der richtige Befehl. Eine Seite, die geladen wird, aber das Benachrichtigungs-Badge nicht aktualisiert, weist auf ein WebSocket-Problem hin. Wenn Sie für eines dieser Probleme die Logs von backend lesen, verlieren Sie unnötig Zeit.

Mit den Produktions-Compose-Dateien installieren, nicht mit der Demo

Das Repository enthält pwd.yml. 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 ausgeliefert. 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 mit bereits eingesetzten Variablen aus. Anschließend führen Sie diese erzeugte Datei aus. Dieser zusätzliche Schritt lohnt sich: Der laufende Stack liegt als eine lesbare und versionierbare Datei vor. Er kann sich daher nicht unbemerkt ändern, wenn jemand die Env-Datei bearbeitet oder Sie das Repository aktualisieren. wie mehrere Docker-Compose-Dateien zusammengeführt werden erklärt 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 fehlerfreies ps zeigt in running neun Dienste und in restarting keinen Dienst.

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. Für MariaDB kommt die Verbindung daher von einem Remote-Host. Ein Datenbankbenutzer, der auf localhost beschränkt ist, kann sich von dort nicht anmelden. Die Site-Erstellung schlägt dann mit einem MariaDB-Fehler wegen verweigerter Zugriffsberechtigung für den Benutzer root fehl. Der Bereich % erlaubt dem Benutzer der neuen Site den 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. Alternativ setzen Sie FRAPPE_SITE_NAME_HEADER in der Env-Datei auf den Site-Namen und erzeugen die Compose-Datei erneut.

HTTPS und welche Voraussetzungen dafür erfüllt sein müssen

Der compose.https.yaml-Override startet Traefik auf Port 443, leitet Port 80 dorthin um und fordert Zertifikate bei Let's Encrypt an. TLS (Transport Layer Security) verhindert, dass eine Rechnung und ein Sitzungscookie unverschlüsselt ü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 zusätzlich zur Firewall auf dem Server auch die Netzwerk-Firewall Ihres Anbieters. Das sind getrennte Kontrollen, und die Panel-Firewall wird häufig vergessen.

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 einen 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 Port 443 zwischen den Anwendungen aufzuteilen. Die zweite Anwendung auf einem solchen Server ist häufig für Kunden erreichbar. Ein selbst gehostetes Chatwoot-Supportdesk läuft hinter demselben Proxy, sodass die Mitarbeiter, die Rechnungen bearbeiten, Kunden-E-Mails und Chats an einem zentralen Ort beantworten können.

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

Diesen Schritt überspringen die meisten ERPNext-Anleitungen. Er entscheidet jedoch 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 versenden. Die meisten Anbieter blockieren bei neuen Konten ausgehenden Datenverkehr über Port 25. Was dennoch versendet wird, wird abgelehnt oder als Spam abgelegt, weil die Adresse eines neuen VPS noch keine Absenderreputation besitzt. Verwenden Sie ein authentifiziertes Relay über Port 587.

Der unterstützte Weg führt über die Ansicht „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 und nicht als Zeichenfolge "587". Lesen Sie die Datei erneut aus und prüfen 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 die Ansicht „Email Account“ und nicht über die Befehlszeile fest. Dadurch wird der Wert verschlüsselt gespeichert und gelangt nicht in den Shell-Verlauf.

Senden Sie anschließend eine echte Nachricht. Erstellen Sie eine Sales Invoice, senden Sie sie per E-Mail an eine von Ihnen kontrollierte Adresse und beobachten Sie dabei die Warteschlange:

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

Ausgehende E-Mails werden als Hintergrundauftrag verarbeitet. Eine Nachricht, die nicht ankommt, erscheint daher meistens 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 sendende Domain und fügen Sie anschließend eine DMARC-Richtlinie hinzu. 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 Mailserver mit Mailcow ein Relay, das Sie auf einem vom ERP getrennten Server kontrollieren.

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, wird jede hochgeladene Bestellung als defekter Link angezeigt.

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 sites-Volumes 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 weggeworfen. Genau das verursacht später Probleme. Sie enthält encryption_key, den Schlüssel, mit dem Frappe gespeicherte Passwörter verschlüsselt: 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. Das Senden von E-Mails schlägt jedoch mit folgender Meldung fehl:

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

Bewahren Sie immer alle vier Dateien zusammen auf.

Übertragen Sie sie anschließend vom Server. Ein Backup innerhalb des Volumes überlebt den Ausfall oder Verlust des Servers nicht. Außerdem löscht bench Backups aus diesem Verzeichnis standardmäßig nach 24 Stunden.

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 geeignet, weil restic die Daten vor dem Upload verschlüsselt und restic check nachweist, dass das Repository weiterhin lesbar ist. Ein ERP-Backup ist eine Kopie Ihres vollständigen Hauptbuchs. Es gehört daher verschlüsselt im Ruhezustand auf Hardware, die nicht dieser Server ist.

Testen Sie die Wiederherstellung, bevor Sie sie benötigen

Ein nicht getestetes Backup ist nur eine Vermutung. Testen Sie es auf einem zweiten Standort auf demselben Server, niemals auf dem Produktivsystem.

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 den wiederhergestellten Standort. Andernfalls bleiben dessen Integrationen defekt:

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 „Accounts Receivable“ und vergleichen Sie den Endsaldo mit dem Produktivsystem. Öffnen Sie eine kürzlich erstellte Eingangsrechnung und laden Sie ihren Anhang herunter. Dass ein Standort seine Anmeldeseite anzeigt, beweist überhaupt nichts.

Entfernen Sie den Teststandort nach Abschluss des Tests:

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

Warum die Versionsfixierung bei ERPNext wichtiger ist

Bei einer statischen Website bedeutet ein nicht fixierter Image-Tag einen unerwarteten Neustart. Bei ERPNext bedeutet er eine Schema-Migration. bench migrate schreibt Datenbanktabellen um und kann Dokumentdaten neu schreiben. Das lässt sich nicht rückgängig machen. Ein Rollback erfolgt durch die Wiederherstellung eines Backups, nicht durch ein docker compose down.

Fixieren Sie den Tag daher. ERPNEXT_VERSION=v16.32.1 war die Version, die im August 2026 im repositoryeigenen pwd.yml fixiert war. Übernehmen Sie diese Nummer nicht ungeprüft. Aktuelle Releases sind auf der Veröffentlichungsseite von frappe/erpnext aufgeführt. Vorhandene Image-Tags finden Sie auf Docker Hub. Lesen Sie die Hinweise zu der Version, auf die Sie aktualisieren möchten, bevor Sie das Upgrade 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 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 die 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 die Aktualisierung vom unmittelbar 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. Dadurch wird ein Container hinzugefügt, der bei jedem Start bench --site all migrate ausführt. 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 als bewusst getroffene Entscheidung aus.

Eine Box mit Kundendaten absichern

Ändern Sie das Administratorpasswort bei der ersten Anmeldung. Die Evaluierungs-Compose-Datei verwendet admin als Passwort, und diese Gewohnheit wird in Produktionsumgebungen übernommen.

Ändern Sie DB_PASSWORD so, dass es nicht mehr dem 123 in example.env entspricht. Dieser Wert steht im gerenderten ~/gitops/erpnext.yaml im Klartext. Schützen Sie chmod 600 daher entsprechend und halten Sie die Datei aus jedem Git-Repository heraus. Für eine stärkere Absicherung liest overrides/compose.mariadb-secrets.yaml das Passwort stattdessen aus einer Docker-Secret-Datei und nicht aus einer Umgebungsvariable. Umgebungsdateien und Secrets in Docker Compose verwalten erläutert die Abwägungen.

Veröffentlichen Sie nur die benötigten Ports. Mit dem HTTPS-Override sind ausschließlich die Ports 80 und 443 erreichbar. Fügen Sie dem db-Dienst kein ports-Mapping hinzu, damit sich ein Datenbankclient leichter verbinden kann. Dadurch wäre MariaDB im ö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, verweigern 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 als Administratorkonto und nicht als reine Komfortfunktion. Wenn Sie mehrere selbst gehostete Anwendungen betreiben, ist Authentik als selbst gehosteter Single-Sign-on-Provider besser als ein weiteres Passwort für jede Anwendung.

Installieren Sie Sicherheitsupdates auf dem Host und starten Sie ihn für Kernel-Updates neu. Prüfen Sie vor dem Verlassen auf den automatischen Neustart des Stacks die gerenderte Datei auf eine restart-Richtlinie für jeden Dienst. Ohne eine solche Richtlinie bleibt ein Stack nach diesem Neustart beendet. einen Docker-Compose-Stack nach einem Neustart erneut starten erläutert die Einrichtung auf der systemd-Seite.

Wenn ERPNext auf einem 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 Exit-Code 137.
• Berichte, die zuvor zwei Sekunden dauerten, benötigen nun dreißig Sekunden. MariaDB belegt dabei die CPU.
• Backups laufen so lange, dass eines den nächsten geplanten Lauf überlappt.

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 besonders viel Speicher. Ein größerer Anwendungsserver bringt weniger, als viele erwarten. 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 von ERPNext laufen im Hintergrund, insbesondere 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 Container unter Last. docker inspect meldet dies als "OOMKilled": true mit Exit-Code 137. Diese Werte sind Ausgangspunkte und keine Messwerte. Überwachen Sie daher im ersten Monat den tatsächlichen Speicherverbrauch.

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

Nein. Die README des Projekts beschreibt die Datei als ausschließlich für kurzzeitige Evaluierungen vorgesehen. Außerdem weist sie darauf hin, dass sich darin keine benutzerdefinierten Apps installieren lassen. Verwenden Sie compose.yaml mit den Überschreibungen für MariaDB, Redis und HTTPS. Führen Sie diese anschließend mit docker compose config in einer einzelnen Datei zusammen und starten Sie diese Datei.

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

Das Frontend wählt standardmäßig anhand des HTTP-Headers Host aus, welche Site ausgeliefert wird. Der Site-Name muss daher mit der im Browser verwendeten Domain übereinstimmen. Eine als erpnext erstellte Site wird unter erp.example.com nicht ausgeliefert. 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. Erzeugen Sie die Compose-Datei anschließend erneut und starten Sie den Stack neu.

Was muss ein ERPNext-Backup enthalten?

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 erzeugt alle vier Dateien. Die Konfigurationskopie enthält encryption_key. Ohne diese Datei lassen sich gespeicherte Passwörter für Integrationen bei einer Wiederherstellung nicht entschlüsseln. 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, erzeugen Sie die Compose-Datei erneut, laden Sie die Images herunter und starten Sie den Stack. Führen Sie anschließend bench --site erp.example.com migrate aus und deaktivieren Sie 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.