Dockerతో VPSపై Discourse ఎలా ఇన్‌స్టాల్ చేయాలి

VPSపై Discourse ఇన్‌స్టాల్ చేయడం: ఒక container, ఒక config file

VPSపై Discourse ఇన్‌స్టాల్ చేయడానికి ప్రాజెక్ట్ అందించే installer ను అమలు చేసి, చిన్న wizard లోని ప్రశ్నలకు సమాధానాలు ఇవ్వాలి. తరువాత build పూర్తయ్యే వరకు వేచి ఉండాలి. Discourse ఒకే Docker containerగా విడుదలవుతుంది. ఇందులో Rails application, PostgreSQL, Redis, nginx ఉంటాయి. తరువాత మీరు మార్చే ప్రతిదీ ఒకే fileలో ఉంటుంది: /var/discourse/containers/app.yml. ప్రతి మార్పు rebuild ద్వారా siteకు వర్తిస్తుంది.

అధికారిక install విధానం discourse_docker: ఇది ఒక launcher shell script మరియు కొన్ని YAML templates కలిగి ఉంటుంది. మీరు స్వయంగా రాసే Compose fileను Discourse support చేయదు. అలాగే containerను చేతితో విడదీయడానికి ఇది రూపొందించబడలేదు. మీరు VPSపై Docker Composeతో services నడపడం కు అలవాటుపడి ఉంటే, ఇక్కడి నిర్మాణం భిన్నంగా ఉంటుంది. ఇక్కడ docker compose up -d ఉండదు. ./launcher rebuild app deploy విధానం.

Discourse ప్రారంభించే ముందు అవసరమైనవి

నాలుగు అవసరాలు తరచుగా గుర్తించకుండా పోతాయి. Login page చేరుకునేలోపే వీటిలో ప్రతి ఒక్కటి సమస్య కలిగించవచ్చు.

• Memory. ఒకే container లో PostgreSQL, Redis, Sidekiq మరియు Ruby web server నడుస్తాయి. Build step assets ను compile చేస్తుంది. దీనికి నడుస్తున్న site కంటే ఎక్కువ memory అవసరం.
• నిజమైన domain name. పంపిణీ చేసే sample config దీన్ని స్పష్టంగా చెబుతుంది: "Discourse will not work with a bare IP number."
• Outbound mail path. Account activation, password resets, admin invites మరియు digest mail అన్నీ SMTP (simple mail transfer protocol) ద్వారా బయటకు పంపబడతాయి.
• Host పై 80 మరియు 443 ports ఖాళీగా ఉండాలి. మీరు ఇప్పటికే నడుపుతున్న proxy వెనుక Discourse ను ఉద్దేశపూర్వకంగా ఉంచితే ఈ అవసరం ఉండదు.

[
  {
    "label": "Documented minimum",
    "ram_gb": 1,
    "storage_gb": 10
  },
  {
    "label": "Documented recommended",
    "ram_gb": 2,
    "storage_gb": 20
  }
]

అధికారిక install document కనీస అవసరంగా 1 GB RAM, swap మరియు 10 GB disk పేర్కొంటుంది. అలాగే 2 GB RAM మరియు 20 GB disk సిఫారసు చేస్తుంది. మొదటి వరుసలోని సంఖ్యను installer పూర్తి కావడానికి అవసరమైన పరిమాణంగా చూడాలి. Community ను నడపడానికి మీరు కోరుకునే పరిమాణంగా చూడకూడదు. ఈ తేడా ముఖ్యమైనది. కారణం traffic కాదు, build సమయంలో ఏర్పడే memory peak.

మీరు install చేసే ముందు domain ను server కు point చేయండి

మీరు ఉపయోగించే hostname కోసం A record సృష్టించండి. తరువాత server నుంచే దాన్ని నిర్ధారించండి.

dig +short forum.example.com
curl -4 -s https://ifconfig.co

రెండు commands ఒకే address ను print చేయాలి. Setup wizard మీ hostname పై connection test నిర్వహిస్తుంది కాబట్టి అవి ఒకే address ను చూపాలి. Record ఇంకా వేరే చోటికి point చేస్తుంటే ఆ test విఫలమవుతుంది. మీరు రెండు నిమిషాల క్రితం సృష్టించిన record ఇంకా cache అయి ఉండవచ్చు. అందువల్ల wizard తో పోరాడకుండా పాత TTL (time to live) గడిచే వరకు వేచి ఉండండి.

ఆ record ను CDN proxy చేస్తుందా లేదా ఇప్పుడే నిర్ణయించండి. Proxied record మీ server address ను దాచుతుంది. అప్పుడు container certificate request విఫలమవుతుంది. కారణం, ACME (automatic certificate management environment) challenge కు Discourse బదులుగా proxy సమాధానం ఇస్తుంది. మొదటి install సమయంలో record ను unproxied గా ఉంచండి.

అధికారిక installer ను అమలు చేయండి

ఒకే command తో git install అవుతుంది, Docker స్వంత install script ద్వారా Docker install అవుతుంది, discourse_docker ను /var/discourse లో clone చేసి setup wizard ప్రారంభమవుతుంది.

wget -qO- https://raw.githubusercontent.com/discourse/discourse_docker/main/install-discourse | sudo bash

Docker ఇప్పటికే system లో ఉంటే, ప్రతి దశను చూడాలనుకుంటే ఇదే పని manual గా చేయండి.

sudo -s
git clone https://github.com/discourse/discourse_docker.git /var/discourse
cd /var/discourse
./discourse-setup

దీన్ని root గా అమలు చేయండి. సాధారణ user గా ప్రారంభిస్తే, discourse-setup వెంటనే This script must be run as root. Please sudo or log in as root first. తో ఆగిపోతుంది. System లో Docker లేకపోతే Docker is not installed. Please install Docker first. తో ఆగిపోతుంది, ఎందుకంటే manual clone మీ కోసం ఏదీ install చేయదు.

సెటప్ విజార్డ్ ఏమి అడుగుతుంది, ఏమి రాస్తుంది

August 2026 నాటికి discourse-setup ఒక thin wrapper మాత్రమే. ఇది host network మరియు Docker socket mount చేసిన స్థితిలో discourse/setup-wizard:release ను container గా నడుపుతుంది. అందువల్ల విజార్డ్ తాను configure చేస్తున్న machine ను పరిశీలించగలదు. ఇది hostname మరియు admin email addresses ను అడుగుతుంది. తరువాత మీ SMTP block ను అడుగుతుంది. ఇది containers/app.yml ను రాసి, ఆపై rebuild చేస్తుంది.

ప్రారంభించే ముందు రెండు ప్రవర్తనలను తెలుసుకోవాలి. Machine లో memory తక్కువగా ఉండి, swap లేకపోతే విజార్డ్ ఆగి swap సృష్టించమని సూచిస్తుంది. అప్పుడు wrapper 2 GB /swapfile ను సృష్టించి, దాన్ని /etc/fstab కు జతచేస్తుంది. /etc/sysctl.d/30-discourse-swap.conf లో vm.swappiness = 10 ను సెట్ చేసి, విజార్డ్‌ను మళ్లీ ప్రారంభిస్తుంది. విజార్డ్ పూర్తయినప్పుడు ఇది Rebuilding app in 5 seconds (Ctrl+C to cancel)... ను print చేసి, host పై ./launcher rebuild app ను నడుపుతుంది. చిన్న VPS లో ఈ build కు కొన్ని నిమిషాలు పడుతుంది. మొదటి build ఎక్కువ సమయం తీసుకుంటుంది, ఎందుకంటే ప్రతి asset ను మొదటి నుంచి compile చేస్తుంది.

ఏదైనా సమస్య వచ్చినప్పుడు ఉపయోగపడే flags ను ./discourse-setup --help జాబితా చేస్తుంది. --skip-rebuild build చేయకుండా config ను రాస్తుంది. --skip-connection-test DNS మరియు port checks ను దాటవేస్తుంది. Test ఎందుకు విఫలమవుతుందో మీకు ఇప్పటికే తెలిసినప్పుడు మాత్రమే --skip-connection-test ను ఉపయోగించండి. ఉదాహరణకు, host మీ నియంత్రణలో ఉన్న network firewall వెనుక ఉన్నప్పుడు దీన్ని ఉపయోగించవచ్చు.

మొదటి rebuild కు ముందు app.yml ను చదవండి

Wizard నిర్వహించాల్సిన ఫైల్‌ను రూపొందిస్తుంది. ఇప్పుడు దాని నిర్వహణ మీ బాధ్యత. sudo nano /var/discourse/containers/app.yml తో దాన్ని తెరవండి. దాదాపు అన్నింటినీ నిర్ణయించే భాగాలు ఇవి.

templates:
  - "templates/postgres.template.yml"
  - "templates/redis.template.yml"
  - "templates/web.template.yml"
  - "templates/web.ratelimited.template.yml"
  ## Uncomment these two lines if you wish to add Lets Encrypt (https)
  #- "templates/web.ssl.template.yml"
  #- "templates/web.letsencrypt.ssl.template.yml"

expose:
  - "80:80"   # http
  - "443:443" # https

env:
  DISCOURSE_HOSTNAME: "forum.example.com"
  DISCOURSE_DEVELOPER_EMAILS: "you@example.com"
  DISCOURSE_SMTP_ADDRESS: smtp.example.com
  DISCOURSE_SMTP_PORT: 587
  DISCOURSE_SMTP_USER_NAME: user@example.com
  DISCOURSE_SMTP_PASSWORD: "your-smtp-password"

DISCOURSE_HOSTNAME అనేది site స్పందించే address. Discourse తన links ను దీని ఆధారంగా రూపొందిస్తుంది. కాబట్టి తప్పు విలువ ఉంటే site ఒకసారి load అయి, ఆ తర్వాత మిమ్మల్ని వేరే చోటికి పంపుతుంది. DISCOURSE_DEVELOPER_EMAILS అనేది comma-separated list. అందులోని addresses మొదటి signup సమయంలో స్వయంచాలకంగా admin addresses గా మారతాయి. అక్కడ మీ స్వంత address ను ఉంచి, అదే address తో register చేయండి. మొదటి admin account ఈ విధంగానే సృష్టించబడుతుంది.

ఫైల్‌లో మీ SMTP password plain text గా నిల్వ ఉంటుంది. అందువల్ల sudo chmod 700 /var/discourse/containers తో directory కు పరిమితులు విధించండి. ఇది YAML కూడా. YAML లో whitespace config లో భాగం. తప్పుగా అమర్చిన key parse error తో build ను విఫలమయ్యేలా చేస్తుంది. దాంతో site అందుబాటులో ఉండదు. Sample file లోనే ఒక సమస్యను నమోదు చేశారు. Quoted కాని password లోని # comment ను ప్రారంభిస్తుంది. కాబట్టి # ఉన్న ఏ password నైనా quotes లో ఉంచండి.

Email చాలా installలను ఆపే దశ

August 2026 నాటికి wizard SMTP ను దాటవేసి, బదులుగా Discourse ID logins ను ఉపయోగించడానికి అనుమతిస్తుంది. app.yml లో దీనికి సరిపోయే DISCOURSE_SKIP_EMAIL_SETUP switch కూడా ఉంది. అక్కడ ఇది email setup validation ను దాటవేయడంగా వివరించబడింది. సాఫ్ట్‌వేర్‌ను మొదటిసారి పరిశీలించడానికి ఈ దశను దాటవేయడం సమంజసం. అయితే community కోసం ఇది సరైన ఎంపిక కాదు. బయటకు mail పంపే వ్యవస్థ లేకపోతే ఎవరూ account ను activate చేయలేరు లేదా password ను reset చేయలేరు.

అమలులో ప్రధాన సమస్య ఏమిటంటే, చాలా VPS providers బయటకు వెళ్లే port 25 ను block చేస్తాయి. అందువల్ల ఆ server పై సాధారణ mail server mail ను deliver చేయదు. Port 587 పై authenticated relay ను ఉపయోగించండి. ప్రత్యామ్నాయంగా implicit TLS (transport layer security) తో port 465 ను ఉపయోగించండి. Port 465 కోసం DISCOURSE_SMTP_FORCE_TLS: true ను set చేయండి. Sample config ఆ port కోసం ఇదే సిఫారసు చేస్తుంది. Rebuild చేయడానికి ముందు host నుంచి reachability ను పరీక్షించండి.

nc -vz smtp.example.com 587

సరైన ఫలితం succeeded! తో ముగిసే ఒకే line. Command కొంతసేపు నిలిచిపోయి తరువాత timeout అయితే, మీ VPS నుంచి బయటకు వెళ్లే మార్గంలో ఆ port block అయిందని అర్థం. ఏ Discourse setting కూడా దీనిని పరిష్కరించదు. మీ provider అనుమతించే port కు మారండి లేదా ఆ port ను open చేయమని provider ను అడగండి.

Site ప్రారంభమైన తర్వాత, Admin లోని Email page నుంచి test message పంపండి. తరువాత అదే page లోని Skipped మరియు Bounced tabs ను పరిశీలించండి. పంపడానికి Discourse నిరాకరించిన mail మరియు relay తిరస్కరించిన mail వివరాలను ఈ tabs లో నమోదు చేస్తుంది. కారణాన్ని కూడా అక్కడ చూపిస్తుంది. Logs చదవడం కంటే ఇది వేగవంతమైన పద్ధతి.

TLS: container కు తన సొంత certificate పొందేలా చేయండి

Discourse ports 80 మరియు 443 ను స్వాధీనం చేసుకుంటే, దాని built-in issuance ను ఉపయోగించండి. పైన చూపిన రెండు SSL template lines కు ఉన్న comment తొలగించి, తర్వాత rebuild చేయండి. ఈ template acme.sh ను నియంత్రిస్తుంది, certificates ను /shared/ssl కింద ఉన్న shared volume లో నిల్వ చేస్తుంది, container లో schedule ప్రకారం వాటిని renew చేస్తుంది, అలాగే Discourse ను HTTPS ను తప్పనిసరిగా ఉపయోగించేలా సెట్ చేస్తుంది.

ఇది పనిచేయాలంటే port 80 ఇంటర్నెట్‌ నుంచి చేరుకోగలిగేలా ఉండాలి, ఎందుకంటే HTTP challenge కు అక్కడే సమాధానం ఇవ్వబడుతుంది. 443 ను మాత్రమే అనుమతించే firewall వల్ల build పూర్తవుతుంది, కానీ certificate ఎప్పటికీ issue కాదు. Rebuild పూర్తయిన వెంటనే ./launcher logs app తో ఫలితాన్ని తనిఖీ చేయండి.

nginx లేదా Caddy ను ముందు ఉంచాలా?

VPSలో Discourse మాత్రమే web service అయితే ఉంచవద్దు. Container‌లో ఇప్పటికే అనుకూలంగా కాన్ఫిగర్ చేసిన nginx నడుస్తోంది. రెండవ proxy ఒక అదనపు hop ను, మళ్లీ renewal చేయాల్సిన మరో certificate ను, header సమస్యలకు కొత్త కారణాన్ని జోడిస్తుంది.

అదే VPS ఇతర sites ను అందిస్తే ముందు proxy ఉంచండి. Templates జాబితాకు templates/web.socketed.template.yml ను జోడించండి. expose ఉన్న రెండు lines ను comment చేయండి. SSL templates ఉన్న రెండు lines ను కూడా comment చేసినట్టే ఉంచండి. అప్పుడు container /var/discourse/shared/standalone/nginx.http.sock వద్ద unix socket పై మాత్రమే listen చేస్తుంది. ఏ ports ను స్వయంగా ఉపయోగించదు. దీంతో 80 మరియు 443 ports మీ స్వంత proxy కోసం ఖాళీగా ఉంటాయి.

server {
  listen 443 ssl;
  server_name forum.example.com;

  location / {
    proxy_pass http://unix:/var/discourse/shared/standalone/nginx.http.sock:;
    proxy_set_header Host $http_host;
    proxy_http_version 1.1;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Real-IP $remote_addr;
  }
}

.sock తర్వాత ఉన్న చివరి colon, nginx unix socket syntax లో భాగం. అది లేకపోతే sudo nginx -t configuration ను తిరస్కరిస్తుంది. X-Forwarded-Proto కూడా తప్పనిసరి. Discourse absolute links ను రాస్తుంది. ఆ header లేకపోతే HTTPS page లో http:// links ను ఉత్పత్తి చేస్తుంది. Browsers వాటిని mixed content గా block చేస్తాయి. Container socket ద్వారా పనిచేసినప్పుడు TLS బాధ్యత మీపై ఉంటుంది. అందువల్ల host పై Ubuntu 24.04 మరియు nginx లో Certbot ఉపయోగించి certificate జారీ చేయండి. ఏ proxy ఎంచుకోవాలో ఇంకా నిర్ణయించకపోతే, nginx, Caddy మరియు Traefik పోలిక మీరు చేస్తున్న trade-off ను వివరిస్తుంది.

Rebuildలు, upgrades మరియు మీరు వాస్తవంగా ఉపయోగించే commands

cd /var/discourse
./launcher rebuild app

rebuild నడుస్తున్న container ను తొలగించి, app.yml నుంచి కొత్తదాన్ని సిద్ధం చేసి ప్రారంభిస్తుంది. మొత్తం build సమయంలో site offline గా ఉంటుంది. అందువల్ల ప్రతి config మార్పును కొన్ని నిమిషాల scheduled downtime గా పరిగణించండి.

env: కింద ఉన్న values మాత్రమే మార్చితే ఇది అవసరం లేదు. ./launcher destroy app && ./launcher start app మీరు ఇప్పటికే build చేసిన image నుంచి container ను మళ్లీ సృష్టిస్తుంది. దీనికి కొన్ని seconds మాత్రమే పడుతుంది. templates: లేదా hooks: కింద ఉన్న ఏదైనా మారితే image కూడా మారుతుంది. అందువల్ల పూర్తి rebuild అవసరం.

Upgrades రెండు మార్గాల్లో వస్తాయి. Point releases ను /admin/upgrade వద్ద ఉన్న web interface నుంచి apply చేయవచ్చు. ఈ interface ను build సమయంలో app.yml clone చేసే docker_manager plugin అందిస్తుంది. Base image లేదా templates లోని మార్పులు git నుంచి వస్తాయి.

cd /var/discourse
git pull
./launcher rebuild app

చిన్న servers లో rebuild సమయంలో failures సంభవిస్తాయి. దీనికి కారణం asset compilation మొత్తం system లో memory peak కావడం. Build మధ్యలో ఆగిపోయి, dmesg లో ruby process పేరును చూపించే Out of memory: Killed process వంటి line కనిపిస్తే, site అంతకుముందు సరిగ్గా నడుస్తున్నప్పటికీ build సమయంలో memory అయిపోయిందని అర్థం. Swap జోడించి rebuild ను మళ్లీ అమలు చేయండి.

./launcher logs app
./launcher enter app
./launcher cleanup

logs container output ను చూపిస్తుంది. enter దాని లోపల shell ను తెరుస్తుంది. cleanup 24 గంటలకంటే ఎక్కువసేపు stopped గా ఉన్న containers ను తొలగిస్తుంది. cleanup ను అప్పుడప్పుడు అమలు చేయండి. ప్రతి rebuild తర్వాత పాత container మిగిలిపోతుంది. చిన్న VPS లో disk స్థలం నిశ్శబ్దంగా పూర్తవుతుంది.

బ్యాకప్‌లు, అలాగే బ్యాకప్‌లో లేని ఫైల్

Admin లోని Backups పేజీ నుంచి బ్యాకప్‌లు తీసుకోండి. ఆర్కైవ్ host లోని /var/discourse/shared/standalone/backups/default/ వద్ద నిల్వ అవుతుంది. ఇదే పని shell నుంచి కూడా అమలు చేయవచ్చు.

cd /var/discourse
./launcher enter app
discourse backup

discourse restore <filename> దాన్ని పునరుద్ధరిస్తుంది. అయితే ముందుగా discourse enable_restore అమలు చేసే వరకు restore నిరాకరించబడుతుంది. సక్రియంగా ఉన్న forum ను అనుకోకుండా ఒక command overwrite చేయకుండా ఉండటానికే ఈ రక్షణ ఉంది.

మీరు స్వయంగా పరిష్కరించాల్సిన రెండు లోపాలు ఉన్నాయి. ఆర్కైవ్‌లో database ఉంటుంది. Uploads ను చేర్చే backup setting ఆన్‌లో ఉన్నప్పుడే uploaded files కూడా ఉంటాయి. కాబట్టి దానిపై నమ్మకం పెట్టుకునే ముందు ఆ setting ను తనిఖీ చేయండి. ఇందులో ఎప్పుడూ app.yml ఉండదు. అందువల్ల fresh VPS కు restore చేసినప్పుడు మీ hostname మరియు SMTP block ను మళ్లీ అమర్చాలి. అంటే ఆ file ను కూడా server వెలుపలికి copy చేయాలి.

ఆర్కైవ్, అది రక్షించే site ఉన్న అదే disk లోనే ఉంటుంది. అది backup కాదు. నిర్ణయించిన schedule ప్రకారం ఆర్కైవ్‌ను వేరే ప్రదేశానికి తరలించండి.

rsync -avz root@forum.example.com:/var/discourse/shared/standalone/backups/default/ ~/discourse-backups/

RAMలో అధిక ట్రాఫిక్ ఉన్న ఫోరమ్‌కు అయ్యే ఖర్చు

bootstrap గుర్తించిన memory మరియు CPU ఆధారంగా UNICORN_WORKERS, db_shared_buffers విలువలను సెట్ చేస్తుంది. నమూనా config మొత్తం memoryలో నాలుగో వంతుకు shared buffers పరిమితం చేస్తుంది. ప్రతి unicorn worker ఒక పూర్తి Ruby process. Sidekiq వాటి పక్కన background jobs నడుపుతుంది. అందువల్ల memory వినియోగం నమోదు చేసిన సభ్యుల సంఖ్యకన్నా concurrent requests ను అనుసరిస్తుంది. కొన్ని వందల సభ్యులు ఉన్న నిశ్శబ్ద ఫోరమ్‌కు అధిక workload ఉండదు.

ఈ వ్యాసంలోని సంఖ్యతో సహా, ఏదైనా వ్యాసంలోని సంఖ్య ఆధారంగా server పరిమాణాన్ని నిర్ణయించవద్దు. మీ స్వంత serverను కొలవండి.

free -m
docker stats --no-stream

Swap నిరంతరం ఉపయోగంలో ఉండటం, pages నెమ్మదిగా లోడ్ కావడం కలిసి కనిపిస్తే మీకు RAM తక్కువగా ఉంది. Memory స్థిరంగా ఉండి pages నెమ్మదిగా లోడ్ అయితే సాధారణంగా కారణం మరొకటి. అందువల్ల పెద్ద plan కొనుగోలు చేసే ముందు ./launcher logs app చదవండి. Server వెలుపల నుంచి కూడా ఒక check జోడించండి. ఎందుకంటే 3am సమయంలో ఫోరమ్ memory అయిపోయినా అది నిశ్శబ్దంగా విఫలమవుతుంది. వేరే hostలో ఉన్న self-hosted Uptime Kuma status monitor మీ సభ్యులు గుర్తించేలోపు మీకు తెలియజేస్తుంది.

Discourse సరైన ఎంపిక కానప్పుడు

Discourse పెద్ద అప్లికేషన్. దీని installation భారీగా ఉంటుంది. app.yml లో ఉన్న ప్రతి setting మార్పుకు rebuild cycle అవసరం. ఈ ఖర్చుతో moderation కోసం ఉపయోగకరమైన సాధనాలు, archive పెద్దదైనా పనిచేసే search లభిస్తాయి. మాట్లాడుకోవడానికి ఒక వేదిక మాత్రమే కావాలనుకునే ముప్పై మందికి, సంభాషణ అవసరానికి ఇది మించిన యంత్ర వనరులను కోరుతుంది. ముందుగా self-hosted forum software పోలికను చదవండి. Discourse పేరు మీకు ముందే తెలుసు కాబట్టి కాకుండా, అది అందించే లక్షణాలు మీకు అవసరమైనందున ఎంచుకోండి.

FAQ

డొమైన్ పేరు లేకుండా VPSలో Discourseను ఇన్‌స్టాల్ చేయవచ్చా?

లేదు. అందించిన configuration ప్రకారం Discourse bare IP numberతో పనిచేయదు; DISCOURSE_HOSTNAME అవసరం. Discourse ఆ hostname ఆధారంగా absolute links రూపొందిస్తుంది. అందువల్ల అక్కడ IP address ఉపయోగిస్తే links పనిచేయవు, certificate issuance కూడా ఆగిపోతుంది. ప్రారంభించే ముందు A record సృష్టించండి. అది మీ server addressకు resolve అవుతోందని dig +short forum.example.comతో నిర్ధారించండి.

ఇన్‌స్టాలేషన్‌ను పూర్తి చేయడానికి SMTPను configure చేయాలా?

August 2026 నాటికి అది తప్పనిసరి కాదు. Setup wizard బదులుగా Discourse ID loginsను అందిస్తుంది. అలాగే email setup validationను దాటవేయడానికి app.ymlలో switch ఉంది. మొదటి పరిశీలనకంటే ఎక్కువగా ఉపయోగించాలనుకుంటే SMTPను configure చేయండి. Account activation మరియు password resets రెండూ emailపై ఆధారపడతాయి. Port 587 లేదా 465పై authenticated relayను ఉపయోగించండి. చాలా VPS providers outbound port 25ను block చేస్తాయి.

Discourse rebuild మధ్యలో ఎందుకు విఫలమైంది?

సాధారణ కారణం memory. Build సమయంలో asset compilationకు running siteకంటే ఎక్కువ memory అవసరం. అందువల్ల forumను సరిగా serve చేస్తున్న server కూడా rebuild సమయంలో విఫలమవచ్చు. dmesgలో Out of memory: Killed process అనే ruby process కనిపిస్తే, swapను జోడించండి. Wizard అందించే స్వంత swapfile పరిమాణం 2 GB. తరువాత ./launcher rebuild appను మళ్లీ run చేయండి. Build YAML error వద్ద ఆగితే, app.ymlలో indentation తప్పు ఉందని అర్థం.

Discourseను నా స్వంత nginx లేదా Caddy వెనుక ఉంచాలా?

VPSలో ఇతర sites కూడా serve చేస్తున్నప్పుడు మాత్రమే ఉంచండి. Serverలో Discourse మాత్రమే ఉంటే, container ports 80 మరియు 443ను ఉపయోగించనివ్వండి. అది తన certificateను తానే issue చేస్తుంది. దీనివల్ల నిర్వహించాల్సిన భాగాలు తగ్గుతాయి. Machineను share చేయాలంటే templates/web.socketed.template.ymlను జోడించండి. expose linesను comment out చేయండి. తరువాత unix socket /var/discourse/shared/standalone/nginx.http.sockకు proxy చేయండి. X-Forwarded-Protoను pass through చేయండి. లేకపోతే HTTPS pageలో Discourse http:// linksను ఉత్పత్తి చేస్తుంది.

Self-hosted Discourseకు backup ఎలా తీసుకోవాలి?

Adminలోని Backups pageను ఉపయోగించండి. లేదా ./launcher enter app తర్వాత discourse backupను run చేయండి. Archives hostలో /var/discourse/shared/standalone/backups/default/ వద్ద నిల్వ అవుతాయి. Uploadsను చేర్చే setting ఆన్‌లో ఉందని నిర్ధారించండి. Archiveతో పాటు /var/discourse/containers/app.ymlను కూడా copy చేయండి. రెండింటినీ మరో machineకు తరలించండి. Site ఉన్న అదే diskలో backup ఉంచితే, ఆ backup అవసరమైన disk failure నుంచి అది రక్షించదు.