VPS پر Docker کے ساتھ ERPNext self-host کرنے کا طریقہ

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

VPS پر ERPNext کو self-host کرنا operations کا کام ہے، نہ کہ ایک کمانڈ سے مکمل ہونے والی installation۔ سرکاری Docker Compose stack میں 11 containers شامل ہیں، اور اس میں آپ کا general ledger اور customer records محفوظ ہوتے ہیں۔ اس لیے ذیل کے تمام اقدامات کے لیے معیار بلند ہے: backup اس وقت تک backup نہیں ہوتا جب تک آپ اسے restore نہ کر لیں، اور image tag کو pin نہ کرنا ایسی 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 استعمال کی گئی ہے، جس کی deployment project maintain کرتا ہے۔ ذیل کی ہر command کو August 2026 میں اسی repository کے خلاف check کیا گیا تھا۔ اگر 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
  }
]

شائع شدہ رہنمائی کے مطابق، کسی ایک صارف کے login کرنے سے پہلے ہی کم از کم 2 vCPU اور 4 GB RAM درکار ہوتی ہے۔ یہ evaluation tier ہے۔ یہ صرف ابتدائی حدود ہیں، اس guide کی پیمائشیں نہیں، اور اصل ضرورت آپ کے document volume کا تعین کرتی ہے۔ آخری row کسی صورت شائع شدہ minimum نہیں ہے۔ یہ تقریباً وہ سطح ہے جہاں memory ایسی چیز نہیں رہتی جس کے بارے میں آپ کو مسلسل سوچنا پڑے۔

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

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

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

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

• backend gunicorn کے تحت Frappe application چلاتا ہے۔ bench اسی میں موجود ہے۔
• frontend nginx ہے۔ یہ static assets فراہم کرتا ہے اور باقی تمام درخواستیں 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 worker میں ہے، اس لیے docker compose logs -f queue-short درست command ہے۔ اگر page load ہو جائے لیکن notification badge کبھی update نہ ہو تو مسئلہ websocket میں ہے۔ دونوں میں سے کسی کے لیے backend کے logs پڑھنا وقت ضائع کرتا ہے۔

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

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

db کے start ہونے اور configurator کے exit ہونے کا انتظار کریں۔ اس میں چند seconds لگتے ہیں۔ پھر 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 کے ساتھ print کرنا چاہیے۔ صحت مند ps میں running state کی نو services دکھائی دیتی ہیں اور کوئی بھی restarting میں نہیں ہوتی۔

یہاں دو مسائل اکثر پیش آتے ہیں۔ 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 پر قابل رسائی نہیں ہوتی، اگرچہ دونوں موجود ہوں۔ اوپر کی طرح 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 traffic پر plain text میں منتقل ہونے سے محفوظ رکھتا ہے۔

Certificate جاری ہونے کے لیے 2 باتیں درست ہونا ضروری ہیں۔ erp.example.com کا DNS A record پہلے ہی VPS کی طرف point ہونا چاہیے۔ ports 80 اور 443 انٹرنیٹ سے 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 کیا جائے۔ ایسے server پر دوسری app اکثر customers کے لیے ہوتی ہے، اور self-hosted Chatwoot support desk اسی proxy کے پیچھے چلتا ہے، اس لیے invoices پر کام کرنے والے لوگ customer email اور chat کا جواب بھی ایک ہی جگہ سے دے سکتے ہیں۔

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

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

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

Supported طریقہ 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

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

ایسے بیک اپ جو واقعی بحال ہو سکیں

صرف 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 میں چار files لکھتا ہے:

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

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

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

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

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

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

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

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

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

encrypted config سے encryption key 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 کریں۔ جس 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 تھا جسے repository کی اپنی pwd.yml میں August 2026 میں pin کیا گیا تھا۔ تصدیق کیے بغیر اس number کو آگے استعمال نہ کریں۔ موجودہ 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 میں ترمیم کریں، پھر 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 نصف مکمل migration والی 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 تبدیل کریں۔ evaluation compose file میں admin بطور password موجود ہوتا ہے، اور لوگ یہ عادت production میں بھی لے جاتے ہیں۔

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

صرف وہی چیز publish کریں جس کی ضرورت ہو۔ HTTPS override کے ساتھ صرف ports 80 اور 443 expose ہوتے ہیں۔ database client کو آسانی سے connect کرانے کے لیے 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 Settings میں ہر ایسے account کے لیے two factor authentication فعال کریں جس کے پاس System Manager role ہو۔ یہ role ہر document پڑھ اور ہر table export کر سکتا ہے، اس لیے اسے سہولت کے بجائے administrator account سمجھیں۔ اگر آپ متعدد self-hosted apps چلاتے ہیں تو self-hosted single sign-on provider کے طور پر Authentik ہر app کے لیے ایک اضافی password رکھنے سے بہتر ہے۔

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

ایک VPS پر ERPNext کب مزید آسانی سے نہیں چلتا

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

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

سب سے پہلے MariaDB کو ایسے resources دیں جو اس کے ساتھ share نہ ہوں، کیونکہ 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

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

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

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

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

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

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

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

چار فائلیں ایک ساتھ رکھیں: -database.sql.gz dump، -files.tar اور -private-files.tar archives، اور -site_config_backup.json config copy۔ bench --site erp.example.com backup --with-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 فائل میں ERPNEXT_VERSION تبدیل کریں، compose فائل دوبارہ render کریں، images pull کریں، stack شروع کریں، پھر bench --site erp.example.com migrate چلائیں اور maintenance mode بند کر دیں۔ ہر بار صرف ایک major version آگے جائیں اور پہلے release notes پڑھیں، کیونکہ migrate schema اور document data کو دوبارہ لکھتا ہے اور اسے واپس کرنے کا کوئی طریقہ نہیں ہوتا۔ Rollback کے لیے آغاز میں لیا گیا backup restore کریں۔