VPSపై Dockerతో Discourse ఇన్‌స్టాల్ చేసే విధానం

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

VPSపై Discourseను ఇన్‌స్టాల్ చేయడానికి project యొక్క స్వంత installerను అమలు చేసి, చిన్న wizardలోని ప్రశ్నలకు సమాధానం ఇవ్వాలి, తరువాత build పూర్తయ్యే వరకు వేచి ఉండాలి. Discourse ఒకే Docker containerగా విడుదలవుతుంది. ఆ 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ను చేతితో విడగొట్టడానికి అది రూపొందించబడలేదు. Docker Composeతో VPSపై 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 swap తో కనీసం 1 GB RAM మరియు 10 GB disk అవసరమని చెబుతుంది. అలాగే 2 GB RAM మరియు 20 GB disk సిఫారసు చేస్తుంది. మొదటి వరుసలోని విలువను installer పూర్తి కావడానికి అవసరమైన సంఖ్యగా చూడాలి. Community ను నడపాలనుకునే సరైన సామర్థ్యంగా దాన్ని చూడకండి. ఈ తేడా ముఖ్యమైనది. కారణం traffic కాదు; build సమయంలో memory peak ఎక్కువగా ఉంటుంది.

మీరు ఇన్‌స్టాల్ చేయడానికి ముందు domain ను server వైపు point చేయండి

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

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

రెండు commands ఒకే address ను print చేయాలి. అవి ఒకే address ను చూపాలి, ఎందుకంటే setup wizard మీ hostname కు connection test నిర్వహిస్తుంది. వేరే చోటుకు point చేస్తున్న record ఆ 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

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

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 చేయదు.

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

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

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

ఏదైనా తప్పు జరిగినప్పుడు అవసరమైన flags ను ./discourse-setup --help జాబితా చేస్తుంది. --skip-rebuild build చేయకుండా config ను రాస్తుంది. --skip-connection-test DNS మరియు port checks ను skip చేస్తుంది. Test ఎందుకు fail అవుతుందో మీకు ఇప్పటికే తెలిసినప్పుడు మాత్రమే --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 అనేది సైట్ స్పందించే చిరునామా. Discourse తన links ను దీని ఆధారంగా రూపొందిస్తుంది. అందువల్ల తప్పు విలువ ఉంటే సైట్ ఒకసారి లోడ్ అయి, తరువాత మిమ్మల్ని వేరే చోటికి పంపుతుంది. DISCOURSE_DEVELOPER_EMAILS comma-separated list. అందులోని చిరునామాలు మొదటి signup సమయంలో స్వయంచాలకంగా admin అవుతాయి. అక్కడ మీ స్వంత చిరునామాను ఉంచి, అదే చిరునామాతో register చేయండి. మొదటి admin account ఈ విధంగానే సృష్టించబడుతుంది.

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

ఇమెయిల్ చాలా ఇన్‌స్టాలేషన్‌లను ఆపే దశ

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

ప్రధాన సమస్య ఏమిటంటే చాలా VPS providers outbound 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 ను test చేయండి.

nc -vz smtp.example.com 587

సరైన ఫలితం succeeded! తో ముగిసే ఒకే line. Command hang అయి, తరువాత timeout అయితే, మీ VPS నుంచి బయటికి వెళ్లే మార్గంలో ఆ port block అయిందని అర్థం. Discourse setting ఏదీ దీనిని పరిష్కరించదు. మీ provider అనుమతించే 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 ను uncomment చేసి, ఆ తరువాత rebuild చేయండి. Template acme.sh ను నడిపిస్తుంది, certificates ను /shared/ssl కింద shared volume లో నిల్వ చేస్తుంది, container లోని schedule ప్రకారం వాటిని renew చేస్తుంది, అలాగే Discourse ను HTTPS ను తప్పనిసరిగా ఉపయోగించేలా సెట్ చేస్తుంది.

ఇది పనిచేయాలంటే port 80 internet నుంచి అందుబాటులో ఉండాలి, ఎందుకంటే 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 పంక్తులను comment out చేయండి. రెండు SSL templatesను కూడా comment out చేసిన స్థితిలో ఉంచండి. అప్పుడు container /var/discourse/shared/standalone/nginx.http.sock వద్ద unix socketపై మాత్రమే వినుతుంది. అది ఎలాంటి 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గా నిరోధిస్తాయి. Container socketను ఉపయోగించే విధంగా అమర్చినప్పుడు TLS బాధ్యత మీపై ఉంటుంది. అందువల్ల hostపై Ubuntu 24.04 మరియు nginxలో Certbot ఉపయోగించి certificateను జారీ చేయండి. ఇంకా ఏ proxyని ఎంచుకోవాలో నిర్ణయించకపోతే, nginx, Caddy మరియు Traefik పోలిక మీరు చేస్తున్న trade-offలను వివరిస్తుంది.

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

cd /var/discourse
./launcher rebuild app

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

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

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

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

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

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

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

బ్యాకప్‌లు మరియు బ్యాకప్‌లో లేని ఫైల్

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

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

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

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

అదనంగా, archive రక్షించాల్సిన site ఉన్న అదే disk లోనే ఉంటుంది. ఇది backup కాదు. నిర్ణయించిన schedule ప్రకారం దాన్ని వేరే ప్రదేశానికి copy చేయండి.

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

RAMలో రద్దీగా ఉండే forum నిర్వహణ వ్యయం

Bootstrap గుర్తించిన memory మరియు CPU ఆధారంగా UNICORN_WORKERS, db_shared_buffers విలువలను సెట్ చేస్తుంది. నమూనా config మొత్తం memoryలో నాలుగో వంతు వరకు shared buffersను పరిమితం చేస్తుంది. ప్రతి unicorn worker ఒక పూర్తి Ruby process. Sidekiq కూడా వాటి పక్కన background jobs నడుపుతుంది. అందువల్ల memory వినియోగం నమోదు చేసిన సభ్యుల సంఖ్యకన్నా concurrent requestsను అనుసరిస్తుంది. కొన్ని వందల మంది సభ్యులతో నిశ్శబ్దంగా ఉండే forumకు అధిక workload ఉండదు. అదే boxలో మరే ఇతర సేవలు నడుస్తున్నాయో సాధారణంగా ఎక్కువ ప్రభావం చూపుతుంది. అది photo library అయితే, PhotoPrism మరియు Immich పోలికలో కొలిచిన కనిష్ఠ RAM అవసరాలు Discourse rebuild పూర్తయ్యేంత headroom ఉందో తెలియజేస్తాయి.

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

free -m
docker stats --no-stream

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

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

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

FAQ

domain name లేకుండా 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ను అందిస్తుంది. app.ymlలో email setup validationను దాటవేసే switch ఉంది. మొదటి పరిశీలనకు మించి ఉపయోగించాలంటే దీన్ని configure చేయండి. Account activation మరియు password resets రెండింటికీ email అవసరం. 587 లేదా 465 portపై authenticated relayను ఉపయోగించండి. చాలా VPS providers outbound port 25ను block చేస్తాయి.

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

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

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

VPSపై ఇతర sites కూడా నడుస్తున్నప్పుడు మాత్రమే అలా చేయండి. ఒక 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ను ఎలా back up చేయాలి?

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