VPS پر Docker کے ساتھ ERPNext کیسے چلائیں؟

آپ کس چیز کو چلانے کی ذمہ داری لے رہے ہیں

VPS پر ERPNext کو self-host کرنا operations کا کام ہے، صرف ایک command سے ہونے والی installation نہیں۔ سرکاری Docker Compose stack میں 11 containers شامل ہیں، اور اس میں آپ کا general ledger اور customer records محفوظ ہوتے ہیں۔ اس لیے نیچے دی گئی ہر چیز کے لیے معیار بلند ہے: backup اس وقت تک backup نہیں ہوتا جب تک آپ اسے restore نہ کر لیں، اور unpinned image tag کسی بھی وقت شروع ہونے والی schema migration کا باعث بن سکتا ہے۔

اس guide میں چند نام بار بار آئیں گے۔ 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 کرتا ہے۔ نیچے دی گئی ہر 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 درکار ہوتی ہے۔ یہ جائزے کے درجے کے وسائل ہیں۔ یہ اس رہنما میں کی گئی پیمائش نہیں بلکہ ابتدائی حدیں ہیں، اور حقیقی ضرورت آپ کے دستاویزات کے حجم سے طے ہوتی ہے۔ آخری قطار کسی صورت شائع شدہ کم از کم ضرورت نہیں ہے۔ یہ تقریباً وہ سطح ہے جہاں memory ایسی چیز نہیں رہتی جس کے بارے میں آپ کو مسلسل سوچنا پڑے۔

چھوٹے plans کے بارے میں خود سے واضح رہیں۔ 1 GB یا 2 GB کا VPS stack شروع کر دے گا، لیکن پہلے import یا پہلے طویل report پر رک جائے گا، کیونکہ نو طویل عرصے تک چلنے والے containers، MariaDB کا buffer pool، اور report تیار کرنے والا Python worker اتنی memory میں سما نہیں سکتے۔ failure تدریجی نہیں ہوتی۔ kernel کا out of memory killer کسی container کو روک دیتا ہے، اور اس پر موجود docker inspect پھر exit code 137 کے ساتھ "OOMKilled": true دکھاتا ہے۔ job کے دوران worker رک جائے تو submitted document کا background work ادھورا رہ جاتا ہے۔

ERPNext روزانہ استعمال کرنے والی کمپنی کے لیے 8 GB RAM، 4 vCPU، اور 100 GB SSD ایک حقیقت پسندانہ کم از کم حد ہے۔ RAM سب سے پہلے ختم ہوتی ہے۔ Disk توقع سے زیادہ تیزی سے بھر جاتی ہے، کیونکہ ہر attachment اور ہر local backup database کے اسی volume پر محفوظ ہوتا ہے۔

گیارہ containers اور ہر ایک کا کام

Stack کے شروع ہونے اور نو containers کے چلنے کے بعد docker compose ps چلائیں۔ مزید دو containers، configurator اور create-site، اپنا کام ایک مرتبہ مکمل کرکے exit ہو جاتے ہیں۔ اسی لیے کل تعداد گیارہ بنتی ہے۔

• backend Frappe application کو gunicorn کے تحت چلاتا ہے۔ bench اسی میں موجود ہے۔
• frontend nginx ہے۔ یہ static assets فراہم کرتا ہے اور باقی تمام requests کو backend تک پہنچاتا ہے۔
• queue-short اور queue-long RQ (Redis Queue) workers ہیں۔ یہ background jobs چلاتے ہیں، جیسے outgoing email، imports اور reports بنانا۔
• scheduler وقت کی بنیاد پر چلنے والی jobs شروع کرتا ہے، جن میں scheduled reports اور auto repeat documents شامل ہیں۔
• websocket browser میں live updates کے پیچھے کام کرنے والا socket.io process ہے۔
• db MariaDB ہے۔
• redis-cache اور redis-queue دو الگ Redis instances ہیں۔ ایک cache کے لیے اور دوسرا job queue کے لیے ہے۔

اس تقسیم کو سمجھنا مفید ہے، کیونکہ اس سے معلوم ہوتا ہے کہ کون سا log پڑھنا ہے۔ اگر email queue میں اٹکی ہوئی ہو تو مسئلہ queue worker کا ہے، اس لیے docker compose logs -f queue-short درست command ہے۔ اگر page load ہو جائے لیکن notification badge کبھی update نہ ہو تو مسئلہ websocket کا ہے۔ دونوں میں سے کسی کے لیے backend logs پڑھنا غیر ضروری وقت ضائع کرتا ہے۔

پروڈکشن compose فائلوں کے ساتھ انسٹال کریں، demo کے ساتھ نہیں

repository میں pwd.yml موجود ہے، اور README اس بارے میں واضح ہے: "یہ setup صرف مختصر مدتی جائزے کے لیے ہے۔ آپ اس setup میں 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 کھولیں اور چار values تبدیل کریں۔ 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 فائل render کریں، پھر اسے 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 کے ساتھ merge کرتا ہے اور نتیجہ اس طرح print کرتا ہے کہ ہر variable پہلے ہی substitute ہو چکا ہوتا ہے۔ اس کے بعد rendered فائل چلائیں۔ یہ اضافی مرحلہ مفید ہے: چلنے والا stack ایک ایسی فائل ہوتا ہے جسے آپ پڑھ اور commit کر سکتے ہیں، اس لیے جب کوئی env فائل میں ترمیم کرے یا آپ repository pull کریں تو یہ آپ کی اجازت کے بغیر تبدیل نہیں ہوتا۔ متعدد Docker Compose فائلیں کیسے merge ہوتی ہیں override rules کی تفصیل بیان کرتا ہے۔

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

اسے check کریں:

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 کے ساتھ print کرنا چاہیے۔ ایک درست حالت والا ps، running state میں نو services دکھاتا ہے اور restarting میں کوئی service نہیں ہوتی۔

یہاں اکثر دو مسائل پیش آتے ہیں۔ Docker کے تحت --mariadb-user-host-login-scope=% اختیاری نہیں ہے۔ app container، Docker network کے ذریعے MariaDB تک پہنچتا ہے، اس لیے MariaDB اسے remote host سمجھتا ہے، اور localhost تک محدود database user وہاں سے login نہیں کر سکتا۔ اس کے بعد site creation ناکام ہو جاتی ہے اور MariaDB access denied error میں root user کا نام آتا ہے۔ % scope نئی site کے user کو اس private network کے کسی بھی host سے access دیتا ہے۔

دوسرا مسئلہ site name کا ہے۔ frontend، default طور پر HTTP Host header سے طے کرتا ہے کہ کون سی site serve کرنی ہے۔ اس لیے erpnext کے نام سے بنائی گئی site، erp.example.com پر reachable نہیں ہوتی، اگرچہ دونوں موجود ہوں۔ اوپر کی طرح site کا نام domain کے مطابق رکھیں، یا env فائل میں FRAPPE_SITE_NAME_HEADER کو site name پر set کریں اور compose فائل دوبارہ render کریں۔

HTTPS، اور اس کے کام کرنے سے پہلے کیا درست ہونا ضروری ہے

compose.https.yaml override، Traefik کو port 443 پر چلاتا ہے، port 80 کو اس کی طرف redirect کرتا ہے، اور Let's Encrypt سے certificates طلب کرتا ہے۔ TLS (transport layer security) invoice اور session cookie کو network پر plain text میں منتقل ہونے سے محفوظ رکھتا ہے۔

Certificate جاری ہونے کے لیے دو باتیں درست ہونا ضروری ہیں۔ erp.example.com کا DNS A record پہلے سے VPS کی طرف point کرنا چاہیے۔ Ports 80 اور 443 internet سے reachable ہونے چاہییں، کیونکہ Let's Encrypt port 80 پر HTTP-01 challenge کے ذریعے یہ ثابت کرتا ہے کہ آپ اس نام کو control کرتے ہیں۔ اپنے provider کا network firewall بھی چیک کریں اور server پر موجود firewall بھی۔ یہ الگ controls ہیں، اور panel firewall اکثر نظرانداز ہو جاتا ہے۔

Certificates، cert-data volume میں /letsencrypt/acme.json پر محفوظ ہوتے ہیں۔ اگر browser آپ کے certificate کے بجائے default certificate دکھائے تو docker compose --project-name erpnext ps میں proxy service کا نام تلاش کریں اور اس کے logs میں ACME (automatic certificate management environment) error پڑھیں۔ کیا اسی server پر دوسری web apps بھی چل رہی ہیں؟ متعدد Docker Compose apps کے سامنے ایک Traefik instance میں بتایا گیا ہے کہ port 443 پر قبضے کی کشمکش کے بجائے proxy کو کیسے share کیا جائے۔

بیرونی ای میل، ورنہ invoices سرور سے باہر نہیں جائیں گے

یہ وہ مرحلہ ہے جسے زیادہ تر ERPNext guides چھوڑ دیتے ہیں، حالانکہ نظام کے مفید ہونے کا فیصلہ اسی سے ہوتا ہے۔ بیرونی ای میل درست طور پر کام نہ کرے تو کوئی invoice customer تک نہیں پہنچتا، password reset موصول نہیں ہوتا، اور scheduled report بھی فراہم نہیں ہوتی۔ اس stack میں mail server شامل نہیں ہے۔

VPS سے port 25 پر براہِ راست mail بھیجنے کی کوشش نہ کریں۔ زیادہ تر providers نئے accounts پر outbound port 25 کو block کر دیتے ہیں۔ جو mail باہر نکل بھی جائے، اسے اکثر reject کر دیا جاتا ہے یا spam میں بھیج دیا جاتا ہے، کیونکہ نئے VPS address کی sending reputation نہیں ہوتی۔ port 587 پر authenticated relay استعمال کریں۔

تجویز کردہ طریقہ ERPNext interface میں موجود Email Account screen ہے۔ یہ password کو encrypted حالت میں محفوظ کرتی ہے۔ آپ 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" کی string کے بجائے number کے طور پر محفوظ کرتا ہے۔ فائل دوبارہ پڑھیں اور تصدیق کریں کہ ان دونوں values کے گرد quotes موجود نہ ہوں:

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

mail_password کو command line کے بجائے Email Account screen کے ذریعے set کریں، تاکہ یہ encrypted حالت میں محفوظ ہو اور آپ کی shell history میں کبھی شامل نہ ہو۔

اب ایک حقیقی message بھیجیں۔ Sales Invoice بنائیں، اسے اپنے زیرِ اختیار کسی address پر email کریں، اور اسی دوران queue کو monitor کریں:

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

بیرونی mail ایک background job ہے۔ اس لیے جو message کبھی موصول نہ ہو، وہ عموماً browser میں error کے بجائے اس log میں failed job کے طور پر نظر آتا ہے۔ sending domain کے لیے SPF (sender policy framework) اور DKIM (domainkeys identified mail) records بھی publish کریں، پھر DMARC policy شامل کریں۔ ان records کے بغیر درست طور پر تیار کیا گیا invoice بھی customer کے spam folder میں پہنچ سکتا ہے۔ اگر آپ مکمل mail path خود manage کرنا چاہتے ہیں تو self-hosted Mailcow mail server آپ کو ایسا relay فراہم کرتا ہے جس کا control آپ کے پاس ہوتا ہے، اور اسے ERP سے الگ box پر چلایا جا سکتا ہے۔

وہ بیک اپ جو واقعی restore ہو

صرف database dump، ERPNext کا مکمل بیک اپ نہیں ہوتا۔ Attachments اور private files، MariaDB میں نہیں بلکہ sites directory میں موجود رہتی ہیں۔ صرف database restore کرنے سے ہر upload کیا گیا purchase order broken link بن کر واپس آتا ہے۔

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

یہ command sites volume کے اندر sites/erp.example.com/private/backups میں چار files لکھتی ہے:

• -database.sql.gz dump
• public files کا -files.tar archive
• private files کا -private-files.tar archive
• site config کی -site_config_backup.json copy

چوتھی file وہ ہے جسے لوگ عموماً ضائع کر دیتے ہیں، اور نقصان بھی اسی سے ہوتا ہے۔ اس میں encryption_key موجود ہوتا ہے۔ Frappe stored passwords کو encrypt کرنے کے لیے یہی key استعمال کرتا ہے: email account credentials، payment gateway keys، اور ہر integration secret۔ matching key کے بغیر database restore کریں تو site معمول کے مطابق load ہو جاتی ہے، لیکن mail بھیجنا ناکام ہو جاتا ہے:

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

چاروں files کو ہمیشہ ایک ساتھ رکھیں۔

اس کے بعد انہیں server سے باہر منتقل کریں۔ volume کے اندر موجود backup، server کے خراب ہونے سے محفوظ نہیں رہتا، اور bench اسے ویسے بھی prune کر دیتا ہے: default طور پر یہ اس directory سے 24 hours سے پرانے backups delete کر دیتا ہے۔

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

اس command کو cron سے چلائیں، پھر directory کو ایسی جگہ push کریں جس کا انتظام آپ خود نہ کرتے ہوں۔ encrypted restic backups کو off-site storage پر اس کام کے لیے درست tool ہے، کیونکہ یہ upload سے پہلے data encrypt کرتا ہے، اور restic check ثابت کرتا ہے کہ repository اب بھی readable ہے۔ ERP backup آپ کے پورے ledger کی copy ہوتا ہے، اس لیے اسے at-rest encrypted حالت میں ایسے hardware پر رکھیں جو یہ server نہ ہو۔

ضرورت پڑنے سے پہلے restore کی جانچ کریں

جس backup کی جانچ نہ کی گئی ہو، وہ صرف ایک اندازہ ہے۔ اسے اسی سرور پر ایک دوسری site میں restore کر کے آزمائیں، 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>'

backup شدہ configuration سے encryption key کو restored site میں copy کریں، ورنہ اس کے 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 رپورٹ کھولیں اور closing balance کا live site سے موازنہ کریں۔ حالیہ purchase invoice کھولیں اور اس کی attachment download کریں۔ ایسی site کا 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 کو دوبارہ لکھتا ہے اور document data بھی تبدیل کر سکتا ہے، جبکہ اسے واپس کرنے کا کوئی طریقہ نہیں ہوتا۔ Rollback کا مطلب backup سے restore کرنا ہے، نہ کہ docker compose down۔

اس لیے tag کو pin کریں۔ ERPNEXT_VERSION=v16.32.1 وہ release تھا جسے August 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 آدھی migrated table کے خلاف document submit کرے تو records کو دستی طور پر repair کرنا پڑ سکتا ہے۔

ایک وقت میں صرف ایک major version منتقل کریں، اور ہر step سے پہلے backup بنائیں۔ کسی release کا migration code اس سے پچھلے release سے upgrade کے لیے لکھا جاتا ہے، اس لیے major versions چھوڑنے سے ایسی migrations چلتی ہیں جنہیں کسی نے test نہیں کیا ہوتا۔

Repository میں overrides/compose.migrator.yaml بھی شامل ہے، جو ہر start پر bench --site all migrate چلانے والا container شامل کرتا ہے۔ یہ آسان ہے۔ لیکن اس کا مطلب یہ بھی ہے کہ بدلا ہوا tag رکھنے والا docker compose up کسی کی نگرانی کے بغیر production database migrate کر دیتا ہے۔ Business system پر migrate کو اسی صبح کیا گیا باقاعدہ فیصلہ سمجھ کر چلائیں۔

صارف کے ریکارڈ رکھنے والے سرور کو محفوظ بنانا

پہلی بار login کرتے ہی Administrator کا password تبدیل کریں۔ جائزے کے لیے فراہم کی گئی Compose file میں admin بطور password موجود ہے، اور یہ عادت production تک پہنچ جاتی ہے۔

DB_PASSWORD کو example.env میں موجود 123 سے مختلف قدر پر تبدیل کریں۔ یہ قدر rendered ~/gitops/erpnext.yaml میں plain text کے طور پر شامل ہو جاتی ہے، اس لیے file کو chmod 600 کریں اور اسے کسی بھی git repository سے باہر رکھیں۔ زیادہ مضبوط طریقے کے لیے overrides/compose.mariadb-secrets.yaml password کو environment variable کے بجائے Docker secret file سے پڑھتا ہے۔ Docker Compose میں env files اور secrets کا انتظام میں اس کے فوائد اور نقصانات بیان کیے گئے ہیں۔

صرف ضروری ports publish کریں۔ HTTPS override کے ساتھ صرف ports 80 اور 443 expose ہوتے ہیں۔ database client کے لیے connection آسان بنانے کی خاطر db service میں ports mapping شامل نہ کریں؛ اس سے MariaDB public internet پر دستیاب ہو جاتی ہے۔ اس کے بجائے docker compose --project-name erpnext exec backend bench mariadb استعمال کریں۔ host پر 22، 80 اور 443 کی اجازت دیں، باقی کو deny کریں، اور provider کے الگ network firewall کو بھی چیک کریں۔

System Settings میں ہر اس account کے لیے two-factor authentication فعال کریں جس کے پاس System Manager role ہو۔ یہ role ہر document پڑھ سکتا ہے اور ہر table export کر سکتا ہے، اس لیے اسے سہولت کے لیے بنائے گئے account کے بجائے administrator account سمجھیں۔ اگر آپ متعدد self-hosted apps چلاتے ہیں تو self-hosted single sign-on provider کے طور پر Authentik ہر app کے لیے ایک اضافی password رکھنے سے بہتر ہے۔

host کو patch کریں اور kernel updates کے لیے reboot کریں۔ Stack کے دوبارہ شروع ہونے پر انحصار کرنے سے پہلے rendered file میں ہر service کے لیے restart policy کی موجودگی چیک کریں، کیونکہ ایسی policy کے بغیر stack اس reboot کے بعد بند رہے گا۔ reboot کے بعد Docker Compose stack کو دوبارہ شروع کرانا میں systemd سے متعلق طریقہ بیان کیا گیا ہے۔

جب ERPNext ایک VPS پر چلانا آرام دہ نہ رہے

ایک VPS طویل عرصے تک ایک چھوٹی کمپنی کی ضروریات پوری کر سکتا ہے۔ لیکن درج ذیل علامات ظاہر کرتی ہیں کہ اب یہ کافی نہیں رہا:

• Background jobs جمع ہونے لگتی ہیں، اس لیے emails اور imports کئی منٹ یا کئی گھنٹے کی تاخیر سے پہنچتے ہیں۔
• docker inspect، "OOMKilled": true یا exit code 137 کے ساتھ containers کی خرابی رپورٹ کرتا ہے۔
• جو reports پہلے دو seconds میں مکمل ہوتی تھیں، انہیں اب thirty seconds لگتے ہیں، اور MariaDB CPU استعمال کرنے والا process ہوتا ہے۔
• Backups اتنا وقت لیتے ہیں کہ ایک backup اگلی مقررہ run کے ساتھ overlap ہو جاتا ہے۔

سب سے پہلے MariaDB کو ایسے resources دیں جو اسے مشترک طور پر استعمال نہ کرنے پڑیں، کیونکہ database اور Python workers اسی memory کے لیے مقابلہ کرتے ہیں، جبکہ buffer pool کو اضافی memory کی زیادہ ضرورت ہوتی ہے۔ Application server کو بڑا کرنے سے فائدہ عموماً توقع سے کم ہوتا ہے۔ database کو Docker میں یا host پر چلانا اس فیصلے کا احاطہ کرتا ہے، جبکہ Docker Compose میں memory limits مقرر کرنا اس دوران کسی ایک container کو دوسرے containers کے resources ختم کرنے سے روکتا ہے۔

اس کے بعد web capacity بڑھانے کے بجائے queue workers شامل کریں۔ ERPNext کا سست کام background work ہوتا ہے، جس میں report generation اور bulk imports شامل ہیں۔ زیادہ worker containers کی لاگت بڑے server سے کم ہوتی ہے، اور یہ اسی مسئلے کو حل کرتے ہیں جس کی شکایت users عملی طور پر کرتے ہیں۔

FAQ

VPS پر ERPNext کے لیے کتنی RAM درکار ہے؟

شائع شدہ رہنمائی کے مطابق آغاز 4 GB RAM اور 2 vCPU سے ہوتا ہے، لیکن یہ سطح صرف جائزے کے لیے ہے۔ روزانہ استعمال کرنے والی کمپنی کے لیے 8 GB RAM، 4 vCPU اور 100 GB SSD مختص کریں۔ اس سے کم وسائل میں kernel کا out of memory killer load کے دوران containers روک دیتا ہے۔ docker inspect اسے exit code 137 کے ساتھ "OOMKilled": true کے طور پر رپورٹ کرتا ہے۔ یہ اعداد ابتدائی تخمینے ہیں، حتمی پیمائش نہیں۔ اس لیے پہلے ماہ کے دوران اپنی memory usage monitor کریں۔

کیا میں production میں pwd.yml چلا سکتا ہوں؟

نہیں۔ project کی README کے مطابق یہ صرف مختصر مدتی جائزے کے لیے ہے، اور اس میں custom apps install نہیں کی جا سکتیں۔ MariaDB، Redis اور HTTPS overrides کے ساتھ compose.yaml استعمال کریں، انہیں docker compose config کے ذریعے ایک single file میں render کریں، اور وہ file چلائیں۔

site بنانے کے فوراً بعد میری ERPNext site ناقابل رسائی کیوں ہے؟

frontend طے کرتا ہے کہ default طور پر HTTP Host header کی بنیاد پر کون سی site serve کرنی ہے۔ اس لیے site name کا browser میں موجود domain سے match ہونا ضروری ہے۔ erpnext کے طور پر بنائی گئی site کو erp.example.com پر serve نہیں کیا جاتا۔ یا تو domain کو site name کے طور پر استعمال کرتے ہوئے site بنائیں، یا env file میں FRAPPE_SITE_NAME_HEADER کو site name پر set کریں، compose file دوبارہ render کریں، اور stack restart کریں۔

ERPNext backup میں کیا شامل ہونا چاہیے؟

چار files کو ایک ساتھ رکھیں: -database.sql.gz dump، -files.tar اور -private-files.tar archives، اور -site_config_backup.json config copy۔ bench --site erp.example.com backup --with-files چلانے سے یہ چاروں files تیار ہو جاتی ہیں۔ config copy میں encryption_key موجود ہوتا ہے۔ اس کے بغیر restore کرنے پر محفوظ شدہ integration passwords decrypt نہیں کیے جا سکتے، اور نتیجتاً Encryption key is invalid! Please check site_config.json ظاہر ہوتا ہے۔

اپنا data خراب کیے بغیر ERPNext کو کیسے upgrade کروں؟

--with-files کے ذریعے backup لیں، maintenance mode فعال کریں، env file میں ERPNEXT_VERSION تبدیل کریں، compose file دوبارہ render کریں، images pull کریں، stack start کریں، پھر bench --site erp.example.com migrate چلائیں اور maintenance mode بند کر دیں۔ ایک وقت میں صرف ایک major version آگے بڑھیں اور پہلے release notes پڑھیں، کیونکہ migrate schema اور document data کو ایسے تبدیل کرتا ہے جنہیں واپس نہیں کیا جا سکتا۔ Rollback کے لیے آغاز میں لیا گیا backup restore کریں۔