Jak zainstalować ERPNext na VPS przy użyciu Docker

Czym jest uruchamiana usługa

Samodzielne hostowanie ERPNext na VPS to zadanie operacyjne, a nie instalacja za pomocą jednego polecenia. Oficjalny stos Docker Compose składa się z jedenastu kontenerów i przechowuje księgę główną oraz dane klientów. Podnosi to wymagania dla wszystkich poniższych działań: kopia zapasowa nie jest kopią, dopóki nie zostanie przywrócona, a nieprzypięty tag obrazu to zapowiedź problemów przy migracji schematu.

W tekście pojawia się kilka nazw. ERPNext to aplikacja biznesowa. Frappe to framework w języku Python, na którym jest oparta. Bench to narzędzie wiersza poleceń służące do zarządzania witrynami, zainstalowane wewnątrz kontenerów. Witryna (site) to jeden najemca: jedna baza danych MariaDB oraz jeden katalog z przesłanymi plikami. Prawie każde polecenie w tym przewodniku jest wykonywane za pomocą bench wewnątrz kontenera backend dla konkretnej witryny.

Ten przewodnik korzysta z repozytorium frappe_docker, które jest oficjalną metodą wdrażania utrzymywaną przez projekt. Każde poniższe polecenie zostało zweryfikowane w odniesieniu do tego repozytorium w sierpniu 2026 roku. Jeśli Docker Compose jest nowym narzędziem, uruchamianie Docker Compose na VPS zawiera podstawy, na których opiera się ten przewodnik.

Jakich zasobów VPS wymaga 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
  }
]

Opublikowane wytyczne wskazują na 2 vCPU oraz 4 GB pamięci RAM przed zalogowaniem pierwszego użytkownika. Jest to poziom ewaluacyjny. Są to wartości początkowe, a nie pomiary wynikające z niniejszego przewodnika; rzeczywiste zapotrzebowanie zależy od wolumenu dokumentów. Ostatni wiersz nie stanowi opublikowanego minimum. Określa on przybliżony punkt, w którym pamięć przestaje być głównym ograniczeniem.

Należy realistycznie ocenić najmniejsze plany hostingowe. VPS z 1 GB lub 2 GB RAM uruchomi stos, ale ulegnie awarii przy pierwszym imporcie lub generowaniu dłuższego raportu. Wynika to z faktu, że dziewięć działających kontenerów, pula buforów MariaDB oraz proces roboczy Python generujący raport nie mieszczą się w tej pamięci. Awaria nie przebiega w sposób kontrolowany. Mechanizm kernel out of memory killer zatrzymuje kontener, a polecenie docker inspect wykazuje wtedy "OOMKilled": true z kodem wyjścia 137. Proces roboczy przerwany w trakcie pracy pozostawia przesłany dokument z niedokończonymi zadaniami w tle.

Dla firmy korzystającej z ERPNext codziennie, 8 GB RAM i 4 vCPU z 100 GB przestrzeni SSD stanowi uczciwe minimum. Pamięć RAM wyczerpuje się jako pierwsza. Zużycie dysku rośnie szybciej, niż można oczekiwać, ponieważ każdy załącznik oraz każda lokalna kopia zapasowa trafiają na ten sam wolumen co baza danych.

Jedenaście kontenerów i rola każdego z nich

Uruchom docker compose ps, gdy stos jest gotowy i działa dziewięć kontenerów. Dwa kolejne, configurator oraz create-site, wykonują swoje zadania jednorazowo i kończą działanie, co daje łącznie jedenaście jednostek.

• backend uruchamia aplikację Frappe w środowisku gunicorn. To tutaj znajduje się bench.
• frontend to nginx. Serwuje zasoby statyczne i przekazuje pozostały ruch do backendu.
• queue-short oraz queue-long to procesy robocze RQ (Redis Queue). Obsługują zadania w tle, takie jak wysyłka wiadomości e-mail, importy oraz generowanie raportów.
• scheduler wyzwala zadania czasowe, w tym zaplanowane raporty i automatyczne powtarzanie dokumentów.
• websocket to proces socket.io odpowiadający za aktualizacje na żywo w przeglądarce.
• db to MariaDB.
• redis-cache oraz redis-queue to dwie oddzielne instancje Redis: jedna dla pamięci podręcznej, druga dla kolejki zadań.

Warto poznać ten podział, ponieważ wskazuje on, który dziennik należy analizować. Zablokowana wiadomość e-mail to problem z procesem roboczym kolejki, więc właściwym poleceniem jest docker compose logs -f queue-short. Strona, która się ładuje, ale nie aktualizuje powiadomień, wskazuje na problem z websocketami. Analiza dzienników backend w obu tych przypadkach to strata czasu.

Instalacja przy użyciu produkcyjnych plików compose, a nie wersji demonstracyjnej

Repozytorium dostarcza pwd.yml, a plik README jasno to określa: „Ta konfiguracja jest przeznaczona wyłącznie do krótkotrwałej oceny. W tej konfiguracji nie będzie można instalować własnych aplikacji”. Użyj jej, aby zapoznać się z ERPNext przez jedno popołudnie. Nie uruchamiaj na niej firmy.

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

Otwórz ~/gitops/erpnext.env i zmień cztery wartości. ERPNEXT_VERSION przypina tag obrazu. DB_PASSWORD jest dostarczane jako 123 w przykładowym pliku. SITES_RULE to reguła routingu Traefik, a LETSENCRYPT_EMAIL otrzymuje ostrzeżenia o certyfikatach.

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

Teraz wygeneruj jeden plik compose, a następnie uruchom go.

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 niczego nie uruchamia. Łączy plik bazowy z nadpisaniami i wyświetla wynik z już podstawionymi wszystkimi zmiennymi. Następnie uruchamiasz ten wygenerowany plik. Ten dodatkowy krok jest uzasadniony: działający stos to jeden plik, który można odczytać i zatwierdzić w systemie kontroli wersji, więc nie zmieni się on w sposób niekontrolowany, gdy ktoś edytuje plik env lub gdy pobierzesz repozytorium. sposób łączenia kilku plików Docker Compose szczegółowo wyjaśnia zasady nadpisywania.

Poczekaj, aż db się uruchomi, a configurator zakończy działanie, co zajmuje kilka sekund, a następnie utwórz witrynę.

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

Sprawdź działanie:

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

list-apps powinno wyświetlić frappe oraz erpnext wraz z ich wersjami. Prawidłowo działający ps pokazuje dziewięć usług w stanie running i żadnej w stanie restarting.

Często występują tu dwa problemy. --mariadb-user-host-login-scope=% nie jest opcjonalne w Docker. Kontener aplikacji łączy się z MariaDB przez sieć Docker, więc dociera jako host zdalny, a użytkownik bazy danych przypisany do localhost nie może się stamtąd zalogować. Tworzenie witryny kończy się wtedy błędem odmowy dostępu MariaDB dla użytkownika root. Zakres % przyznaje użytkownikowi nowej witryny dostęp z dowolnego hosta w tej sieci prywatnej.

Drugim problemem jest nazwa witryny. Frontend domyślnie wybiera witrynę do obsługi na podstawie nagłówka HTTP Host, więc witryna utworzona jako erpnext nie jest dostępna pod adresem erp.example.com, nawet jeśli obie istnieją. Nazwij witrynę zgodnie z domeną, jak powyżej, lub ustaw FRAPPE_SITE_NAME_HEADER w pliku env na nazwę witryny i ponownie wygeneruj plik compose.

HTTPS oraz warunki konieczne do poprawnego działania

Nadpisanie compose.https.yaml uruchamia Traefik na porcie 443, przekierowuje na niego ruch z portu 80 i występuje o certyfikaty do Let's Encrypt. TLS (transport layer security) zapobiega przesyłaniu faktur oraz plików cookie sesji w postaci otwartego tekstu.

Muszą zostać spełnione dwa warunki, w przeciwnym razie certyfikat nie zostanie wydany. Rekord DNS A dla erp.example.com musi już wskazywać na VPS. Porty 80 oraz 443 muszą być osiągalne z Internetu, ponieważ Let's Encrypt weryfikuje kontrolę nad domeną za pomocą wyzwania HTTP-01 na porcie 80. Należy sprawdzić zarówno zaporę sieciową u dostawcy, jak i tę skonfigurowaną na serwerze. Są to odrębne mechanizmy kontroli, a o zaporze w panelu zarządzania często się zapomina.

Certyfikaty trafiają do wolumenu cert-data w lokalizacji /letsencrypt/acme.json. Jeśli przeglądarka wyświetla certyfikat domyślny zamiast własnego, należy odnaleźć nazwę usługi proxy w docker compose --project-name erpnext ps i sprawdzić jej dzienniki pod kątem błędów ACME (automatic certificate management environment). Uruchamiasz inne aplikacje webowe na tym samym serwerze? jedna instancja Traefik przed wieloma aplikacjami Docker Compose pokazuje, jak współdzielić proxy zamiast rywalizować o port 443. Druga aplikacja na takim serwerze często służy do obsługi klientów, a własny system wsparcia Chatwoot działa za tym samym proxy, dzięki czemu osoby zajmujące się fakturami mogą również odpowiadać na e-maile i czaty klientów w jednym miejscu.

Poczta wychodząca, czyli dlaczego faktury nie opuszczają skrzynki

To etap, który pomija większość przewodników po ERPNext, a decyduje on o użyteczności systemu. Bez działającej poczty wychodzącej żadna faktura nie dotrze do klienta, nie nadejdzie żaden reset hasła, ani nie zostanie dostarczony żaden zaplanowany raport. Stos technologiczny nie zawiera serwera pocztowego.

Nie należy próbować wysyłać poczty bezpośrednio z VPS przez port 25. Większość dostawców blokuje port 25 dla ruchu wychodzącego na nowych kontach, a każda wiadomość, która zdoła się wydostać, jest odrzucana lub trafia do spamu, ponieważ nowy adres IP serwera VPS nie posiada reputacji nadawcy. Należy użyć uwierzytelnionego przekaźnika (relay) na porcie 587.

Zalecaną metodą jest ekran Email Account w interfejsie ERPNext, który przechowuje hasło w formie zaszyfrowanej. Można również wpisać klucze bezpośrednio do pliku konfiguracyjnego witryny:

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 przechowuje 587 jako liczbę, a nie ciąg znaków "587". Należy odczytać plik i upewnić się, że te dwie wartości nie są ujęte w cudzysłowy:

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

Ustawienie mail_password należy przeprowadzić przez ekran Email Account, a nie z poziomu wiersza poleceń, dzięki czemu zostanie ono zapisane w formie zaszyfrowanej i nigdy nie trafi do historii powłoki.

Następnie należy wysłać rzeczywistą wiadomość. Trzeba utworzyć Sales Invoice, wysłać go na kontrolowany przez siebie adres e-mail i monitorować kolejkę w trakcie operacji:

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

Poczta wychodząca jest zadaniem działającym w tle, więc wiadomość, która nie dociera do adresata, zazwyczaj pojawia się w tym dzienniku jako nieudane zadanie, a nie jako błąd w przeglądarce. Należy również opublikować rekordy SPF (sender policy framework) oraz DKIM (domainkeys identified mail) dla domeny nadawcy, a następnie dodać politykę DMARC. Bez nich technicznie poprawna faktura nadal trafi do folderu spam klienta. Jeśli wolisz zarządzać całą ścieżką samodzielnie, własny serwer pocztowy Mailcow zapewni przekaźnik pod Twoją kontrolą, działający na oddzielnej maszynie niż ERP.

Kopie zapasowe, które faktycznie można przywrócić

Sam zrzut bazy danych nie stanowi kopii zapasowej ERPNext. Załączniki i pliki prywatne znajdują się w katalogu sites, a nie w MariaDB. Przywrócenie wyłącznie bazy danych spowoduje, że każde przesłane zamówienie zakupu będzie wyświetlane jako uszkodzony odnośnik.

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

Polecenie to zapisuje cztery pliki w sites/erp.example.com/private/backups wewnątrz wolumenu sites:

• zrzut -database.sql.gz
• archiwum -files.tar plików publicznych
• archiwum -private-files.tar plików prywatnych
• kopię -site_config_backup.json konfiguracji witryny

Czwarty plik jest tym, który użytkownicy często pomijają, a jego brak powoduje najwięcej problemów. Zawiera on encryption_key, czyli klucz, którego Frappe używa do szyfrowania przechowywanych haseł: danych uwierzytelniających kont e-mail, kluczy bramek płatności oraz wszystkich sekretów integracji. Przywrócenie bazy danych bez pasującego klucza sprawi, że witryna załaduje się poprawnie, ale wysyłka wiadomości e-mail zakończy się błędem:

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

Wszystkie cztery pliki należy zawsze przechowywać razem.

Następnie należy je przenieść poza serwer. Kopia zapasowa znajdująca się wewnątrz wolumenu nie przetrwa awarii serwera, a ponadto bench automatycznie ją usuwa: domyślnie usuwane są kopie starsze niż 24 godziny z tego katalogu.

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

Polecenie to należy uruchamiać za pomocą cron, a następnie przesyłać katalog w miejsce, które nie jest administrowane przez ten sam podmiot. szyfrowane kopie zapasowe restic do pamięci zewnętrznej stanowią odpowiednie narzędzie, ponieważ szyfrują dane przed wysyłką, a restic check potwierdza, że repozytorium jest nadal czytelne. Kopia zapasowa ERP to kopia całej księgi rachunkowej, dlatego powinna być przechowywana w formie zaszyfrowanej na sprzęcie innym niż serwer źródłowy.

Przetestuj przywracanie danych, zanim zajdzie taka potrzeba

Nietestowana kopia zapasowa to jedynie przypuszczenie. Przetestuj ją w drugiej lokalizacji na tym samym serwerze, nigdy w środowisku produkcyjnym.

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>'

Skopiuj klucz szyfrujący z kopii zapasowej konfiguracji do przywróconej witryny, w przeciwnym razie jej integracje pozostaną niedziałające:

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

Teraz sprawdź przywróconą kopię w sposób skrupulatny. Otwórz raport należności (Accounts Receivable) i porównaj saldo końcowe z witryną produkcyjną. Otwórz niedawną fakturę zakupu i pobierz załącznik. Witryna, która wyświetla jedynie stronę logowania, nie stanowi dowodu poprawności danych.

Po zakończeniu usuń witrynę testową:

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

Dlaczego przypinanie wersji jest kluczowe dla ERPNext

W przypadku statycznej strony brak przypiętego tagu obrazu oznacza jedynie niespodziewany restart. W ERPNext oznacza to migrację schematu. bench migrate modyfikuje tabele bazy danych i może nadpisywać dane dokumentów, a operacja ta jest nieodwracalna. Wycofanie zmian wymaga przywrócenia kopii zapasowej, a nie użycia docker compose down.

Dlatego należy przypinać tagi. ERPNEXT_VERSION=v16.32.1 było wersją przypiętą w pliku pwd.yml repozytorium w sierpniu 2026 roku. Nie należy przenosić tego numeru bez wcześniejszej weryfikacji. Aktualne wydania znajdują się na stronie wydań frappe/erpnext, a dostępne tagi obrazów na Docker Hub. Przed zmianą wersji należy zapoznać się z informacjami o wydaniu.

Sama aktualizacja rozpoczyna się od wykonania kopii zapasowej i włączenia trybu konserwacji.

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

Edytuj ERPNEXT_VERSION w ~/gitops/erpnext.env, a następnie wykonaj renderowanie, pobranie obrazu i migrację.

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

Tryb konserwacji jest istotny, ponieważ migrate zmienia schemat w trakcie działania. Użytkownik przesyłający dokument w momencie, gdy tabela jest w trakcie migracji, doprowadzi do konieczności ręcznej naprawy rekordów.

Aktualizacje należy przeprowadzać o jedną główną wersję naraz, wykonując kopię zapasową pomiędzy każdym krokiem. Kod migracji w danym wydaniu jest przygotowany do aktualizacji z wersji bezpośrednio go poprzedzającej, więc pomijanie głównych wersji uruchamia migracje w konfiguracji, której nikt nie testował.

Repozytorium dostarcza również overrides/compose.migrator.yaml, który dodaje kontener uruchamiający bench --site all migrate przy każdym starcie. Jest to wygodne rozwiązanie. Oznacza jednak, że docker compose up ze zmienionym tagiem przeprowadzi migrację produkcyjnej bazy danych bez nadzoru. W systemach biznesowych uruchomienie migracji powinno być świadomą decyzją podjętą w odpowiednim czasie.

Zabezpieczanie serwera przechowującego dane klientów

Zmień hasło administratora przy pierwszym logowaniu. Przykładowy plik compose zawiera admin jako hasło domyślne, a nawyk ten jest często przenoszony do środowisk produkcyjnych.

Zmień DB_PASSWORD na wartość inną niż 123 w pliku example.env. Wartość ta trafia do wygenerowanego pliku ~/gitops/erpnext.yaml w postaci jawnej, dlatego należy chmod 600 ten plik i nie umieszczać go w żadnym repozytorium git. Aby uzyskać wyższy poziom bezpieczeństwa, overrides/compose.mariadb-secrets.yaml odczytuje hasło z pliku Docker secret zamiast ze zmiennej środowiskowej. obsługa plików env i sekretów w Docker Compose omawia wady i zalety tego rozwiązania.

Udostępniaj tylko niezbędne zasoby. Przy użyciu nadpisania HTTPS, jedynymi otwartymi portami powinny być 80 oraz 443. Nie dodawaj mapowania ports do usługi db w celu ułatwienia połączenia klientowi bazy danych: wystawia to MariaDB bezpośrednio do publicznego Internetu. Zamiast tego użyj docker compose --project-name erpnext exec backend bench mariadb. Na hoście zezwól na ruch na portach 22, 80 oraz 443, zablokuj pozostałe i sprawdź również zewnętrzny firewall dostawcy usług.

Włącz uwierzytelnianie dwuskładnikowe w ustawieniach systemowych dla każdego konta posiadającego rolę System Manager. Rola ta umożliwia odczyt każdego dokumentu i eksport każdej tabeli, dlatego należy traktować ją jak konto administratora, a nie jako udogodnienie. Jeśli uruchamiasz kilka aplikacji we własnej infrastrukturze, Authentik jako samodzielny dostawca SSO jest lepszym rozwiązaniem niż zarządzanie kolejnym hasłem dla każdej aplikacji.

Aktualizuj hosta i wykonuj restart po aktualizacjach jądra. Zanim założysz, że stos usług uruchomi się ponownie, sprawdź w wygenerowanym pliku politykę restart dla każdej usługi, ponieważ stos bez niej pozostanie wyłączony po restarcie. automatyczne uruchamianie stosu Docker Compose po restarcie systemu omawia konfigurację po stronie systemd.

Gdy ERPNext przestaje działać wydajnie na jednym VPS

Jeden VPS może obsługiwać małą firmę przez długi czas. Oznaki, że zasoby stały się niewystarczające:

• Zadania w tle (background jobs) gromadzą się, przez co e-maile i importy docierają z kilkuminutowym lub kilkugodzinnym opóźnieniem.
• docker inspect zgłasza kontenery z "OOMKilled": true lub kodem wyjścia 137.
• Raporty, których generowanie trwało dwie sekundy, zajmują teraz trzydzieści, a procesem obciążającym CPU jest MariaDB.
• Kopie zapasowe trwają tak długo, że nakładają się na kolejny zaplanowany proces.

Zacznij od przydzielenia MariaDB zasobów, których nie będzie współdzielić, ponieważ baza danych i procesy robocze Python rywalizują o tę samą pamięć, a pula buforów (buffer pool) jest elementem, który wymaga jej najwięcej. Zwiększenie zasobów serwera aplikacji pomaga mniej, niż można by oczekiwać. uruchomienie bazy danych w Docker lub na hoście omawia tę decyzję, a ustawienie limitów pamięci w Docker Compose zapobiega sytuacji, w której jeden kontener wyczerpuje zasoby pozostałych podczas wprowadzania zmian.

Następnie dodaj procesy robocze kolejki (queue workers) zamiast zwiększać wydajność serwera WWW. Wolne działanie ERPNext wynika zazwyczaj z zadań w tle: generowania raportów i masowych importów. Więcej kontenerów typu worker kosztuje mniej niż większa maszyna, a rozwiązuje problemy, na które faktycznie skarżą się użytkownicy.

FAQ

Ile pamięci RAM wymaga ERPNext na serwerze VPS?

Oficjalne wytyczne wskazują na 4 GB pamięci RAM oraz 2 vCPU, jednak ten poziom jest przeznaczony wyłącznie do celów ewaluacyjnych. W przypadku codziennego użytkowania w firmie należy zaplanować 8 GB pamięci RAM, 4 vCPU oraz 100 GB przestrzeni SSD. Poniżej tych wartości mechanizm OOM (Out of Memory) killera przerywa działanie kontenerów pod obciążeniem, co docker inspect raportuje jako "OOMKilled": true z kodem wyjścia 137. Są to wartości początkowe, a nie pomiary, dlatego należy monitorować zużycie pamięci przez pierwszy miesiąc pracy.

Czy można uruchomić pwd.yml w środowisku produkcyjnym?

Nie. Plik README projektu określa go jako narzędzie przeznaczone wyłącznie do krótkotrwałej ewaluacji i zaznacza, że nie pozwala on na instalację własnych aplikacji. Należy użyć compose.yaml z nadpisaniami dla MariaDB, Redis oraz HTTPS, wygenerować plik wynikowy za pomocą docker compose config i uruchomić go.

Dlaczego witryna ERPNext jest niedostępna zaraz po utworzeniu?

Frontend domyślnie wybiera witrynę do obsłużenia na podstawie nagłówka HTTP Host, dlatego nazwa witryny musi być zgodna z domeną wpisaną w przeglądarce. Witryna utworzona jako erpnext nie będzie dostępna pod adresem erp.example.com. Należy albo utworzyć witrynę używając domeny jako jej nazwy, albo ustawić FRAPPE_SITE_NAME_HEADER w pliku env na nazwę witryny, ponownie wygenerować plik compose i zrestartować stos.

Co musi zawierać kopia zapasowa ERPNext?

Cztery pliki przechowywane razem: zrzut -database.sql.gz, archiwa -files.tar i -private-files.tar oraz kopię konfiguracji -site_config_backup.json. Uruchomienie bench --site erp.example.com backup --with-files generuje wszystkie cztery elementy. Kopia konfiguracji zawiera encryption_key, więc przywrócenie danych bez niej uniemożliwia odszyfrowanie zapisanych haseł integracji, co objawia się błędem Encryption key is invalid! Please check site_config.json.

Jak zaktualizować ERPNext bez utraty danych?

Należy wykonać kopię zapasową za pomocą --with-files, włączyć tryb konserwacji, zmienić ERPNEXT_VERSION w pliku env, ponownie wygenerować plik compose, pobrać obrazy, uruchomić stos, a następnie wykonać bench --site erp.example.com migrate i wyłączyć tryb konserwacji. Aktualizacje należy przeprowadzać o jedną wersję główną na raz, czytając wcześniej informacje o wydaniu, ponieważ migrate dokonuje zmian w schemacie bazy danych i danych dokumentów bez możliwości cofnięcia operacji. Wycofanie zmian wymaga przywrócenia kopii zapasowej wykonanej na początku procesu.