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 లో stack ప్రారంభమవుతుంది, కానీ మొదటి import లేదా మొదటి సుదీర్ఘమైన report రన్ చేసినప్పుడు అది ఆగిపోతుంది. ఎందుకంటే తొమ్మిది రన్ అవుతున్న containers, 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 assets ను అందిస్తుంది మరియు మిగిలిన అన్నింటినీ backend కు పంపుతుంది.
• queue-short మరియు queue-long అనేవి RQ (Redis Queue) వర్కర్లు. ఇవి ఇమెయిల్ పంపడం, డేటా ఇంపోర్ట్ చేయడం మరియు రిపోర్టులను తయారు చేయడం వంటి background పనులను నిర్వహిస్తాయి.
• scheduler అనేది సమయానుకూల పనులను (time based jobs) ప్రారంభిస్తుంది, ఇందులో షెడ్యూల్ చేసిన రిపోర్టులు మరియు ఆటో రిపీట్ డాక్యుమెంట్లు ఉంటాయి.
• websocket అనేది బ్రౌజర్‌లో లైవ్ అప్‌డేట్‌ల కోసం పనిచేసే socket.io ప్రాసెస్.
• db అనేది MariaDB.
• redis-cache మరియు redis-queue అనేవి రెండు వేర్వేరు Redis ఇన్‌స్టాన్సులు, ఒకటి cache కోసం మరియు మరొకటి job queue కోసం.

ఈ విభజనను అర్థం చేసుకోవడం ముఖ్యం, ఎందుకంటే ఏ లాగ్‌ను చదవాలో ఇది తెలియజేస్తుంది. ఇమెయిల్ పంపడంలో సమస్య ఉంటే అది queue worker సమస్య, కాబట్టి docker compose logs -f queue-short సరైన కమాండ్. ఒక పేజీ లోడ్ అవుతున్నా నోటిఫికేషన్ బ్యాడ్జ్ అప్‌డేట్ కాకపోతే అది websocket సమస్య. అటువంటప్పుడు backend లాగ్‌లను చదవడం వల్ల సమయం వృథా అవుతుంది.

డెమో ఫైల్స్ కాకుండా ప్రొడక్షన్ కంపోజ్ ఫైల్స్‌తో ఇన్‌స్టాల్ చేయండి

ఈ రిపోజిటరీ pwd.yml ను అందిస్తుంది, మరియు దీని README లో స్పష్టంగా ఇలా ఉంది: "ఈ సెటప్ కేవలం స్వల్పకాలిక మూల్యాంకనం (evaluation) కోసం మాత్రమే ఉద్దేశించబడింది. మీరు ఈ సెటప్‌లో కస్టమ్ యాప్‌లను ఇన్‌స్టాల్ చేయలేరు." 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 పోర్ట్‌ను దానికి మళ్ళిస్తుంది (redirect), మరియు Let's Encrypt నుండి సర్టిఫికేట్‌లను అభ్యర్థిస్తుంది. ఇన్‌వాయిస్ మరియు సెషన్ కుక్కీలు నెట్‌వర్క్‌లో ప్లెయిన్ టెక్స్ట్ రూపంలో వెళ్లకుండా TLS (transport layer security) కాపాడుతుంది.

రెండు విషయాలు నిజమైతేనే సర్టిఫికేట్ జారీ చేయబడుతుంది. erp.example.com కోసం DNS A రికార్డ్ ఇప్పటికే 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 పోర్ట్ కోసం పోటీ పడకుండా ప్రాక్సీని పంచుకోవడానికి సహాయపడుతుంది. ఇలాంటి సర్వర్‌పై ఉండే రెండవ అప్లికేషన్ తరచుగా కస్టమర్లకు సంబంధించినది అయి ఉంటుంది, మరియు self-hosted Chatwoot support desk అదే ప్రాక్సీ వెనుక ఉంటుంది, తద్వారా ఇన్‌వాయిస్‌లపై పనిచేసే వారు కస్టమర్ ఈమెయిల్ మరియు చాట్‌లకు కూడా ఒకే చోట సమాధానం ఇవ్వగలరు.

అవుట్‌బౌండ్ ఈమెయిల్, లేదా ఇన్‌వాయిస్‌లు సర్వర్ నుండి బయటకు వెళ్లకపోవడం

ERPNext గైడ్‌లలో చాలా వరకు ఈ దశను విస్మరిస్తాయి, కానీ సిస్టమ్ ఉపయోగకరంగా ఉంటుందా లేదా అనేది ఇదే నిర్ణయిస్తుంది. అవుట్‌బౌండ్ మెయిల్ పనిచేయకపోతే, కస్టమర్‌కు ఇన్‌వాయిస్ అందదు, పాస్‌వర్డ్ రీసెట్ మెయిల్ రాదు, మరియు షెడ్యూల్ చేసిన రిపోర్టులు డెలివరీ కావు. ఈ స్టాక్‌లో మెయిల్ సర్వర్ ఉండదు.

VPS నుండి నేరుగా port 25 ద్వారా మెయిల్ పంపడానికి ప్రయత్నించకండి. చాలా ప్రొవైడర్లు కొత్త అకౌంట్లపై అవుట్‌బౌండ్ port 25 ను బ్లాక్ చేస్తారు. ఒకవేళ మెయిల్ బయటకు వెళ్లినా, కొత్త VPS అడ్రస్‌కు సెండింగ్ రెప్యుటేషన్ ఉండదు కాబట్టి, అది తిరస్కరించబడుతుంది లేదా స్పామ్‌గా పరిగణించబడుతుంది. port 587 లో authenticated relay ను ఉపయోగించండి.

ERPNext ఇంటర్‌ఫేస్‌లోని Email Account స్క్రీన్ దీనికి మద్దతు ఇచ్చే మార్గం, ఇది పాస్‌వర్డ్‌ను ఎన్‌క్రిప్ట్ చేసి భద్రపరుస్తుంది. మీరు కీలను సైట్ కాన్ఫిగరేషన్‌లో కూడా రాయవచ్చు:

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 ను నంబర్‌గా స్టోర్ చేస్తుంది. ఫైల్‌ను మళ్ళీ చదివి, ఆ రెండు విలువలకు కోట్స్ లేవని నిర్ధారించుకోండి:

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

mail_password ను కమాండ్ లైన్‌లో కాకుండా Email Account స్క్రీన్ ద్వారా సెట్ చేయండి, తద్వారా అది ఎన్‌క్రిప్ట్ చేయబడి ఉంటుంది మరియు మీ షెల్ హిస్టరీలో ఎప్పటికీ కనిపించదు.

ఆ తర్వాత ఒక నిజమైన మెసేజ్‌ను పంపండి. ఒక Sales Invoice ను సృష్టించి, మీకు అందుబాటులో ఉన్న అడ్రస్‌కు ఈమెయిల్ చేయండి, మరియు మీరు అలా చేస్తున్నప్పుడు క్యూను గమనించండి:

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

అవుట్‌గోయింగ్ మెయిల్ అనేది బ్యాక్‌గ్రౌండ్ జాబ్, కాబట్టి మెసేజ్ అందకపోతే అది బ్రౌజర్‌లో ఎర్రర్‌గా కాకుండా, ఆ లాగ్‌లో ఫెయిల్ అయిన జాబ్‌గా కనిపిస్తుంది. పంపే డొమైన్ కోసం SPF (sender policy framework) మరియు DKIM (domainkeys identified mail) రికార్డులను పబ్లిష్ చేయండి, ఆపై DMARC పాలసీని జోడించండి. ఇవి లేకపోతే, సాంకేతికంగా సరైన ఇన్‌వాయిస్ కూడా కస్టమర్ స్పామ్ ఫోల్డర్‌లోకి వెళ్తుంది. మీరు మొత్తం మార్గాన్ని మీ నియంత్రణలో ఉంచుకోవాలనుకుంటే, self-hosted Mailcow మెయిల్ సర్వర్ మీకు ERP నుండి వేరుగా ఉన్న మరొక సర్వర్‌లో నియంత్రణ కలిగిన రిలేను అందిస్తుంది.

నిజంగా పునరుద్ధరించగలిగే బ్యాకప్‌లు

కేవలం డేటాబేస్ డంప్ మాత్రమే ERPNext కు పూర్తి బ్యాకప్ కాదు. అటాచ్‌మెంట్‌లు మరియు ప్రైవేట్ ఫైల్‌లు MariaDB లో కాకుండా sites డైరెక్టరీలో ఉంటాయి. మీరు కేవలం డేటాబేస్‌ను మాత్రమే పునరుద్ధరిస్తే, అప్‌లోడ్ చేసిన ప్రతి పర్చేజ్ ఆర్డర్ బ్రోకెన్ లింక్‌గా మారుతుంది.

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 దీనిని ఉపయోగిస్తుంది. సరిపోలే కీ లేకుండా డేటాబేస్‌ను పునరుద్ధరిస్తే సైట్ సాధారణంగానే లోడ్ అవుతుంది, కానీ మెయిల్ పంపడం విఫలమై ఈ క్రింది ఎర్రర్ వస్తుంది:

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 బ్యాకప్ అనేది మీ మొత్తం లెడ్జర్ యొక్క కాపీ, కాబట్టి ఇది ప్రస్తుతం ఉన్న హార్డ్‌వేర్ కాకుండా వేరే చోట ఎన్‌క్రిప్ట్ చేయబడి ఉండాలి.

మీకు అవసరానికి ముందే restore ప్రక్రియను పరీక్షించండి

పరీక్షించని backup అనేది కేవలం ఒక ఊహ మాత్రమే. దీనిని అదే సర్వర్‌లోని మరొక ప్రదేశంలో పరీక్షించండి, ఎట్టి పరిస్థితుల్లోనూ లైవ్ సైట్‌లో చేయవద్దు.

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 చేసిన కాన్ఫిగరేషన్ నుండి encryption key ని కాపీ చేసి restore చేసిన సైట్‌లోకి ఉంచండి, లేకపోతే దాని 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 ను సరిచూసుకోండి. Accounts Receivable నివేదికను తెరిచి, దాని ముగింపు నిల్వను (closing balance) లైవ్ సైట్‌తో పోల్చండి. ఇటీవల జరిగిన ఒక purchase invoice ను తెరిచి, దానికి జత చేసిన ఫైల్‌ను డౌన్‌లోడ్ చేయండి. కేవలం login పేజీ కనిపిస్తే అది సైట్ సరిగ్గా పనిచేస్తుందని అర్థం కాదు.

పరీక్ష పూర్తయిన తర్వాత test సైట్‌ను తొలగించండి:

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

ERPNext కోసం వెర్షన్ పిన్నింగ్ ఎందుకు ముఖ్యమైనది

స్టాటిక్ సైట్‌లో పిన్ చేయని ఇమేజ్ ట్యాగ్ అంటే ఊహించని రీస్టార్ట్ మాత్రమే. కానీ 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 మీ ప్రొడక్షన్ డేటాబేస్‌ను ఎవరి పర్యవేక్షణ లేకుండానే మైగ్రేట్ చేస్తుంది. బిజినెస్ సిస్టమ్స్‌లో, మైగ్రేషన్ అనేది మీరు ఆ రోజు ఉదయం తీసుకున్న నిర్ణయం ప్రకారం మాత్రమే జరగాలి.

కస్టమర్ రికార్డులను కలిగి ఉన్న సర్వర్‌ను సురక్షితం చేయడం

మొదటిసారి లాగిన్ అయినప్పుడు అడ్మినిస్ట్రేటర్ పాస్‌వర్డ్‌ను మార్చండి. మూల్యాంకన (evaluation) compose ఫైల్ ఆ పాస్‌వర్డ్‌గా adminని కలిగి ఉంటుంది, మరియు ఈ అలవాటును ప్రజలు ప్రొడక్షన్ వరకు కొనసాగిస్తారు.

example.envలోని 123 నుండి DB_PASSWORDని మార్చండి. ఆ విలువ రెండర్ చేయబడిన ~/gitops/erpnext.yamlలో ప్లెయిన్ టెక్స్ట్‌లో కనిపిస్తుంది, కాబట్టి ఫైల్‌ను chmod 600 చేసి, దానిని ఏ git రిపోజిటరీలోనూ ఉంచకండి. మరింత పటిష్టమైన భద్రత కోసం, overrides/compose.mariadb-secrets.yaml ఎన్విరాన్‌మెంట్ వేరియబుల్‌కు బదులుగా Docker సీక్రెట్ ఫైల్ నుండి పాస్‌వర్డ్‌ను చదువుతుంది. 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 చిన్న కంపెనీకి చాలా కాలం పాటు సరిపోతుంది. అది ఇక సరిపోదని చెప్పడానికి సంకేతాలు ఇవే:

• Background jobs పేరుకుపోతాయి, దీనివల్ల emails మరియు imports నిమిషాలు లేదా గంటల ఆలస్యంగా అందుతాయి.
• docker inspect కంటైనర్లు "OOMKilled": true లేదా exit code 137 తో ఆగిపోతాయి.
• రెండు సెకన్లలో పూర్తయ్యే Reports ముప్పై సెకన్లు తీసుకుంటాయి, మరియు CPUని MariaDB ప్రాసెస్ ఆక్రమిస్తుంది.
• Backups పూర్తి కావడానికి పట్టే సమయం, తదుపరి షెడ్యూల్ చేసిన సమయాన్ని దాటిపోతుంది.

ముందుగా MariaDB కి ఇతర వాటితో పంచుకోని వనరులను కేటాయించండి, ఎందుకంటే database మరియు Python workers ఒకే memory కోసం పోటీ పడతాయి మరియు buffer pool కి ఎక్కువ memory అవసరమవుతుంది. అప్లికేషన్ సర్వర్‌ను పెంచడం వల్ల ఆశించినంత ఫలితం ఉండదు. database ను Docker లో లేదా host పై నడపడం ఈ నిర్ణయానికి సంబంధించిన వివరాలను వివరిస్తుంది, మరియు Docker Compose లో memory limits సెట్ చేయడం ఒక కంటైనర్ మిగిలిన వాటిని ఇబ్బంది పెట్టకుండా చూస్తుంది.

ఆ తర్వాత, web capacity ని పెంచే బదులు queue workers ను జోడించండి. ERPNext లో నెమ్మదిగా జరిగే పనులు background పనులు: report generation మరియు bulk imports. పెద్ద సర్వర్ కంటే ఎక్కువ worker కంటైనర్లు తక్కువ ఖర్చుతో కూడుకున్నవి, మరియు వినియోగదారులు ఫిర్యాదు చేసే సమస్యలను ఇవి పరిష్కరిస్తాయి.

FAQ

VPS పై ERPNext నడపడానికి ఎంత RAM అవసరం?

ప్రచురించబడిన మార్గదర్శకాల ప్రకారం 4 GB RAM మరియు 2 vCPU తో ప్రారంభించాలి, అయితే ఈ స్థాయి కేవలం పరిశీలన (evaluation) కోసం మాత్రమే. రోజువారీగా ఉపయోగించే సంస్థల కోసం 8 GB RAM, 4 vCPU మరియు 100 GB SSD ని ప్లాన్ చేసుకోవాలి. దీనికంటే తక్కువ ఉంటే, లోడ్ పెరిగినప్పుడు kernel out of memory killer కంటైనర్లను నిలిపివేస్తుంది. ఇది docker inspect లో "OOMKilled": true గా, exit code 137 తో కనిపిస్తుంది. ఇవి కేవలం ప్రారంభ సూచనలు మాత్రమే, కాబట్టి మొదటి నెలలో మీ సర్వర్ మెమరీ వినియోగాన్ని నిశితంగా గమనించండి.

నేను production లో pwd.yml ని రన్ చేయవచ్చా?

లేదు. ఈ ప్రాజెక్ట్ యొక్క README ప్రకారం ఇది కేవలం స్వల్పకాలిక పరిశీలన కోసం మాత్రమే ఉద్దేశించబడింది మరియు ఇందులో మీరు custom apps ను ఇన్‌స్టాల్ చేయలేరని గమనించండి. MariaDB, Redis మరియు HTTPS overrides తో compose.yaml ని ఉపయోగించండి, docker compose config తో వాటిని ఒకే ఫైల్‌గా render చేసి, ఆ ఫైల్‌ను రన్ చేయండి.

ERPNext సైట్ క్రియేట్ చేసిన వెంటనే ఎందుకు అందుబాటులో ఉండదు?

Frontend డిఫాల్ట్‌గా HTTP Host header ఆధారంగా ఏ సైట్‌ను చూపించాలో నిర్ణయిస్తుంది, కాబట్టి బ్రౌజర్‌లోని డొమైన్ పేరు మరియు సైట్ పేరు ఒకేలా ఉండాలి. erpnext గా క్రియేట్ చేసిన సైట్ erp.example.com వద్ద కనిపించదు. సైట్‌ను డొమైన్ పేరుతోనే క్రియేట్ చేయండి లేదా env ఫైల్‌లో FRAPPE_SITE_NAME_HEADER ని సైట్ పేరుకు సెట్ చేసి, compose ఫైల్‌ను మళ్ళీ render చేసి stack ను restart చేయండి.

ERPNext బ్యాకప్‌లో ఏమేమి ఉండాలి?

నాలుగు ఫైళ్లు కలిపి ఉండాలి: -database.sql.gz dump, -files.tar మరియు -private-files.tar archives, మరియు -site_config_backup.json కాన్ఫిగరేషన్ కాపీ. bench --site erp.example.com backup --with-files రన్ చేయడం ద్వారా ఈ నాలుగూ తయారవుతాయి. కాన్ఫిగరేషన్ కాపీలో encryption_key ఉంటుంది, కాబట్టి అది లేకుండా restore చేస్తే నిల్వ ఉన్న integration పాస్‌వర్డ్‌లను decrypt చేయడం సాధ్యం కాదు, ఇది Encryption key is invalid! Please check site_config.json గా కనిపిస్తుంది.

నా డేటా పాడవకుండా ERPNext ని ఎలా అప్‌గ్రేడ్ చేయాలి?

--with-files తో బ్యాకప్ తీసుకోండి, maintenance mode ఆన్ చేయండి, మీ env ఫైల్‌లో ERPNEXT_VERSION ని మార్చండి, compose ఫైల్‌ను మళ్ళీ render చేయండి, pull చేయండి, stack ను అప్‌లోడ్ చేయండి, ఆపై bench --site erp.example.com migrate రన్ చేసి maintenance mode ని ఆఫ్ చేయండి. ఒకసారి ఒక major version మాత్రమే అప్‌గ్రేడ్ చేయండి మరియు ముందుగా release notes చదవండి, ఎందుకంటే migrate schema మరియు document డేటాను తిరిగి మార్చలేని విధంగా (undo లేకుండా) మారుస్తుంది. వెనక్కి వెళ్లాలంటే (rollback) మీరు ప్రారంభంలో తీసుకున్న బ్యాకప్‌ను restore చేయాల్సి ఉంటుంది.