VPS वर Docker वापरून ERPNext कसे होस्ट करावे

तुम्ही कशासाठी साइन अप करत आहात

VPS वर ERPNext स्वतः होस्ट करणे हे एक ऑपरेशन्सचे काम आहे, केवळ एका कमांडने होणारे इन्स्टॉलेशन नाही. अधिकृत Docker Compose स्टॅक अकरा कंटेनर्सचा बनलेला आहे आणि त्यात तुमचा जनरल लेजर आणि ग्राहकांचे रेकॉर्ड्स असतात. यामुळे खालील सर्व गोष्टींसाठी मानके वाढतात: जोपर्यंत तुम्ही बॅकअप रिस्टोर करून पाहत नाही, तोपर्यंत तो बॅकअप मानला जात नाही आणि अनपिन (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 आहे. हे स्थिर (static) ॲसेट्स सर्व्ह करते आणि इतर सर्व विनंत्या बॅकएंडकडे पाठवते.
• queue-short आणि queue-long हे RQ (Redis Queue) वर्कर्स आहेत. हे ईमेल पाठवणे, डेटा इम्पोर्ट करणे आणि रिपोर्ट तयार करणे यांसारखी बॅकग्राउंड कामे करतात.
• scheduler हे वेळेवर आधारित कामे (time based jobs) कार्यान्वित करते, ज्यामध्ये शेड्यूल केलेले रिपोर्ट आणि ऑटो-रिपीट डॉक्युमेंट्सचा समावेश होतो.
• 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 साठी मर्यादित असलेला डेटाबेस युजर तिथून लॉग इन करू शकत नाही. त्यानंतर साईट निर्मिती root युजरचे नाव दर्शविणाऱ्या MariaDB ॲक्सेस डिनाइड एररसह अयशस्वी होते. % स्कोप नवीन साईटच्या युजरला त्या खाजगी नेटवर्कवरील कोणत्याही होस्टवरून ॲक्सेस देतो.

दुसरी गोष्ट म्हणजे साईटचे नाव. फ्रंटएंड डीफॉल्टनुसार 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 instance हे लेख पोर्ट 443 साठी संघर्ष करण्याऐवजी प्रॉक्सी कशी शेअर करावी हे दर्शवते.

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

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

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

ERPNext इंटरफेस मधील Email Account स्क्रीन हा अधिकृत मार्ग आहे, जो पासवर्ड एनक्रिप्ट करून साठवतो. तुम्ही हे कीज (keys) थेट साइट कॉन्फिगरेशनमध्ये देखील लिहू शकता:

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 मधून रन करा आणि त्यानंतर ती डिरेक्टरी अशा ठिकाणी पाठवा जिथे तुमचे प्रशासन नाही. off-site स्टोरेजवर एन्क्रिप्टेड 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) का महत्त्वाचे आहे

एका स्टॅटिक साईटवर अनपिन (unpinned) इमेज टॅगचा अर्थ केवळ अनपेक्षित रीस्टार्ट असा असू शकतो. पण 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 कोणाच्याही देखरेखीशिवाय तुमच्या प्रोडक्शन डेटाबेसचे मायग्रेशन करू शकतो. बिझनेस सिस्टिमवर, मायग्रेट करण्याचा निर्णय तुम्ही स्वतः त्या दिवशी सकाळी घेतला पाहिजे.

ग्राहक रेकॉर्ड्स असलेल्या सर्व्हरचे हार्डनिंग

पहिल्या लॉगिनच्या वेळी 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 ॲप्स चालवत असाल, तर प्रत्येक ॲपसाठी वेगळा पासवर्ड ठेवण्यापेक्षा self-hosted सिंगल साइन-ऑन प्रोव्हायडर म्हणून Authentik वापरणे अधिक चांगले आहे.

होस्ट पॅच करा आणि कर्नल अपडेट्ससाठी रीबूट करा. स्टॅक पुन्हा सुरू होईल यावर अवलंबून राहण्यापूर्वी, प्रत्येक सर्व्हिससाठी रेंडर केलेल्या फाईलमध्ये 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 ची शिफारस केली जाते, परंतु हा स्तर केवळ मूल्यमापनासाठी आहे. दैनंदिन वापरासाठी, 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 वापरून बॅकअप घ्या, maintenance mode सुरू करा, तुमच्या env फाईलमध्ये ERPNEXT_VERSION बदला, compose फाईल पुन्हा रेंडर करा, इमेज पुल करा, स्टॅक अप करा आणि त्यानंतर bench --site erp.example.com migrate रन करून maintenance mode बंद करा. एका वेळी एकाच मुख्य आवृत्तीचे (major version) अपग्रेड करा आणि आधी release notes वाचा, कारण migrate स्कीमा आणि डॉक्युमेंट डेटा पुन्हा लिहिते (rewrite) जे पूर्ववत करता येत नाही. रोलबॅक करण्यासाठी सुरुवातीला घेतलेला बॅकअप रिस्टोर करावा लागतो.