VPS पर Docker के जरिए ERPNext को कैसे install करें

आप क्या चलाने के लिए तैयार हो रहे हैं

VPS पर ERPNext को self-host करना एक operations का काम है, न कि एक command में होने वाला install। आधिकारिक Docker Compose stack में ग्यारह containers होते हैं, और इसमें आपका general ledger तथा customer records सुरक्षित रहते हैं। यह नीचे दी गई हर चीज़ के लिए मानक को बढ़ा देता है: backup तब तक backup नहीं है जब तक आपने उसे restore न किया हो, और एक unpinned image tag का मतलब है कि schema migration कभी भी हो सकता है।

पूरी प्रक्रिया में कुछ नाम बार-बार आएंगे। ERPNext एक business application है। Frappe इसके नीचे काम करने वाला Python framework है। Bench एक command line tool है जो sites को manage करता है, और यह containers के अंदर पहले से ही installed होता है। एक site का अर्थ है एक tenant: एक MariaDB database और uploaded files की एक directory। यहाँ दी गई लगभग हर command bench के अंदर backend container में एक विशिष्ट site के लिए चलाई जाती है।

यह guide frappe_docker repository का उपयोग करती है, जो कि project द्वारा maintain किया जाने वाला deployment है। नीचे दी गई हर command को August 2026 में उस repository के आधार पर जाँचा गया था। यदि Docker Compose आपके लिए नया है, तो VPS पर Docker Compose चलाना उन बुनियादी बातों को कवर करता है जिन्हें यह guide मानकर चलती है।

ERPNext के लिए कितने VPS की आवश्यकता है?

[
  {
    "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
  }
]

प्रकाशित मार्गदर्शन 2 vCPU और 4 GB RAM से शुरू होता है, इससे पहले कि कोई भी उपयोगकर्ता लॉग इन करे। यह मूल्यांकन स्तर (evaluation tier) है। ये शुरुआती बिंदु हैं, इस गाइड से लिए गए माप नहीं, और वास्तविक संख्या आपके दस्तावेज़ों की मात्रा पर निर्भर करती है। अंतिम पंक्ति कोई प्रकाशित न्यूनतम आवश्यकता नहीं है। यह लगभग वह स्तर है जहाँ मेमोरी की चिंता करना बंद हो जाता है।

छोटे प्लान के बारे में स्वयं के प्रति स्पष्ट रहें। 1 GB या 2 GB का VPS स्टैक को शुरू तो कर देगा, लेकिन पहले इम्पोर्ट या पहली लंबी रिपोर्ट के दौरान क्रैश हो जाएगा। इसका कारण यह है कि नौ लंबे समय तक चलने वाले कंटेनर, MariaDB का बफर पूल और रिपोर्ट तैयार करने वाला Python वर्कर उस मेमोरी में फिट नहीं होते हैं। यह विफलता सुचारू नहीं होती है। कर्नल का out of memory killer किसी कंटेनर को रोक देता है, और उस पर docker inspect चलाने पर exit code 137 के साथ "OOMKilled": true दिखाई देता है। काम के बीच में मारा गया वर्कर एक सबमिट किए गए दस्तावेज़ को अधूरा छोड़ देता है।

हर दिन ERPNext का उपयोग करने वाली कंपनी के लिए, 8 GB RAM और 4 vCPU के साथ 100 GB SSD एक वास्तविक न्यूनतम आधार है। RAM सबसे पहले समाप्त होती है। डिस्क लोगों की अपेक्षा से अधिक तेज़ी से भरती है, क्योंकि हर अटैचमेंट और हर लोकल बैकअप उसी वॉल्यूम पर जाता है जहाँ डेटाबेस होता है।

ग्यारह कंटेनर और प्रत्येक का कार्य

स्टैक के चालू होने और नौ कंटेनरों के चलने के बाद docker compose ps चलाएं। दो और कंटेनर, configurator और create-site, अपना काम एक बार पूरा करते हैं और बंद हो जाते हैं, जिससे कुल संख्या ग्यारह हो जाती है।

• backend, gunicorn के अंतर्गत Frappe एप्लिकेशन को चलाता है। bench यहीं स्थित होता है।
• frontend, nginx है। यह static assets को सर्व करता है और बाकी सब कुछ backend को भेज देता है।
• queue-short और queue-long, RQ (Redis Queue) वर्कर्स हैं। ये background jobs जैसे कि ईमेल भेजना, इम्पोर्ट और रिपोर्ट तैयार करना संभालते हैं।
• scheduler, समय-आधारित जॉब्स को ट्रिगर करता है, जिसमें निर्धारित रिपोर्ट और ऑटो-रिपीट डॉक्यूमेंट्स शामिल हैं।
• websocket, ब्राउज़र में लाइव अपडेट के लिए जिम्मेदार socket.io प्रोसेस है।
• db, MariaDB है।
• redis-cache और redis-queue, दो अलग-अलग Redis इंस्टेंस हैं, एक cache के लिए और दूसरा जॉब क्यू के लिए।

इस विभाजन को समझना महत्वपूर्ण है, क्योंकि इससे पता चलता है कि कौन सा लॉग पढ़ना है। यदि ईमेल अटक गया है, तो यह एक क्यू वर्कर की समस्या है, इसलिए docker compose logs -f queue-short सही कमांड है। यदि कोई पेज लोड तो होता है लेकिन उसका नोटिफिकेशन बैज अपडेट नहीं होता, तो यह एक वेबसॉकेट की समस्या है। किसी भी स्थिति के लिए backend के लॉग पढ़ना समय की बर्बादी है।

Production compose files का उपयोग करें, demo का नहीं

Repository में pwd.yml शामिल है, और README इस बारे में स्पष्ट है: "यह सेटअप केवल अल्पकालिक मूल्यांकन के लिए है। आप इस सेटअप में custom apps इंस्टॉल नहीं कर पाएंगे।" इसका उपयोग ERPNext को कुछ घंटों के लिए देखने के लिए करें। इस पर कोई कंपनी न चलाएं।

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

~/gitops/erpnext.env खोलें और चार मान बदलें। ERPNEXT_VERSION image tag को पिन करता है। DB_PASSWORD उदाहरण फ़ाइल में 123 के रूप में आता है। SITES_RULE Traefik routing rule है, और LETSENCRYPT_EMAIL certificate warnings प्राप्त करता है।

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

अब एक compose फ़ाइल रेंडर करें, फिर उसे start करें।

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 कुछ भी start नहीं करता है। यह base फ़ाइल को overrides के साथ मिलाता है और हर variable के प्रतिस्थापित होने के बाद परिणाम प्रिंट करता है। फिर आप उस रेंडर की गई फ़ाइल को चलाते हैं। यह अतिरिक्त चरण उपयोगी है: चल रहा stack एक ऐसी फ़ाइल है जिसे आप पढ़ और commit कर सकते हैं, इसलिए जब कोई env फ़ाइल को edit करता है या जब आप repository pull करते हैं, तो यह आपके बिना जानकारी के बदल नहीं सकता है। Docker Compose फ़ाइलों के मर्ज होने का तरीका override नियमों को विस्तार से समझाता है।

db के start होने और configurator के exit होने की प्रतीक्षा करें, जिसमें कुछ सेकंड लगते हैं, फिर 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

इसे जांचें:

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

list-apps को frappe और erpnext को उनके versions के साथ प्रिंट करना चाहिए। एक स्वस्थ ps, running state में नौ services दिखाता है और restarting में कोई नहीं।

यहाँ अक्सर दो चीजें गलत हो जाती हैं। Docker के अंतर्गत --mariadb-user-host-login-scope=% वैकल्पिक नहीं है। App container, Docker network के माध्यम से MariaDB तक पहुँचता है, इसलिए यह एक remote host के रूप में आता है, और localhost तक सीमित database user वहाँ से login नहीं कर सकता है। तब site creation, root user के नाम के साथ MariaDB access denied error के कारण विफल हो जाता है। % scope, नई site के user को उस private network पर किसी भी host से access प्रदान करता है।

दूसरी समस्या site का नाम है। Frontend डिफ़ॉल्ट रूप से HTTP Host header से चुनता है कि किस site को serve करना है, इसलिए erpnext के रूप में बनाई गई site, erp.example.com पर पहुँच योग्य नहीं है, भले ही दोनों मौजूद हों। Site का नाम domain के अनुसार रखें, जैसा कि ऊपर बताया गया है, या env फ़ाइल में FRAPPE_SITE_NAME_HEADER को site के नाम पर सेट करें और compose फ़ाइल को फिर से रेंडर करें।

HTTPS, और इसके काम करने के लिए किन शर्तों का पूरा होना आवश्यक है

compose.https.yaml ओवरराइड Traefik को port 443 पर चलाता है, port 80 को उस पर रीडायरेक्ट करता है, और Let's Encrypt से certificates का अनुरोध करता है। TLS (transport layer security) वह तकनीक है जो इनवॉइस और session cookie को plain text में नेटवर्क पर जाने से रोकती है।

दो चीजें सही होनी चाहिए, अन्यथा कोई certificate जारी नहीं होगा। erp.example.com के लिए DNS A record का VPS की ओर इशारा करना अनिवार्य है। Port 80 और 443 इंटरनेट से पहुँच योग्य होने चाहिए, क्योंकि Let's Encrypt यह पुष्टि करता है कि आप port 80 पर HTTP-01 challenge के माध्यम से उस नाम को नियंत्रित करते हैं। अपने प्रदाता के नेटवर्क firewall के साथ-साथ सर्वर के firewall की भी जाँच करें। ये दोनों अलग-अलग नियंत्रण हैं, और लोग अक्सर panel firewall को भूल जाते हैं।

Certificates cert-data वॉल्यूम में /letsencrypt/acme.json पर सुरक्षित रहते हैं। यदि ब्राउज़र आपके certificate के बजाय default certificate दिखाता है, तो docker compose --project-name erpnext ps में proxy service का नाम ढूँढें और ACME (automatic certificate management environment) त्रुटि के लिए उसके logs पढ़ें। क्या आप उसी सर्वर पर अन्य web apps चला रहे हैं? कई Docker Compose apps के सामने एक Traefik instance यह दर्शाता है कि port 443 के लिए संघर्ष करने के बजाय proxy को साझा कैसे किया जाए।

आउटबाउंड ईमेल, या इनवॉइस का सर्वर से बाहर न जाना

यह वह चरण है जिसे अधिकांश ERPNext गाइड छोड़ देती हैं, और यही तय करता है कि सिस्टम उपयोगी है या नहीं। यदि आउटबाउंड मेल काम नहीं कर रहा है, तो कोई भी इनवॉइस ग्राहक तक नहीं पहुँचेगा, पासवर्ड रीसेट ईमेल प्राप्त नहीं होगा, और कोई भी निर्धारित रिपोर्ट डिलीवर नहीं होगी। इस स्टैक में कोई मेल सर्वर शामिल नहीं है।

VPS से सीधे port 25 पर मेल भेजने का प्रयास न करें। अधिकांश प्रदाता नए खातों पर आउटबाउंड port 25 को ब्लॉक कर देते हैं, और जो कुछ भी बाहर जाता है उसे या तो रिजेक्ट कर दिया जाता है या स्पैम के रूप में चिह्नित किया जाता है, क्योंकि एक नए VPS पते की कोई सेंडिंग रेपुटेशन नहीं होती है। port 587 पर एक ऑथेंटिकेटेड रिले का उपयोग करें।

समर्थित तरीका ERPNext इंटरफ़ेस में Email Account स्क्रीन है, जो पासवर्ड को एन्क्रिप्ट करके स्टोर करती है। आप keys को सीधे site config में भी लिख सकते हैं:

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, 587 को स्ट्रिंग "587" के बजाय एक संख्या के रूप में स्टोर करता है। फ़ाइल को वापस पढ़ें और सुनिश्चित करें कि उन दो मानों के चारों ओर कोई उद्धरण चिह्न (quotes) नहीं हैं:

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

mail_password को कमांड लाइन के बजाय Email Account स्क्रीन के माध्यम से सेट करें, ताकि यह एन्क्रिप्टेड रूप में स्टोर हो और कभी भी आपकी शेल हिस्ट्री में न आए।

इसके बाद एक वास्तविक संदेश भेजें। एक Sales Invoice बनाएँ, इसे एक ऐसे पते पर ईमेल करें जिसे आप नियंत्रित करते हैं, और ऐसा करते समय कतार (queue) पर नज़र रखें:

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

आउटगोइंग मेल एक बैकग्राउंड जॉब है, इसलिए जो संदेश प्राप्त नहीं होता है, वह आमतौर पर ब्राउज़र में त्रुटि के बजाय उस लॉग में एक विफल जॉब (failed job) के रूप में दिखाई देता है। भेजने वाले डोमेन के लिए SPF (sender policy framework) और DKIM (domainkeys identified mail) रिकॉर्ड प्रकाशित करें, और फिर एक DMARC पॉलिसी जोड़ें। इनके बिना, तकनीकी रूप से सही इनवॉइस भी ग्राहक के स्पैम फ़ोल्डर में चला जाएगा। यदि आप पूरे पाथ को स्वयं नियंत्रित करना चाहते हैं, तो एक self-hosted Mailcow मेल सर्वर आपको एक ऐसा रिले देता है जिसे आप ERP से अलग बॉक्स पर नियंत्रित कर सकते हैं।

ऐसे बैकअप जो वास्तव में रिस्टोर हो सकें

केवल एक database dump ERPNext का पूर्ण बैकअप नहीं है। attachments और private files MariaDB में नहीं, बल्कि sites directory में रहती हैं। यदि आप केवल database को रिस्टोर करते हैं, तो सभी अपलोड किए गए purchase order टूटे हुए लिंक के रूप में दिखाई देंगे।

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

यह कमांड sites वॉल्यूम के अंदर sites/erp.example.com/private/backups में चार फाइलें लिखता है:

• एक -database.sql.gz डंप
• public files का एक -files.tar आर्काइव
• private files का एक -private-files.tar आर्काइव
• site config की एक -site_config_backup.json कॉपी

चौथी फाइल वह है जिसे लोग अक्सर छोड़ देते हैं, और यही सबसे अधिक नुकसान पहुँचाती है। इसमें encryption_key होता है, वह key जिसका उपयोग Frappe संग्रहीत पासवर्ड को encrypt करने के लिए करता है: जैसे email account credentials, payment gateway keys, और सभी integration secrets। यदि आप बिना matching key के database रिस्टोर करते हैं, तो साइट सामान्य रूप से लोड तो हो जाएगी, लेकिन mail भेजने पर यह त्रुटि आएगी:

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

इन चारों फाइलों को हमेशा एक साथ रखें।

इसके बाद इन्हें सर्वर से बाहर निकालें। वॉल्यूम के अंदर रखा गया बैकअप सर्वर के नष्ट होने पर नहीं बचेगा, और bench वैसे भी इसे हटा देता है: डिफ़ॉल्ट रूप से यह उस directory से 24 घंटे से पुराने बैकअप को डिलीट कर देता है।

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

इसे cron से चलाएं, और फिर उस directory को किसी ऐसी जगह भेजें जिसे आप स्वयं manage नहीं करते। encrypted restic backups to off-site storage इसके लिए सही टूल है, क्योंकि यह अपलोड करने से पहले डेटा को encrypt करता है और restic check यह प्रमाणित करता है कि repository अभी भी पढ़ने योग्य है। ERP बैकअप आपके पूरे बही-खाते (ledger) की एक प्रति है, इसलिए इसे किसी अन्य हार्डवेयर पर encrypted अवस्था में रखा जाना चाहिए।

जरूरत पड़ने से पहले restore का परीक्षण करें

बिना परीक्षण किया गया backup केवल एक अनुमान है। इसका परीक्षण उसी मशीन पर किसी दूसरे स्थान (site) पर करें, कभी भी 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>'

Encryption key को backup की गई config से copy करके restore की गई site में डालें, अन्यथा इसके integrations काम नहीं करेंगे:

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

अब restore की जाँच उसी तरह करें जैसे कोई accountant करता है। Accounts Receivable report खोलें और closing balance की तुलना live site से करें। हाल ही का कोई purchase invoice खोलें और उसका attachment download करें। केवल login page का खुल जाना यह साबित नहीं करता कि सब कुछ ठीक है।

काम पूरा होने पर test site को हटा दें:

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

ERPNext के लिए version pinning क्यों अधिक महत्वपूर्ण है

एक static site पर unpinned image tag का मतलब केवल एक अनपेक्षित restart हो सकता है। ERPNext पर इसका मतलब एक schema migration है। bench migrate database tables को rewrite करता है और document data को भी बदल सकता है, और इसमें undo की कोई सुविधा नहीं है। rollback करने का अर्थ है backup से restore करना, न कि कोई docker compose down।

इसलिए tag को pin करें। ERPNEXT_VERSION=v16.32.1 वह release था जिसे अगस्त 2026 में repository के अपने pwd.yml में pin किया गया था। उस नंबर को बिना जाँचे आगे न बढ़ाएं। वर्तमान releases frappe/erpnext releases page पर सूचीबद्ध हैं, और उपलब्ध image tags Docker Hub पर हैं। जिस version पर आप जा रहे हैं, उसके notes को आगे बढ़ने से पहले पढ़ें।

upgrade की प्रक्रिया backup और maintenance mode से शुरू होती है।

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

~/gitops/erpnext.env में ERPNEXT_VERSION को edit करें, फिर render, pull और migrate करें।

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

Maintenance mode महत्वपूर्ण है क्योंकि migrate चलते समय schema को बदल देता है। यदि कोई user आधी-अधूरी migrate हुई table पर document submit करता है, तो आपको records को हाथ से ठीक करना पड़ सकता है।

एक बार में एक ही major version पर आगे बढ़ें, और हर चरण के बीच backup लें। एक release का migration code अपने पिछले release से upgrade करने के लिए लिखा जाता है, इसलिए major versions को छोड़ने (skip करने) से ऐसी migrations चलती हैं जिनका परीक्षण किसी ने नहीं किया है।

यह repository overrides/compose.migrator.yaml भी प्रदान करती है, जो हर start पर bench --site all migrate चलाने वाला एक container जोड़ती है। यह सुविधाजनक है। लेकिन इसका मतलब यह भी है कि बदला हुआ tag वाला docker compose up आपकी production database को बिना किसी निगरानी के migrate कर सकता है। business system पर, migrate चलाने का निर्णय उसी दिन लें।

ग्राहक रिकॉर्ड रखने वाले सर्वर को सुरक्षित बनाना

पहली बार लॉगिन करने पर Administrator पासवर्ड बदलें। evaluation compose file में admin पासवर्ड के रूप में दिया गया है, और लोग अक्सर इसे production में भी इस्तेमाल करते रहते हैं।

DB_PASSWORD को example.env में 123 से बदलें। यह मान रेंडर की गई ~/gitops/erpnext.yaml फाइल में plain text के रूप में आ जाता है, इसलिए फाइल को chmod 600 करें और इसे किसी भी git repository से दूर रखें। अधिक सुरक्षा के लिए, overrides/compose.mariadb-secrets.yaml पासवर्ड को environment variable के बजाय Docker secret फाइल से पढ़ता है। Docker Compose में env फाइलों और secrets को मैनेज करना में इसके फायदे और नुकसान बताए गए हैं।

केवल वही पब्लिश करें जिसकी आवश्यकता है। HTTPS override के साथ, केवल port 80 और 443 ही expose होते हैं। database client से कनेक्शन आसान बनाने के लिए db सर्विस में ports मैपिंग न जोड़ें: ऐसा करने से MariaDB public internet पर आ जाता है। इसके बजाय docker compose --project-name erpnext exec backend bench mariadb का उपयोग करें। होस्ट पर, केवल 22, 80 और 443 को अनुमति दें, बाकी को deny करें, और provider के अलग network firewall की भी जाँच करें।

System Manager role वाले प्रत्येक अकाउंट के लिए System Settings में two factor authentication चालू करें। यह role हर document को पढ़ सकता है और हर table को export कर सकता है, इसलिए इसे एक सुविधा के बजाय administrator अकाउंट की तरह ही मानें। यदि आप कई self-hosted apps चलाते हैं, तो प्रत्येक ऐप के लिए अलग पासवर्ड रखने के बजाय self-hosted single sign-on provider के रूप में Authentik का उपयोग करना बेहतर है।

होस्ट को पैच करें और kernel updates के लिए reboot करें। इस पर निर्भर रहने से पहले कि stack वापस आ जाएगा, प्रत्येक सर्विस पर restart policy के लिए रेंडर की गई फाइल की जाँच करें, क्योंकि इसके बिना stack reboot के बाद बंद ही रहेगा। reboot के बाद Docker Compose stack को दोबारा शुरू करना में systemd के बारे में जानकारी दी गई है।

जब ERPNext एक VPS पर पर्याप्त न रहे

एक VPS लंबे समय तक छोटी कंपनी का काम संभाल सकता है। जब यह क्षमता कम होने लगे, तो ये संकेत मिलते हैं:

• Background jobs जमा होने लगती हैं, जिससे emails और imports मिनटों या घंटों की देरी से पहुँचते हैं।
• docker inspect containers में "OOMKilled": true या exit code 137 दिखाई देता है।
• जो reports दो सेकंड में बनती थीं, उन्हें तीस सेकंड लग रहे हैं और MariaDB वह process है जो CPU का उपयोग कर रही है।
• Backups इतने लंबे चलते हैं कि वे अगली निर्धारित run के साथ overlap होने लगते हैं।

सबसे पहले MariaDB को ऐसे resources दें जिन्हें वह साझा न करे, क्योंकि database और Python workers एक ही memory के लिए प्रतिस्पर्धा करते हैं और buffer pool को अधिक memory की आवश्यकता होती है। एक बड़ा application server उम्मीद से कम मदद करता है। database को Docker में या host पर चलाना इस निर्णय को कवर करता है, और Docker Compose में memory limits सेट करना एक container को दूसरों के संसाधन छीनने से रोकता है, जब तक आप इसे ठीक करते हैं।

इसके बाद, web capacity के बजाय queue workers बढ़ाएं। ERPNext का धीमा काम background का काम है: report generation और bulk imports। अधिक worker containers का खर्च एक बड़े server से कम होता है, और वे उस समस्या को हल करते हैं जिसकी शिकायत उपयोगकर्ता वास्तव में करते हैं।

FAQ

VPS पर ERPNext को कितनी RAM की आवश्यकता होती है?

प्रकाशित मार्गदर्शन 4 GB RAM और 2 vCPU से शुरू होता है, और यह स्तर केवल मूल्यांकन के लिए है। दैनिक उपयोग करने वाली कंपनी के लिए, 8 GB RAM, 4 vCPU और 100 GB SSD की योजना बनाएं। इससे कम होने पर, लोड बढ़ने पर kernel का out of memory killer कंटेनरों को बंद कर देता है, जिसे docker inspect, "OOMKilled": true और exit code 137 के रूप में रिपोर्ट करता है। ये केवल शुरुआती बिंदु हैं, वास्तविक माप नहीं, इसलिए पहले महीने के दौरान अपने memory उपयोग पर नजर रखें।

क्या मैं production में pwd.yml चला सकता हूँ?

नहीं। प्रोजेक्ट का README इसे केवल अल्पकालिक मूल्यांकन के लिए बताता है, और यह भी स्पष्ट करता है कि आप इसमें custom apps इंस्टॉल नहीं कर सकते। MariaDB, Redis और HTTPS overrides के साथ compose.yaml का उपयोग करें, उन्हें docker compose config के साथ एक ही फाइल में रेंडर करें, और फिर उस फाइल को चलाएं।

मेरा ERPNext site बनाने के तुरंत बाद unreachable क्यों है?

Frontend डिफ़ॉल्ट रूप से HTTP Host header से यह चुनता है कि कौन सी site serve करनी है, इसलिए site का नाम browser में मौजूद domain से मेल खाना चाहिए। erpnext के रूप में बनाई गई site erp.example.com पर serve नहीं होती है। या तो domain का उपयोग करके site बनाएं, या env फाइल में FRAPPE_SITE_NAME_HEADER को site के नाम पर सेट करें, compose फाइल को फिर से रेंडर करें और stack को restart करें।

ERPNext backup में क्या होना चाहिए?

चार फाइलें, जिन्हें एक साथ रखा जाना चाहिए: -database.sql.gz डंप, -files.tar और -private-files.tar आर्काइव, और -site_config_backup.json कॉन्फ़िगरेशन कॉपी। bench --site erp.example.com backup --with-files चलाने से ये चारों फाइलें प्राप्त होती हैं। कॉन्फ़िगरेशन कॉपी में encryption_key होता है, इसलिए इसके बिना restore करने पर संग्रहीत integration पासवर्ड डिक्रिप्ट नहीं हो पाएंगे, जो Encryption key is invalid! Please check site_config.json के रूप में सामने आता है।

मैं अपने डेटा को नुकसान पहुँचाए बिना ERPNext को अपग्रेड कैसे करूँ?

--with-files के साथ बैकअप लें, maintenance mode चालू करें, अपनी env फाइल में ERPNEXT_VERSION बदलें, compose फाइल को फिर से रेंडर करें, pull करें, stack को चालू करें, फिर bench --site erp.example.com migrate चलाएं और maintenance mode बंद कर दें। एक बार में केवल एक major version आगे बढ़ें और पहले release notes पढ़ें, क्योंकि migrate बिना किसी undo विकल्प के schema और document डेटा को फिर से लिख देता है। रोलबैक करने का अर्थ है शुरुआत में लिए गए बैकअप को रिस्टोर करना।