Jak samodzielnie zainstalować ERPNext na VPS przez Docker

Czego podejmujesz się uruchamiając to oprogramowanie

Samodzielne hostowanie ERPNext na VPS to zadanie z zakresu utrzymania systemów, 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 bazy danych.

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ń zarządzające instancjami (sites), zainstalowane wewnątrz kontenerów. Site (instancja) to jeden najemca: jedna baza danych MariaDB oraz jeden katalog przesłanych plików. Prawie każde polecenie w tym przewodniku jest wykonywane za pomocą bench wewnątrz kontenera backend dla konkretnej instancji.

Niniejszy przewodnik korzysta z repozytorium frappe_docker, które jest oficjalną metodą wdrażania utrzymywaną przez twórców projektu. Każde polecenie poniżej zostało zweryfikowane pod kątem tego repozytorium w sierpniu 2026 roku. Jeśli Docker Compose jest dla Ciebie nowością, 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 się pierwszego użytkownika. Jest to poziom ewaluacyjny. Są to wartości początkowe, a nie pomiary wynikające z tego przewodnika; rzeczywiste zapotrzebowanie zależy od wolumenu dokumentów. Ostatni wiersz nie stanowi opublikowanego minimum. Jest to punkt, w którym pamięć przestaje być głównym ograniczeniem.

Należy realistycznie oceniać najtańsze plany. VPS z 1 GB lub 2 GB RAM uruchomi stos, ale ulegnie awarii przy pierwszym imporcie lub generowaniu dłuższego raportu. Dziewięć działających kontenerów, pula buforów MariaDB oraz proces Python tworzący raport nie zmieszczą się w tej pamięci. Awaria nie przebiega w sposób kontrolowany. Mechanizm OOM Killer jądra systemu zatrzymuje kontener, a polecenie docker inspect wykazuje wtedy "OOMKilled": true z kodem wyjścia 137. Proces 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 to uczciwe minimum. Pamięć RAM wyczerpuje się jako pierwsza. Zużycie dysku rośnie szybciej, niż można oczekiwać, ponieważ każdy załącznik i 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, a dziewięć kontenerów działa. Dwa kolejne, configurator oraz create-site, wykonują swoje zadania jednorazowo i kończą pracę, stąd łączna liczba jedenastu.

• 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, a druga dla kolejki zadań.

Warto zrozumieć ten podział, ponieważ wskazuje on, który dziennik należy analizować. Zablokowana wiadomość e-mail oznacza 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. Przeglądanie dzienników backend w obu tych przypadkach to strata czasu.

Instalacja z produkcyjnymi plikami compose, nie demonstracyjnymi

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 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 dostarczany 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 nie uruchamia niczego. Łą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 aktualizację repozytorium. jak łączy się kilka plików Docker Compose wyjaśnia szczegółowo 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ź to:

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ą tutaj dwa problemy. --mariadb-user-host-login-scope=% nie jest opcjonalne w Dockerze. 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 prywatnej sieci.

Drugim problemem jest nazwa witryny. Frontend domyślnie wybiera witrynę do obsłużenia 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 żąda certyfikatów od Let's Encrypt. TLS (transport layer security) chroni faktury oraz pliki cookie sesji przed przesyłaniem w otwartym tekście.

Muszą zostać spełnione dwa warunki, w przeciwnym razie certyfikat nie zostanie wydany. Rekord DNS typu 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ą dostawcy, jak i tę skonfigurowaną na serwerze. Są to niezależne 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 wyjaśnia, jak współdzielić proxy zamiast rywalizować o port 443.

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

Jest to krok pomijany w większości poradników dotyczących ERPNext, a decyduje on o użyteczności systemu. Bez działającej poczty wychodzącej faktura nie dotrze do klienta, nie nadejdzie e-mail z resetem hasła, a zaplanowane raporty nie zostaną wysłane. 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 nowych kont, a każda wiadomość, która zdoła się wydostać, jest odrzucana lub trafia do spamu, ponieważ adres IP nowego serwera VPS nie posiada reputacji nadawcy. Należy użyć uwierzytelnionego przekaźnika (relay) na porcie 587.

Zalecaną metodą jest konfiguracja w ekranie Email Account w interfejsie ERPNext, gdzie hasło przechowywane jest w formie zaszyfrowanej. Klucze można również zapisać bezpośrednio w pliku konfiguracyjnym 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łów:

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

Parametr mail_password należy ustawić przez ekran Email Account, a nie z poziomu wiersza poleceń. Dzięki temu zostanie on zapisany w postaci zaszyfrowanej i nie trafi do historii powłoki.

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

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 odbiorcy, 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 poprawna technicznie faktura nadal może trafić do folderu spam u 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 samej 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

To polecenie 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 przenieść je z serwera. Kopia zapasowa znajdująca się wewnątrz wolumenu nie przetrwa awarii serwera, a narzędzie bench i tak ją usunie: domyślnie usuwa ono z tego katalogu kopie starsze niż 24 godziny.

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 są właściwym narzędziem, 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 innym sprzęcie niż serwer źródłowy.

Przetestuj przywracanie danych, zanim będzie potrzebne

Nietestowana kopia zapasowa to tylko 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 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ócone dane w sposób rzetelny. 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 witryny nieprzypięty tag obrazu oznacza jedynie niespodziewany restart. W ERPNext oznacza to migrację schematu. bench migrate modyfikuje tabele bazy danych i może nadpisać 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. Wersja ERPNEXT_VERSION=v16.32.1 była wydaniem przypiętym w pliku pwd.yml repozytorium w sierpniu 2026 roku. Nie należy przenosić tego numeru bez wcześniejszej weryfikacji. Bieżące wydania są wymienione na stronie wydań frappe/erpnext, a dostępne tagi obrazów znajdują się w serwisie Docker Hub. Przed zmianą wersji należy zapoznać się z informacjami o wydaniu, do którego planowana jest migracja.

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

Należy edytować ERPNEXT_VERSION w ~/gitops/erpnext.env, a następnie wygenerować konfigurację, pobrać obraz i przeprowadzić 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 bazy danych 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ą wersję główną naraz, wykonując kopię zapasową pomiędzy każdym krokiem. Kod migracji w danym wydaniu jest przygotowany do aktualizacji z poprzedniej wersji, więc pomijanie wersji głównych uruchamia migracje w konfiguracji, która nie była przez nikogo testowana.

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 danym dniu.

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 formie jawnego tekstu, 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. Artykuł 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 dostawca SSO jest lepszym rozwiązaniem niż zarządzanie kolejnym hasłem dla każdej aplikacji z osobna.

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

Gdy ERPNext przestaje działać wydajnie na jednym VPS

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

• Zadania w tle gromadzą się w kolejce, przez co e-maile i importy docierają z opóźnieniem wynoszącym minuty lub godziny.
• docker inspect zgłasza kontenery z "OOMKilled": true lub kodem wyjścia 137.
• Raporty, które generowały się dwie sekundy, zajmują teraz trzydzieści, a MariaDB jest procesem najbardziej obciążającym CPU.
• Kopie zapasowe trwają tak długo, że nakładają się na kolejny zaplanowany proces.

Rozpocznij 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 buffer pool jest obszarem, 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 zwiększ liczbę procesów roboczych kolejki (queue workers) zamiast zwiększać wydajność serwera WWW. Wolne działanie ERPNext wynika głównie z zadań w tle: generowania raportów i masowych importów danych. 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?

Zalecenia początkowe 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 i 4 vCPU oraz 100 GB przestrzeni SSD. Poniżej tych wartości mechanizm kernel out of memory killer zatrzymuje kontenery pod obciążeniem, co docker inspect raportuje jako "OOMKilled": true z kodem wyjścia 137. Są to wartości orientacyjne, a nie pomiarowe, dlatego należy monitorować zużycie pamięci przez pierwszy miesiąc pracy.

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

Nie. Dokumentacja README projektu określa ten plik jako przeznaczony wyłącznie do krótkotrwałych testów i zaznacza, że nie pozwala on na instalację własnych aplikacji. Należy użyć compose.yaml z odpowiednimi nadpisaniami dla MariaDB, Redis i HTTPS, wygenerować plik wynikowy za pomocą docker compose config, a następnie go uruchomić.

Dlaczego moja witryna ERPNext jest nieosiągalna 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ą naraz, czytając wcześniej informacje o wydaniu, ponieważ migrate dokonuje przebudowy schematu i danych dokumentów bez możliwości cofnięcia zmian. Powrót do poprzedniej wersji wymaga przywrócenia kopii zapasowej wykonanej na początku procesu.