VPS पर Docker के साथ ERPNext कैसे host करें

आप क्या चलाने के लिए साइन अप कर रहे हैं

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 को अगस्त 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 से शुरू होता है, इससे पहले कि कोई भी उपयोगकर्ता लॉग इन करे। यह मूल्यांकन स्तर है। ये शुरुआती बिंदु हैं, न कि इस गाइड से लिए गए माप, और आपके दस्तावेज़ों की वास्तविक संख्या ही सही आवश्यकता तय करती है। अंतिम पंक्ति कोई प्रकाशित न्यूनतम आवश्यकता नहीं है। यह लगभग वह स्तर है जहाँ मेमोरी की चिंता करना बंद हो जाता है।

छोटे प्लान के बारे में स्वयं के प्रति ईमानदार रहें। 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 है। यह स्टेटिक एसेट्स को सर्व करता है और बाकी सभी रिक्वेस्ट को बैकएंड पर भेजता है।
• queue-short और queue-long, RQ (Redis Queue) वर्कर्स हैं। ये बैकग्राउंड जॉब्स जैसे कि ईमेल भेजना, इम्पोर्ट करना और रिपोर्ट तैयार करना संभालते हैं।
• scheduler, समय-आधारित जॉब्स को ट्रिगर करता है, जिसमें निर्धारित रिपोर्ट और ऑटो-रिपीट डॉक्यूमेंट्स शामिल हैं।
• websocket, ब्राउज़र में लाइव अपडेट के लिए जिम्मेदार socket.io प्रोसेस है।
• db, MariaDB है।
• redis-cache और redis-queue, दो अलग-अलग Redis इंस्टेंस हैं, एक कैश के लिए और दूसरा जॉब क्यू के लिए।

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

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

Repository में pwd.yml शामिल है, और README इस बारे में स्पष्ट है: "यह सेटअप केवल अल्पकालिक मूल्यांकन (short-lived evaluation) के लिए है। आप इस सेटअप पर 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 इमेज टैग को पिन करता है। DB_PASSWORD उदाहरण फ़ाइल में 123 के रूप में आता है। SITES_RULE Traefik राउटिंग नियम है, और LETSENCRYPT_EMAIL सर्टिफिकेट चेतावनियाँ प्राप्त करता है।

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

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

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

db के स्टार्ट होने और configurator के एग्जिट होने की प्रतीक्षा करें, जिसमें कुछ सेकंड लगते हैं, फिर साइट बनाएं।

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 प्रिंट करना चाहिए। एक स्वस्थ ps में running स्थिति में नौ सर्विस दिखनी चाहिए और restarting में कोई नहीं।

यहाँ अक्सर दो चीजें गलत हो जाती हैं। Docker के तहत --mariadb-user-host-login-scope=% वैकल्पिक नहीं है। ऐप कंटेनर Docker नेटवर्क के माध्यम से MariaDB तक पहुँचता है, इसलिए यह एक रिमोट होस्ट के रूप में आता है, और localhost तक सीमित डेटाबेस यूजर वहाँ से लॉग इन नहीं कर सकता। साइट निर्माण तब root यूजर के नाम के साथ MariaDB एक्सेस डिनाइड एरर के कारण विफल हो जाता है। % स्कोप नई साइट के यूजर को उस प्राइवेट नेटवर्क पर किसी भी होस्ट से एक्सेस प्रदान करता है।

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

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

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

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

सर्टिफिकेट cert-data वॉल्यूम में /letsencrypt/acme.json पर सेव होते हैं। यदि ब्राउज़र आपके सर्टिफिकेट के बजाय डिफ़ॉल्ट सर्टिफिकेट दिखाता है, तो docker compose --project-name erpnext ps में प्रॉक्सी सर्विस का नाम खोजें और ACME (automatic certificate management environment) त्रुटि के लिए उसके लॉग पढ़ें। क्या आप उसी सर्वर पर अन्य वेब ऐप्स चला रहे हैं? कई Docker Compose ऐप्स के सामने एक Traefik इंस्टेंस दिखाता है कि port 443 के लिए संघर्ष करने के बजाय प्रॉक्सी को कैसे साझा किया जाए। इस तरह के सर्वर पर दूसरा ऐप अक्सर ग्राहकों के लिए होता है, और एक self-hosted Chatwoot सपोर्ट डेस्क उसी प्रॉक्सी के पीछे स्थित होता है, ताकि जो लोग इनवॉइस पर काम करते हैं, वे एक ही जगह से ग्राहकों के ईमेल और चैट का जवाब भी दे सकें।

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

यह वह चरण है जिसे अधिकांश 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 पॉलिसी जोड़ें। इनके बिना, तकनीकी रूप से सही इनवॉइस भी ग्राहक के स्पैम फ़ोल्डर में चला जाएगा। यदि आप पूरे पाथ को स्वयं नियंत्रित करना चाहते हैं, तो एक सेल्फ-होस्टेड Mailcow मेल सर्वर आपको एक ऐसा रिले देता है जिसे आप ERP से अलग बॉक्स पर नियंत्रित कर सकते हैं।

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

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

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

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

• एक -database.sql.gz dump
• public files का एक -files.tar archive
• private files का एक -private-files.tar archive
• site config की एक -site_config_backup.json copy

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

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

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

इसके बाद इन्हें सर्वर से बाहर निकालें। volume के अंदर रखा गया बैकअप सर्वर के नष्ट होने पर नहीं बचेगा, और 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 नहीं करते हैं। off-site storage पर encrypted restic backups इसके लिए सही टूल है, क्योंकि यह upload करने से पहले डेटा को encrypt करता है और restic check यह सुनिश्चित करता है कि repository अभी भी readable है। ERP बैकअप आपके पूरे ledger की एक प्रति है, इसलिए इसे इस हार्डवेयर से अलग किसी अन्य सुरक्षित हार्डवेयर पर encrypted अवस्था में रखा जाना चाहिए।

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

बिना परीक्षण किया गया backup केवल एक अनुमान है। इसका परीक्षण उसी box पर किसी दूसरे 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 करके restored 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 का दिखना यह साबित नहीं करता कि site सही है।

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

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

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

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

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

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

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

सबसे पहले MariaDB को ऐसे संसाधन दें जिन्हें वह साझा न करे, क्योंकि डेटाबेस और Python वर्कर्स एक ही मेमोरी के लिए प्रतिस्पर्धा करते हैं और buffer pool को अधिक मेमोरी की आवश्यकता होती है। एक बड़ा एप्लिकेशन सर्वर लोगों की अपेक्षा से कम मदद करता है। डेटाबेस को Docker या host पर चलाना इस निर्णय के बारे में विस्तार से बताता है, और Docker Compose में मेमोरी लिमिट सेट करना एक कंटेनर को दूसरे कंटेनर के संसाधन छीनने से रोकता है, जब तक आप बदलाव कर रहे हों।

इसके बाद, वेब क्षमता बढ़ाने के बजाय queue workers जोड़ें। ERPNext का धीमा काम background work होता है: रिपोर्ट जनरेशन और बल्क इम्पोर्ट। अधिक वर्कर कंटेनर्स एक बड़े सर्वर की तुलना में सस्ते पड़ते हैं, और वे उन समस्याओं को हल करते हैं जिनकी शिकायत उपयोगकर्ता वास्तव में करते हैं।

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 का नाम ब्राउज़र में मौजूद 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 डेटा को फिर से लिखता है। रोलबैक करने का अर्थ है शुरुआत में लिए गए बैकअप को रिस्टोर करना।