Dockerతో VPSలో ERPNextను self-host చేయడం

మీరు అమలు చేయబోయే వ్యవస్థ గురించి

VPSలో ERPNextను self-host చేయడం operations పని; ఇది ఒకే commandతో పూర్తయ్యే install కాదు. అధికారిక Docker Compose stackలో పదకొండు containers ఉంటాయి. ఇందులో మీ general ledger మరియు customer records నిల్వ ఉంటాయి. అందువల్ల దిగువన ఉన్న ప్రతి అంశానికి అధిక ప్రమాణం అవసరం: మీరు దాన్ని restore చేసి నిర్ధారించేవరకు backup నిజమైన backup కాదు. అలాగే pin చేయని image tag ఎప్పుడైనా జరిగే schema migrationకు దారితీయవచ్చు.

ఈ పాఠ్యంలో కొన్ని పేర్లు తరచుగా కనిపిస్తాయి. ERPNext అనేది business application. Frappe దాని క్రింద పనిచేసే Python framework. Bench అనేది sitesను నిర్వహించే command line tool; ఇది containersలో ఇప్పటికే install అయి ఉంటుంది. site అంటే ఒక tenant: ఒక MariaDB databaseతో పాటు upload చేసిన files ఉన్న ఒక directory. ఇక్కడి దాదాపు ప్రతి command bench ను backend containerలో, పేరుతో పేర్కొన్న ఒక siteపై అమలు చేస్తుంది.

ఈ guideలో frappe_docker repository ఉపయోగించబడుతుంది. ఇదే project నిర్వహించే deployment. దిగువన ఉన్న ప్రతి commandను August 2026లో ఆ repositoryతో తనిఖీ చేశాం. Docker Compose మీకు కొత్తదైతే, ఈ guide ఆధారపడే ప్రాథమిక అంశాలను 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
  }
]

ఒక వినియోగదారు కూడా login చేయకముందే 2 vCPU మరియు 4 GB RAM తో ప్రారంభించాలని ప్రచురిత మార్గదర్శకాలు సూచిస్తున్నాయి. ఇది evaluation tier. ఇవి ప్రారంభ అంచనాలు మాత్రమే; ఈ guide లో చేసిన కొలతలు కావు. మీ పత్రాల పరిమాణమే వాస్తవ అవసరాన్ని నిర్ణయిస్తుంది. చివరి వరుస ప్రచురిత కనిష్ఠ అవసరం కూడా కాదు. మెమరీ గురించి ప్రత్యేకంగా ఆలోచించాల్సిన అవసరం తగ్గే స్థాయి అది.

చిన్న plans విషయంలో మీతో మీరు నేరుగా ఉండాలి. 1 GB లేదా 2 GB VPS stack ను ప్రారంభిస్తుంది, కానీ మొదటి import లేదా మొదటి ఎక్కువసేపు నడిచే report వద్ద ఆగిపోతుంది. ఎందుకంటే ఎక్కువసేపు నడిచే తొమ్మిది containers, MariaDB యొక్క buffer pool, report ను రూపొందిస్తున్న Python worker — ఇవన్నీ ఆ మెమరీలో సరిపోవు. వైఫల్యం నియంత్రితంగా జరగదు. kernel యొక్క out of memory killer ఒక container ను ఆపుతుంది. దానిపై ఉన్న docker inspect లో exit code 137 తో "OOMKilled": true కనిపిస్తుంది. పని మధ్యలో worker ఆగిపోతే, submit చేసిన document యొక్క background పని సగంలోనే మిగిలిపోతుంది.

ప్రతిరోజూ 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 అవుతాయి. మొత్తం పదకొండు containers లెక్కకు కారణం ఇదే.

• backend gunicorn కింద Frappe అప్లికేషన్‌ను నడుపుతుంది. bench ఇక్కడే ఉంటుంది.
• frontend nginx. ఇది static assets ను అందించి, మిగతా అన్ని అభ్యర్థనలను backend కు పంపుతుంది.
• queue-short మరియు queue-long RQ (Redis Queue) workers. ఇవి outgoing email, imports, report builds వంటి background jobs ను నడుపుతాయి.
• 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 చదవడం వల్ల అవసరం లేని సమయం వృథా అవుతుంది.

production 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 తెరిచి నాలుగు విలువలను మార్చండి. 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 చేసి, దాన్ని ప్రారంభించండి.

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 ఏదీ ప్రారంభించదు. ఇది base file ను overrides తో merge చేసి, ప్రతి variable ను ముందుగానే substitute చేసిన ఫలితాన్ని ముద్రిస్తుంది. తరువాత ఆ rendered file ను run చేయాలి. ఈ అదనపు దశ ఉపయోగకరంగా ఉంటుంది: నడుస్తున్న stack మొత్తం ఒకే ఫైల్‌లో చదవగలిగేలా, commit చేయగలిగేలా ఉంటుంది. అందువల్ల ఎవరైనా env file ను మార్చినప్పుడు లేదా repository ను pull చేసినప్పుడు అది మీకు తెలియకుండా మారదు. అనేక Docker Compose ఫైళ్లు ఎలా merge అవుతాయి override నియమాలను వివరంగా వివరిస్తుంది.

db ప్రారంభమయ్యే వరకు, 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

దీన్ని తనిఖీ చేయండి:

docker compose --project-name erpnext ps
docker compose --project-name erpnext exec backend bench --site erp.example.com list-apps

list-apps, వాటి versionsతో కలిసి frappe మరియు erpnext ను ముద్రించాలి. ఆరోగ్యంగా ఉన్న ps, running stateలో తొమ్మిది services ను చూపించాలి. restarting stateలో ఏదీ ఉండకూడదు.

ఇక్కడ తరచుగా రెండు సమస్యలు వస్తాయి. Dockerలో --mariadb-user-host-login-scope=% తప్పనిసరి. App container Docker network ద్వారా MariaDBని చేరుతుంది. కాబట్టి అది remote hostగా కనిపిస్తుంది. localhost కు పరిమితమైన database user అక్కడి నుంచి login చేయలేడు. అప్పుడు site creation విఫలమై, root user పేరును చూపించే MariaDB access denied error వస్తుంది. % scope, ఆ private networkలోని ఏ host నుంచైనా కొత్త site's userకు access ఇస్తుంది.

రెండవ సమస్య site name. సాధారణంగా frontend, HTTP Host header ఆధారంగా ఏ siteను అందించాలో ఎంచుకుంటుంది. అందువల్ల erpnext గా సృష్టించిన site, రెండూ ఉన్నప్పటికీ erp.example.com వద్ద అందుబాటులో ఉండదు. పై విధంగా domain పేరుతో siteను సృష్టించండి. లేదా env fileలో FRAPPE_SITE_NAME_HEADER ను site nameగా సెట్ చేసి compose fileను మళ్లీ 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 ఎప్పటికీ జారీ కాదు. రెండు విషయాలు తప్పనిసరిగా సరిగ్గా ఉండాలి. erp.example.com కోసం DNS A record ఇప్పటికే VPS వైపు చూపాలి. Port 80 మరియు port 443లను internet నుంచి చేరుకోగలగాలి, ఎందుకంటే Let's Encrypt port 80పై HTTP-01 challenge ద్వారా ఆ domainపై మీ నియంత్రణను నిర్ధారిస్తుంది. మీ provider యొక్క network firewallతో పాటు serverలో ఉన్న firewallను కూడా తనిఖీ చేయండి. అవి వేర్వేరు నియంత్రణలు. Panel firewallను చాలామంది మర్చిపోతారు.

Certificates cert-data volumeలోని /letsencrypt/acme.json వద్ద నిల్వ అవుతాయి. Browser మీ certificate బదులుగా default certificateను చూపిస్తే, docker compose --project-name erpnext psలో proxy service nameను కనుగొని, ACME (automatic certificate management environment) error కోసం దాని logsను పరిశీలించండి. అదే serverలో ఇతర web apps నడుస్తున్నాయా? Port 443పై పరస్పరం పోటీ పడకుండా proxyను share చేయడం గురించి అనేక Docker Compose apps ముందు ఒక Traefik instance వివరిస్తుంది.

బయటికి పంపే email పనిచేయకపోతే invoices ఎక్కడికీ చేరవు

ఇది చాలా ERPNext మార్గదర్శకాలు దాటవేసే దశ. అయితే సిస్టమ్ ఉపయోగకరంగా ఉంటుందా లేదా అనేది దీనిపైనే ఆధారపడి ఉంటుంది. బయటికి పంపే mail పనిచేయకపోతే customer కు invoice చేరదు, password reset message అందదు, scheduled report పంపబడదు. ఈ stack లో mail server ఉండదు.

VPS నుంచి port 25 ద్వారా నేరుగా mail పంపడానికి ప్రయత్నించవద్దు. చాలా providers కొత్త accounts కు outbound port 25 ను block చేస్తాయి. బయటికి వెళ్లిన message కూడా rejected కావచ్చు లేదా 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 గా భద్రపరుస్తుంది. ఆ file ను మళ్లీ చదివి, ఆ రెండు values చుట్టూ quotes లేవని నిర్ధారించండి:

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

mail_password ను command line ద్వారా కాకుండా Email Account screen లో సెట్ చేయండి. అప్పుడు అది encrypted రూపంలో భద్రపరచబడుతుంది. అలాగే అది మీ shell history లోకి ఎప్పటికీ వెళ్లదు.

తర్వాత నిజమైన message పంపండి. Sales Invoice సృష్టించి, మీ నియంత్రణలో ఉన్న address కు email పంపండి. అదే సమయంలో queue ను పరిశీలించండి:

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 జోడించండి. ఇవి లేకపోతే సాంకేతికంగా సరైన invoice అయినప్పటికీ customer spam folder లోకి చేరవచ్చు. మొత్తం మార్గాన్ని మీరే నిర్వహించాలనుకుంటే, self-hosted Mailcow mail server ERP నుంచి వేరే box పై మీ నియంత్రణలో ఉండే relay ను అందిస్తుంది.

నిజంగా restore చేయగల backups

Database dump మాత్రమే ERPNext కు backup కాదు. Attachments మరియు private files MariaDB లో కాకుండా sites directory లో ఉంటాయి. Database ను మాత్రమే restore చేస్తే, upload చేసిన ప్రతి purchase order విరిగిన 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 ను చాలామంది తొలగిస్తారు. కానీ సమస్యకు కారణమయ్యేది అదే. ఇందులో encryption_key ఉంటుంది. Stored passwords ను encrypt చేయడానికి Frappe ఉపయోగించే key ఇదే: email account credentials, payment gateway keys, ప్రతి integration secret. సరిపోలే key లేకుండా database ను restore చేస్తే site సాధారణంగా load అవుతుంది. కానీ mail పంపడం విఫలమవుతుంది:

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

నాలుగు files ను ఎల్లప్పుడూ కలిసి ఉంచండి.

తర్వాత వాటిని server వెలుపలకు పంపండి. Volume లో ఉన్న backup, server విఫలమైతే నిలిచి ఉండదు. bench కూడా వాటిని తొలగిస్తుంది: 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

దీన్ని cron నుంచి run చేసి, మీరు administer చేయని ఏదైనా ప్రదేశానికి directory ను push చేయండి. off-site storage కు encrypted restic backups సరైన tool, ఎందుకంటే ఇది upload కు ముందు encrypt చేస్తుంది మరియు restic check repository ఇప్పటికీ చదవగలిగే స్థితిలో ఉందని నిర్ధారిస్తుంది. ERP backup మీ మొత్తం ledger యొక్క copy. కాబట్టి దాన్ని at rest encryption తో, ఈ server కాకుండా వేరే hardware పై ఉంచాలి.

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

పరీక్షించని backup కేవలం ఒక అంచనా మాత్రమే. దాన్ని అదే box లోని రెండో site కు restore చేసి పరీక్షించండి; live site లోకి ఎప్పుడూ restore చేయవద్దు.

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 చేసిన config లోని 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>'

ఇప్పుడు accountant పరిశీలించే విధంగా restore ను తనిఖీ చేయండి. Accounts Receivable report ను తెరిచి, closing balance ను live site తో పోల్చండి. ఇటీవలి purchase invoice ను తెరిచి, దానికి జత చేసిన attachment ను download చేయండి. login page ను చూపించగలిగే site పనిచేస్తుందని నిరూపించదు.

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

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

ERPNext కోసం version pinning ఎందుకు మరింత ముఖ్యమో

Static siteలో image tagను pin చేయకపోతే అనుకోని restart జరుగుతుంది. ERPNextలో అదే schema migrationకు దారితీస్తుంది. bench migrate database tablesను తిరిగి రాస్తుంది మరియు document dataను కూడా మార్చవచ్చు. దీనికి undo ఉండదు. Rollback అంటే backup నుంచి restore చేయడం, docker compose down కాదు.

కాబట్టి tagను pin చేయండి. 2026 Augustలో repository స్వంత pwd.ymlలో pin చేసిన release ERPNEXT_VERSION=v16.32.1. దాన్ని పరిశీలించకుండా అదే సంఖ్యను తరువాతి కాలానికి ఉపయోగించవద్దు. ప్రస్తుత releases frappe/erpnext releases pageలో ఉన్నాయి. అందుబాటులో ఉన్న image tags Docker Hubలో ఉన్నాయి. మీరు upgrade చేయబోయే 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ను మారుస్తుంది. సగం migration పూర్తయిన tableపై user document submit చేస్తే, recordsను చేతితో సరిచేయాల్సి వస్తుంది.

ఒక్కసారి ఒక major version మాత్రమే మార్చండి. ప్రతి దశ మధ్య backup తీసుకోండి. ఒక releaseలోని migration code, దాని ముందు release నుంచి upgrade చేయడానికి రూపొందించబడుతుంది. కాబట్టి major versionsను దాటితే, ఎవరూ పరీక్షించని కలయికలో migrations అమలవుతాయి.

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 ఆ password గా admin ను ఉపయోగిస్తుంది. అలాంటి అలవాటు production లోకి కూడా వస్తుంది.

example.env లోని 123 విలువకు బదులుగా DB_PASSWORD ను వేరే విలువగా మార్చండి. ఆ విలువ plain text రూపంలో rendered ~/gitops/erpnext.yaml లో కనిపిస్తుంది. అందువల్ల chmod 600 file ను భద్రంగా ఉంచి, ఏ git repository లోనూ చేర్చవద్దు. మరింత బలమైన విధానం కోసం, overrides/compose.mariadb-secrets.yaml password ను environment variable నుంచి కాకుండా Docker secret file నుంచి చదువుతుంది. Docker Compose లో env files మరియు secrets నిర్వహణ లో ఈ విధానాల మధ్య trade-offs వివరించబడ్డాయి.

అవసరమైన ports మాత్రమే publish చేయండి. HTTPS override తో 80 మరియు 443 మాత్రమే బయటకు expose అవుతాయి. Database client కనెక్ట్ కావడం సులభం చేయడానికి db service కు ports mapping జోడించవద్దు. అలా చేస్తే MariaDB public internet లోకి తెరుచుకుంటుంది. దాని బదులుగా docker compose --project-name erpnext exec backend bench mariadb ను ఉపయోగించండి. Host పై 22, 80 మరియు 443 ను అనుమతించండి. మిగిలిన వాటిని నిరాకరించండి. Provider యొక్క ప్రత్యేక network firewall ను కూడా తనిఖీ చేయండి.

System Settings లో System Manager role ఉన్న ప్రతి account కు two factor authentication ప్రారంభించండి. ఆ role ఉన్నవారు ప్రతి document ను చదవగలరు మరియు ప్రతి table ను export చేయగలరు. అందువల్ల దాన్ని సౌలభ్యం కోసం ఇచ్చే role గా కాకుండా administrator account గా పరిగణించండి. మీరు అనేక self-hosted apps నడుపుతుంటే, ప్రతి app కు మరో password ఉంచడం కంటే self-hosted single sign-on provider గా Authentik మెరుగైనది.

Host ను patch చేయండి. Kernel updates కోసం reboot చేయండి. Stack తిరిగి ప్రారంభమవుతుందని ఆధారపడే ముందు, ప్రతి service కు rendered file లో restart policy ఉందో తనిఖీ చేయండి. ఆ policy లేకపోతే reboot తర్వాత stack ప్రారంభం కాకుండా down గానే ఉంటుంది. reboot తర్వాత Docker Compose stack ను మళ్లీ ప్రారంభించేలా చేయడం లో systemd సంబంధిత విధానం వివరించబడింది.

ఒక VPSపై ERPNext ఇక సౌకర్యవంతంగా నిర్వహించలేనప్పుడు

ఒక VPS చిన్న సంస్థ అవసరాలను చాలా కాలం నిర్వహించగలదు. అది ఇక సరిపోవడం లేదని సూచించే లక్షణాలు ఇవి:

• Background jobs పేరుకుపోతాయి. అందువల్ల emails మరియు imports కొన్ని నిమిషాలు లేదా గంటలు ఆలస్యంగా వస్తాయి.
• docker inspect reports లో "OOMKilled": true లేదా exit code 137 ఉన్న containers కనిపిస్తాయి.
• రెండు seconds పట్టిన reports ఇప్పుడు thirty seconds పడతాయి. MariaDB CPUని ఎక్కువగా వినియోగించే processగా ఉంటుంది.
• Backups పూర్తవడానికి ఎక్కువ సమయం పడుతుంది. అందువల్ల ఒక backup, తదుపరి scheduled run ప్రారంభమయ్యే సమయానికి ఇంకా నడుస్తూనే ఉంటుంది.

ముందుగా MariaDBకి ఇతర సేవలతో పంచుకోని resources కేటాయించండి. Database మరియు Python workers ఒకే memory కోసం పోటీ పడతాయి. ఎక్కువ memory అవసరమయ్యే భాగం buffer pool. Application serverను పెద్దదిగా చేయడం వల్ల ఆశించినంత ప్రయోజనం ఉండదు. databaseను Dockerలో లేదా hostపై నడపడం గురించి ఆ నిర్ణయాన్ని వివరిస్తుంది. మీరు ఈ మార్పులు చేస్తున్నప్పుడు Docker Composeలో memory limits అమర్చడం ద్వారా ఒక container ఇతర containersకు అవసరమైన resourcesను పూర్తిగా వినియోగించకుండా నిరోధించవచ్చు.

తర్వాత web capacity పెంచడం కంటే queue workers జోడించండి. ERPNextలో నెమ్మదిగా పూర్తయ్యే పనులు background పనులు: report generation మరియు bulk imports. మరింత పెద్ద server కంటే అదనపు worker containers తక్కువ ఖర్చుతో లభిస్తాయి. వినియోగదారులు వాస్తవంగా ఎదుర్కొంటున్న సమస్యను అవి పరిష్కరిస్తాయి.

FAQ

VPSలో ERPNext కు ఎంత 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 వినియోగాన్ని పర్యవేక్షించండి.

Productionలో pwd.yml ను నడపవచ్చా?

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

Siteని సృష్టించిన వెంటనే నా ERPNext site ఎందుకు అందుబాటులో ఉండదు?

Defaultగా frontend, ఏ siteను అందించాలో HTTP Host header ఆధారంగా ఎంచుకుంటుంది. అందువల్ల site పేరు browserలోని domainతో సరిపోవాలి. erpnextగా సృష్టించిన site, erp.example.com వద్ద అందించబడదు. Domainను site పేరుగా ఉపయోగించి siteను సృష్టించండి. లేదా env fileలో FRAPPE_SITE_NAME_HEADERను site పేరుకు సెట్ చేసి, 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ను ప్రారంభించండి. తరువాత bench --site erp.example.com migrateను నడిపి, maintenance modeను ఆపండి. ఒకసారి ఒక major version మాత్రమే మార్చండి. ముందుగా release notes చదవండి. ఎందుకంటే migrate schema మరియు document dataను తిరిగి మార్చలేని విధంగా రాస్తుంది. Rollback చేయాలంటే ప్రారంభంలో తీసుకున్న backupను restore చేయాలి.