VPS वर Docker वापरून ERPNext कसे इन्स्टॉल करावे

तुम्ही काय चालवणार आहात

VPS वर ERPNext self-host करणे हे एक ऑपरेशन्सचे काम आहे, केवळ एका कमांडने होणारे इन्स्टॉलेशन नाही. अधिकृत Docker Compose स्टॅक मध्ये अकरा कंटेनर्स आहेत आणि त्यात तुमचा जनरल लेजर (general ledger) आणि ग्राहकांचे रेकॉर्ड्स असतात. यामुळे खालील सर्व गोष्टींसाठी मानके वाढतात: जोपर्यंत तुम्ही बॅकअप रिस्टोर करून पाहत नाही, तोपर्यंत तो बॅकअप नसतो आणि अनपिन (unpinned) केलेले इमेज टॅग म्हणजे कधीही होऊ शकणारे स्कीमा मायग्रेशन आहे.

या मार्गदर्शिकेत काही नावे वारंवार येतील. ERPNext हे बिझनेस ॲप्लिकेशन आहे. Frappe हे त्याखालील Python फ्रेमवर्क आहे. Bench हे कमांड लाईन टूल आहे जे साइट्सचे व्यवस्थापन करते आणि ते आधीच कंटेनर्समध्ये इन्स्टॉल केलेले असते. एक site म्हणजे एक टेनंट: एक MariaDB डेटाबेस आणि अपलोड केलेल्या फाइल्सची एक डिरेक्टरी. येथील जवळजवळ प्रत्येक कमांड bench ही backend कंटेनरच्या आत एका विशिष्ट साइटसाठी चालवली जाते.

हे मार्गदर्शक frappe_docker रिपॉझिटरीचा वापर करते, जी या प्रकल्पाद्वारे राखली जाणारी डिप्लॉयमेंट आहे. खालील प्रत्येक कमांड ऑगस्ट 2026 मध्ये त्या रिपॉझिटरीच्या संदर्भात तपासली गेली आहे. जर Docker Compose तुमच्यासाठी नवीन असेल, तर VPS वर Docker Compose चालवणे या विषयावर या मार्गदर्शिकेसाठी आवश्यक असलेली पूर्वतयारी दिली आहे.

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 आहे. हे स्टॅटिक ॲसेट्स सर्व्ह करते आणि इतर सर्व विनंत्या बॅकएंडकडे पाठवते.
• 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 चे लॉग वाचण्यात वेळ घालवणे निरर्थक आहे.

डेमो फाईल्सऐवजी प्रोडक्शन कंपोज फाईल्ससह इन्स्टॉल करा

या रिपॉझिटरीमध्ये pwd.yml समाविष्ट आहे आणि README मध्ये त्याबद्दल स्पष्टपणे नमूद केले आहे: "ही सेटअप केवळ अल्पकालीन मूल्यमापनासाठी आहे. तुम्ही या सेटअपवर कस्टम ॲप्स इन्स्टॉल करू शकणार नाही." याचा वापर 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

आता एक कंपोज फाईल रेंडर करा आणि त्यानंतर ती सुरू करा.

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 पर्यंत मर्यादित असलेला डेटाबेस युजर तिथून लॉग इन करू शकत नाही. त्यानंतर साईट निर्मिती MariaDB ॲक्सेस डिनाइड एररसह अयशस्वी होते, ज्यामध्ये root युजरचे नाव येते. % स्कोप नवीन साईटच्या युजरला त्या खाजगी नेटवर्कवरील कोणत्याही होस्टवरून ॲक्सेस देतो.

दुसरी गोष्ट म्हणजे साईटचे नाव. फ्रंटएंड डीफॉल्टनुसार HTTP Host हेडरवरून कोणती साईट सर्व्ह करायची हे निवडते, त्यामुळे erpnext म्हणून तयार केलेली साईट erp.example.com वर पोहोचण्यायोग्य नसते, जरी दोन्ही अस्तित्वात असल्या तरीही. साईटला डोमेनचे नाव द्या, जसे वर दिले आहे, किंवा env फाईलमध्ये FRAPPE_SITE_NAME_HEADER ला साईटच्या नावाने सेट करा आणि कंपोज फाईल पुन्हा रेंडर करा.

HTTPS आणि ते कार्यन्वित होण्यापूर्वी आवश्यक अटी

compose.https.yaml ओव्हरराइड Traefik ला पोर्ट 443 वर चालवते, पोर्ट 80 वरील ट्रॅफिक तिथे रिडायरेक्ट करते आणि Let's Encrypt कडून प्रमाणपत्रे मिळवते. TLS (transport layer security) मुळे इनव्हॉइस आणि सेशन कुकीज नेटवर्कवर प्लेन टेक्स्ट स्वरूपात उघड होत नाहीत.

दोन गोष्टी पूर्ण झाल्याशिवाय कोणतेही प्रमाणपत्र जारी केले जात नाही. erp.example.com साठीचा DNS A record आधीच VPS कडे निर्देशित असावा. पोर्ट 80 आणि 443 इंटरनेटवरून प्रवेशयोग्य असावेत, कारण Let's Encrypt पोर्ट 80 वर HTTP-01 चॅलेंजद्वारे तुम्ही त्या डोमेनचे नियंत्रण करत आहात याची खात्री करते. तुमच्या सर्व्हरवरील फायरवॉलसोबतच तुमच्या क्लाउड प्रोव्हायडरची नेटवर्क फायरवॉलही तपासा. ही दोन्ही स्वतंत्र नियंत्रणे आहेत आणि अनेकदा लोक पॅनेल फायरवॉल तपासण्यास विसरतात.

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

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

ERPNext च्या बहुतेक मार्गदर्शिकांमध्ये ही पायरी वगळली जाते, आणि सिस्टिम उपयुक्त ठरेल की नाही हे याच पायरीवर अवलंबून असते. आउटबाउंड मेल कार्यरत नसल्यास, कोणतेही इनव्हॉइस ग्राहकापर्यंत पोहोचत नाही, पासवर्ड रिसेटची लिंक मिळत नाही आणि नियोजित रिपोर्टही पाठवले जात नाहीत. या स्टॅकमध्ये स्वतःचा मेल सर्व्हर नसतो.

VPS वरून थेट पोर्ट 25 द्वारे मेल पाठवण्याचा प्रयत्न करू नका. बहुतेक प्रोव्हायडर नवीन अकाउंट्ससाठी आउटबाउंड पोर्ट 25 ब्लॉक करतात. तसेच, नवीन VPS पत्त्याची कोणतीही 'sending reputation' नसल्यामुळे, जे काही मेल बाहेर जातात ते नाकारले जातात किंवा स्पॅम म्हणून वर्गीकृत केले जातात. पोर्ट 587 वर ऑथेंटिकेटेड रिले (authenticated relay) वापरा.

यासाठी 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 mail server तुम्हाला ERP पासून वेगळ्या बॉक्सवर एक रिले प्रदान करतो, ज्यावर तुमचे पूर्ण नियंत्रण असते.

बॅकअप जे खरोखर रिस्टोर होतात

केवळ डेटाबेस डंप म्हणजे ERPNext चा बॅकअप नव्हे. अटॅचमेंट्स आणि खाजगी फाइल्स MariaDB मध्ये नसून sites डिरेक्टरीमध्ये असतात. फक्त डेटाबेस रिस्टोर केल्यास प्रत्येक अपलोड केलेली खरेदी ऑर्डर (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 डंप
• पब्लिक फाइल्सची एक -files.tar अर्काइव्ह
• खाजगी फाइल्सची एक -private-files.tar अर्काइव्ह
• साइट कॉन्फिगची एक -site_config_backup.json प्रत

चौथी फाइल लोक सहसा दुर्लक्षित करतात आणि तीच सर्वात महत्त्वाची असते. यामध्ये encryption_key असते, जी Frappe साठवलेले पासवर्ड एनक्रिप्ट करण्यासाठी वापरते: ईमेल अकाउंट क्रेडेंशियल्स, पेमेंट गेटवे कीज आणि प्रत्येक इंटिग्रेशन सीक्रेट. जुळणारी की (key) नसताना डेटाबेस रिस्टोर केल्यास साइट लोड होईल, परंतु ईमेल पाठवताना खालील त्रुटी येईल:

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

या चारही फाइल्स नेहमी एकत्र ठेवा.

त्यानंतर त्या सर्व्हरवरून बाहेर काढा. व्हॉल्यूममधील बॅकअप सर्व्हरच्या अपयशातून वाचू शकत नाही आणि bench स्वतःहून ते काढून टाकते: डीफॉल्टनुसार, ते त्या डिरेक्टरीमधील 24 तासांपेक्षा जुने बॅकअप डिलीट करते.

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

हे cron द्वारे चालवा आणि त्यानंतर ती डिरेक्टरी अशा ठिकाणी पाठवा जिथे तुमचे प्रशासन नाही. ऑफ-साइट स्टोरेजवर एनक्रिप्टेड restic बॅकअप हे यासाठी योग्य साधन आहे, कारण ते अपलोड करण्यापूर्वी डेटा एनक्रिप्ट करते आणि restic check हे रिपॉझिटरी वाचनीय असल्याची खात्री देते. ERP बॅकअप म्हणजे तुमच्या संपूर्ण लेजरची प्रत असते, त्यामुळे ती या हार्डवेअरव्यतिरिक्त इतर सुरक्षित हार्डवेअरवर एनक्रिप्टेड स्वरूपात असणे आवश्यक आहे.

गरज पडण्यापूर्वी रिस्टोरची चाचणी घ्या

ज्या बॅकअपची चाचणी घेतलेली नाही, तो केवळ एक अंदाज असतो. त्याची चाचणी त्याच सर्व्हरवरील दुसऱ्या साईटवर करा, कधीही थेट लाईव्ह साईटवर करू नका.

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) कॉपी करून रिस्टोर केलेल्या साईटमध्ये टाका, अन्यथा तिचे इंटिग्रेशन्स निकामी राहतील:

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

आता एखाद्या अकाउंटंटच्या दृष्टीने रिस्टोरची तपासणी करा. Accounts Receivable रिपोर्ट उघडा आणि क्लोजिंग बॅलन्सची तुलना लाईव्ह साईटशी करा. अलीकडील एखादे खरेदीचे इनव्हॉइस (purchase invoice) उघडा आणि त्यासोबतची अटॅचमेंट डाऊनलोड करा. केवळ लॉगिन पेज दिसते म्हणजे सर्व काही ठीक आहे, असे समजू नका.

चाचणी पूर्ण झाल्यावर टेस्ट साईट काढून टाका:

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

ERPNext साठी व्हर्जन पिनिंग (version pinning) का महत्त्वाचे आहे

एका स्टॅटिक साईटवर अनपिन केलेले इमेज टॅग म्हणजे अचानक होणारा रीस्टार्ट. ERPNext च्या बाबतीत याचा अर्थ स्कीमा मायग्रेशन असा होतो. bench migrate डेटाबेस टेबल्स पुन्हा लिहिते आणि डॉक्युमेंट डेटा देखील बदलू शकते, ज्याला पूर्ववत (undo) करण्याचा कोणताही मार्ग नाही. अशा वेळी रोलबॅक करणे म्हणजे बॅकअपमधून रिस्टोर करणे होय, केवळ docker compose down करणे नव्हे.

त्यामुळे टॅग पिन करा. ऑगस्ट 2026 मध्ये रिपॉझिटरीच्या स्वतःच्या pwd.yml मध्ये ERPNEXT_VERSION=v16.32.1 हे रिलीज पिन केलेले होते. ते क्रमांक तपासल्याशिवाय पुढे वापरू नका. सध्याचे रिलीज frappe/erpnext releases page वर सूचीबद्ध आहेत आणि उपलब्ध इमेज टॅग Docker Hub वर आहेत. तुम्ही ज्या व्हर्जनवर जात आहात, त्याबद्दलच्या नोट्स वाचून घ्या.

अपग्रेडची सुरुवात बॅकअप आणि मेंटेनन्स मोडने होते.

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 संपादित करा, त्यानंतर रेंडर, पुल आणि मायग्रेट करा.

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

मेंटेनन्स मोड महत्त्वाचा आहे कारण migrate चालू असताना स्कीमा बदलत असते. जर एखाद्या वापरकर्त्याने अर्धवट मायग्रेट झालेल्या टेबलवर डॉक्युमेंट सबमिट केले, तर तुम्हाला रेकॉर्ड्स हाताने दुरुस्त करावे लागतील.

एका वेळी एकाच मेजर व्हर्जनवर जा आणि प्रत्येक टप्प्यादरम्यान बॅकअप घ्या. रिलीजमधील मायग्रेशन कोड मागील रिलीजवरून अपग्रेड करण्यासाठी लिहिलेला असतो, त्यामुळे मेजर व्हर्जन वगळल्यास अशा मायग्रेशन्सची अंमलबजावणी होते ज्यांची कोणीही चाचणी केलेली नसते.

रिपॉझिटरी overrides/compose.migrator.yaml देखील पुरवते, जे प्रत्येक स्टार्टवर bench --site all migrate चालवणारा कंटेनर जोडते. हे सोयीचे आहे. परंतु याचा अर्थ असा की, बदललेल्या टॅगसह होणारा docker compose up तुमच्या प्रोडक्शन डेटाबेसचे मायग्रेशन कोणाच्याही देखरेखीशिवाय करेल. बिझनेस सिस्टिमवर, मायग्रेट करण्याचा निर्णय तुम्ही स्वतः त्या दिवशी सकाळी घेणे आवश्यक आहे.

ग्राहक रेकॉर्ड्स असलेल्या सर्व्हरचे सुरक्षितीकरण (Hardening)

पहिल्यांदा लॉगिन केल्यावर Administrator पासवर्ड बदला. इव्हॅल्युएशन compose फाईलमध्ये admin हा पासवर्ड म्हणून दिला जातो आणि ही सवय अनेकदा प्रोडक्शनमध्येही कायम राहते.

example.env मधील 123 वरून DB_PASSWORD बदला. हे मूल्य रेंडर केलेल्या ~/gitops/erpnext.yaml मध्ये प्लेन टेक्स्ट स्वरूपात दिसते, म्हणून फाईलला chmod 600 करा आणि ती कोणत्याही git रिपॉझिटरीमध्ये ठेवू नका. अधिक सुरक्षिततेसाठी, overrides/compose.mariadb-secrets.yaml एनवायरमेंट व्हेरिएबलऐवजी Docker secret फाईलमधून पासवर्ड वाचते. Docker Compose मध्ये env फाईल्स आणि सीक्रेट्स हाताळणे या विषयावर अधिक माहिती दिली आहे.

फक्त आवश्यक तेवढेच पोर्ट्स पब्लिश करा. HTTPS ओव्हरराइडसह, फक्त 80 आणि 443 हे पोर्ट्स उघडे राहतात. डेटाबेस क्लायंटला जोडणी करणे सोपे जावे म्हणून db सर्व्हिसला ports मॅपिंग जोडू नका: यामुळे MariaDB सार्वजनिक इंटरनेटवर उघडे पडते. त्याऐवजी docker compose --project-name erpnext exec backend bench mariadb वापरा. होस्टवर, फक्त 22, 80 आणि 443 पोर्ट्सना परवानगी द्या, बाकी सर्व नाकारा आणि प्रोव्हायडरच्या स्वतंत्र नेटवर्क फायरवॉलचीही तपासणी करा.

System Manager भूमिका असलेल्या प्रत्येक अकाउंटसाठी System Settings मध्ये टू-फॅक्टर ऑथेंटिकेशन सुरू करा. ही भूमिका प्रत्येक दस्तऐवज वाचू शकते आणि प्रत्येक टेबल एक्सपोर्ट करू शकते, त्यामुळे याला सोयीस्कर अकाउंट न मानता ॲडमिनिस्ट्रेटर अकाउंटप्रमाणेच हाताळा. जर तुम्ही अनेक self-hosted ॲप्स चालवत असाल, तर प्रत्येक ॲपसाठी वेगळा पासवर्ड ठेवण्यापेक्षा Authentik ला self-hosted सिंगल साइन-ऑन प्रोव्हायडर म्हणून वापरणे अधिक चांगले आहे.

होस्ट पॅच करा आणि कर्नल अपडेट्ससाठी रीबूट करा. स्टॅक पुन्हा सुरू होईल यावर अवलंबून राहण्यापूर्वी, प्रत्येक सर्व्हिससाठी रेंडर केलेल्या फाईलमध्ये restart पॉलिसी तपासा, कारण पॉलिसी नसलेला स्टॅक रीबूटनंतर बंदच राहतो. रीबूटनंतर Docker Compose स्टॅक पुन्हा सुरू करणे यामध्ये systemd संबंधित माहिती दिली आहे.

जेव्हा ERPNext एका VPS वर अपुरे पडते

एका VPS वर लहान कंपनीचा कारभार बराच काळ चालू शकतो. जेव्हा तो अपुरा पडू लागतो, तेव्हा खालील लक्षणे दिसतात:

• बॅकग्राउंड जॉब्स साचून राहतात, त्यामुळे ईमेल आणि इम्पोर्ट्स काही मिनिटे किंवा तासांनंतर मिळतात.
• docker inspect कंटेनर्समध्ये "OOMKilled": true किंवा exit code 137 असल्याचे दर्शवते.
• जे रिपोर्ट्स दोन सेकंदात तयार व्हायचे, त्यांना आता तीस सेकंद लागतात आणि MariaDB ही प्रक्रिया CPU चा सर्वाधिक वापर करत असते.
• बॅकअपची प्रक्रिया इतका वेळ घेते की ती पुढच्या नियोजित बॅकअपच्या वेळेपर्यंत चालू राहते.

सुरुवातीला MariaDB ला अशी संसाधने द्या जी ती इतर कोणासोबतही शेअर करणार नाही, कारण डेटाबेस आणि Python वर्कर्स एकाच मेमरीसाठी स्पर्धा करतात आणि buffer pool ला अधिक मेमरीची गरज असते. ॲप्लिकेशन सर्व्हर मोठा केल्याने अपेक्षेपेक्षा कमी फायदा होतो. डेटाबेस Docker मध्ये किंवा होस्टवर चालवणे या निर्णयावर मार्गदर्शन करते, आणि Docker Compose मध्ये मेमरी मर्यादा सेट करणे एका कंटेनरला इतरांचे संसाधने संपवण्यापासून रोखते, ज्यामुळे तुम्हाला बदल करण्यासाठी वेळ मिळतो.

त्यानंतर, वेब क्षमतेपेक्षा queue workers वाढवा. ERPNext मधील संथ काम हे बॅकग्राउंडचे काम असते: रिपोर्ट जनरेशन आणि बल्क इम्पोर्ट्स. अधिक वर्कर कंटेनर्स वापरणे हे मोठ्या सर्व्हरपेक्षा स्वस्त पडते आणि वापरकर्त्यांच्या तक्रारींचे मुख्य कारण यामुळे दूर होते.

FAQ

ERPNext ला VPS वर किती RAM ची आवश्यकता असते?

प्रसिद्ध मार्गदर्शक तत्त्वांनुसार, सुरुवातीला 4 GB RAM आणि 2 vCPU ची शिफारस केली जाते, परंतु हा स्तर केवळ मूल्यमापनासाठी (evaluation) आहे. दैनंदिन वापरासाठी, 8 GB RAM, 4 vCPU आणि 100 GB SSD असलेले नियोजन करा. यापेक्षा कमी क्षमतेवर, लोड वाढल्यास कर्नलचा 'out of memory killer' कंटेनर्स बंद करतो, ज्याची नोंद docker inspect मध्ये "OOMKilled": true आणि exit code 137 अशी दिसते. हे केवळ सुरुवातीचे निकष आहेत, त्यामुळे पहिल्या महिन्याभरात तुमच्या सर्व्हरच्या मेमरी वापराचे निरीक्षण करा.

मी production मध्ये pwd.yml वापरू शकतो का?

नाही. प्रकल्पाच्या README मध्ये नमूद केल्याप्रमाणे, हे केवळ अल्पकालीन मूल्यमापनासाठी आहे आणि यात तुम्ही कस्टम ॲप्स इन्स्टॉल करू शकत नाही. त्याऐवजी MariaDB, Redis आणि HTTPS ओव्हरराइड्ससह compose.yaml वापरा, docker compose config वापरून त्यांना एका फाईलमध्ये रेंडर करा आणि ती फाईल रन करा.

ERPNext साईट तयार केल्यानंतर लगेच ती का उघडत नाही?

Frontend डीफॉल्टनुसार HTTP Host हेडरवरून साईट निवडते, त्यामुळे ब्राउझरमधील डोमेन आणि साईटचे नाव जुळणे आवश्यक आहे. erpnext म्हणून तयार केलेली साईट erp.example.com वर उघडणार नाही. एकतर डोमेनच्या नावाने साईट तयार करा किंवा env फाईलमध्ये FRAPPE_SITE_NAME_HEADER सेट करा, त्यानंतर compose फाईल पुन्हा रेंडर करून स्टॅक रीस्टार्ट करा.

ERPNext बॅकअपमध्ये काय असणे आवश्यक आहे?

चार फाईल्स एकत्र असणे आवश्यक आहे: -database.sql.gz डंप, -files.tar आणि -private-files.tar आर्काइव्ह्ज, आणि -site_config_backup.json कॉन्फिगरेशनची प्रत. bench --site erp.example.com backup --with-files रन केल्यावर या चारही फाईल्स तयार होतात. कॉन्फिगरेशनच्या प्रतीमध्ये encryption_key असते, त्यामुळे त्याशिवाय रिस्टोर केल्यास साठवलेले इंटिग्रेशन पासवर्ड्स डिक्रिप्ट करता येत नाहीत, जे Encryption key is invalid! Please check site_config.json म्हणून समोर येते.

डेटा न गमावता ERPNext अपग्रेड कसे करावे?

--with-files वापरून बॅकअप घ्या, मेंटेनन्स मोड सुरू करा, तुमच्या env फाईलमध्ये ERPNEXT_VERSION बदला, compose फाईल पुन्हा रेंडर करा, pull करा, स्टॅक सुरू करा, त्यानंतर bench --site erp.example.com migrate रन करा आणि मेंटेनन्स मोड बंद करा. एका वेळी एकाच मेजर व्हर्जनवर अपडेट करा आणि आधी रिलीज नोट्स वाचा, कारण migrate स्कीमा आणि डॉक्युमेंट डेटा पुन्हा लिहितो (rewrite) जो पूर्ववत करता येत नाही. रोलबॅक करण्याचा एकमेव मार्ग म्हणजे सुरुवातीला घेतलेला बॅकअप रिस्टोर करणे.