VPS पर Docker के साथ Discourse कैसे इंस्टॉल करें

VPS पर Discourse इंस्टॉल करना: एक कंटेनर, एक कॉन्फ़िगरेशन फ़ाइल

VPS पर Discourse इंस्टॉल करने के लिए आप प्रोजेक्ट के अपने इंस्टॉलर को रन करते हैं, एक संक्षिप्त विज़ार्ड के सवालों का जवाब देते हैं और बिल्ड का इंतज़ार करते हैं। Discourse एक सिंगल Docker कंटेनर के रूप में आता है जिसमें Rails एप्लिकेशन, PostgreSQL, Redis और nginx शामिल होते हैं। आप बाद में जो कुछ भी बदलेंगे वह एक ही फ़ाइल, /var/discourse/containers/app.yml में रहता है, और हर बदलाव एक रीबिल्ड के माध्यम से साइट तक पहुँचता है।

आधिकारिक इंस्टॉलेशन discourse_docker है: एक launcher शेल स्क्रिप्ट और YAML टेम्प्लेट का एक सेट। Discourse आपके द्वारा स्वयं लिखे गए Compose फ़ाइल को सपोर्ट नहीं करता है, और कंटेनर को मैन्युअल रूप से अलग करने का इरादा नहीं है। यदि आप Docker Compose के साथ VPS पर सर्विस चलाने के आदी हैं, तो एक अलग संरचना की अपेक्षा करें। यहाँ कोई docker compose up -d नहीं है, और ./launcher rebuild app ही डिप्लॉयमेंट है।

शुरू करने से पहले Discourse की आवश्यकताएं

चार ऐसी आवश्यकताएं हैं जो अक्सर लोगों के लिए समस्या बनती हैं, और लॉगिन पेज तक पहुँचने से पहले ही इनमें से प्रत्येक बाधा उत्पन्न कर सकती है।

• Memory: एक container में PostgreSQL, Redis, Sidekiq और एक Ruby web server चलते हैं। build प्रक्रिया के दौरान assets compile होते हैं, जिसके लिए चलते हुए site की तुलना में अधिक memory की आवश्यकता होती है।
• एक वास्तविक domain name: प्रदान की गई sample config में स्पष्ट रूप से लिखा है: "Discourse केवल IP address के साथ काम नहीं करेगा।"
• एक outbound mail path: account activation, password reset, admin invite और digest mail सभी SMTP (simple mail transfer protocol) के माध्यम से भेजे जाते हैं।
• host पर port 80 और 443 खाली होने चाहिए, जब तक कि आप जानबूझकर Discourse को किसी मौजूदा proxy के पीछे न रखें।

[
  {
    "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 चलाना चाहते हैं। यह अंतर महत्वपूर्ण है क्योंकि memory का peak उपयोग traffic के दौरान नहीं, बल्कि build के समय होता है।

इंस्टॉलेशन से पहले डोमेन को सर्वर पर पॉइंट करें

उस होस्टनेम के लिए एक A record बनाएँ जिसका आप उपयोग करेंगे, फिर सर्वर से ही इसकी पुष्टि करें।

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

दोनों commands को एक ही IP address दिखाना चाहिए। इनका मेल खाना आवश्यक है क्योंकि सेटअप विज़ार्ड आपके होस्टनेम के विरुद्ध एक कनेक्शन टेस्ट चलाता है, और यदि record कहीं और पॉइंट कर रहा है तो वह टेस्ट विफल हो जाएगा। दो मिनट पहले बनाया गया record अभी भी कैश (cached) हो सकता है, इसलिए विज़ार्ड से उलझने के बजाय पुराने TTL (time to live) के समाप्त होने की प्रतीक्षा करें।

अभी तय करें कि क्या record को CDN द्वारा प्रॉक्सी किया जाएगा। एक प्रॉक्सी किया गया record आपके सर्वर के address को छिपा देता है, और कंटेनर का सर्टिफिकेट अनुरोध विफल हो जाता है, क्योंकि ACME (automatic certificate management environment) चुनौती का उत्तर Discourse के बजाय प्रॉक्सी द्वारा दिया जाता है। पहले इंस्टॉलेशन के लिए record को unproxied रखें।

आधिकारिक इंस्टॉलर चलाएं

एक कमांड git को इंस्टॉल करती है, Docker के अपने इंस्टॉलेशन स्क्रिप्ट के साथ Docker को इंस्टॉल करती है, discourse_docker को /var/discourse में क्लोन करती है, और सेटअप विज़ार्ड को शुरू करती है।

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

यदि Docker पहले से ही बॉक्स पर मौजूद है और आप प्रत्येक चरण को देखना चाहते हैं, तो वही काम मैन्युअल रूप से करें।

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

इसे root के रूप में चलाएं। यदि इसे सामान्य उपयोगकर्ता के रूप में शुरू किया जाता है, तो discourse-setup तुरंत This script must be run as root. Please sudo or log in as root first. के साथ रुक जाता है। यदि बॉक्स पर Docker नहीं है, तो यह Docker is not installed. Please install Docker first. के साथ रुक जाता है, क्योंकि मैन्युअल क्लोन आपके लिए कुछ भी इंस्टॉल नहीं करता है।

सेटअप विज़ार्ड क्या पूछता है और क्या लिखता है

अगस्त 2026 तक discourse-setup एक थिन रैपर है। यह discourse/setup-wizard:release को होस्ट नेटवर्क और माउंटेड Docker सॉकेट के साथ एक कंटेनर के रूप में चलाता है, ताकि विज़ार्ड उस मशीन का निरीक्षण कर सके जिसे वह कॉन्फ़िगर कर रहा है। यह होस्टनेम और एडमिन ईमेल पते पूछता है, और फिर आपके SMTP ब्लॉक के लिए जानकारी मांगता है। यह containers/app.yml लिखता है और फिर रीबिल्ड करता है।

शुरू करने से पहले दो व्यवहारों के बारे में जानना उपयोगी है। यदि मशीन में मेमोरी कम है और कोई swap नहीं है, तो विज़ार्ड रुक जाता है और इसे बनाने का विकल्प देता है: रैपर तब 2 GB की /swapfile बनाता है, इसे /etc/fstab में जोड़ता है, /etc/sysctl.d/30-discourse-swap.conf में vm.swappiness = 10 सेट करता है, और विज़ार्ड को फिर से शुरू करता है। जब विज़ार्ड समाप्त होता है, तो यह Rebuilding app in 5 seconds (Ctrl+C to cancel)... प्रिंट करता है और होस्ट पर ./launcher rebuild app चलाता है। एक छोटे VPS पर यह बिल्ड कई मिनट लेता है, और पहला बिल्ड सबसे धीमा होता है क्योंकि हर एसेट को स्क्रैच से कंपाइल किया जाता है।

./discourse-setup --help उन फ्लैग्स को सूचीबद्ध करता है जो तब महत्वपूर्ण होते हैं जब कुछ गलत हो। --skip-rebuild बिल्ड किए बिना कॉन्फ़िगरेशन लिखता है, और --skip-connection-test DNS और पोर्ट चेक को छोड़ देता है। --skip-connection-test का उपयोग केवल तब करें जब आप पहले से जानते हों कि टेस्ट क्यों विफल हो रहा है, उदाहरण के लिए जब होस्ट किसी ऐसे नेटवर्क फायरवॉल के पीछे हो जिसे आप नियंत्रित करते हैं।

पहली बार rebuild करने से पहले app.yml को पढ़ें

विज़ार्ड एक ऐसी फ़ाइल बनाता है जिसे अब आपको ही maintain करना है। इसे 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 इसी के आधार पर अपने लिंक बनाता है। इसलिए, गलत मान डालने पर साइट एक बार तो लोड होगी, लेकिन फिर आपको कहीं और भेज देगी। DISCOURSE_DEVELOPER_EMAILS अल्पविराम (comma) से अलग की गई एक सूची है, और ये पते पहली बार साइनअप करने पर स्वचालित रूप से एडमिन बन जाते हैं। यहाँ अपना ईमेल पता डालें और उसी से रजिस्टर करें, क्योंकि इसी तरह पहला एडमिन अकाउंट बनाया जाता है।

यह फ़ाइल आपका SMTP पासवर्ड plain text में स्टोर करती है, इसलिए डायरेक्टरी को sudo chmod 700 /var/discourse/containers के साथ सुरक्षित करें। यह YAML फ़ाइल है, जिसका अर्थ है कि इसमें whitespace ही कॉन्फ़िगरेशन है: एक गलत जगह पर लगा key बिल्ड को विफल कर देता है और parse error के कारण आपकी साइट काम नहीं करती। एक समस्या का उल्लेख स्वयं sample फ़ाइल में किया गया है। बिना quote किए गए पासवर्ड के अंदर मौजूद # एक टिप्पणी (comment) शुरू कर देता है, इसलिए यदि पासवर्ड में यह चिन्ह हो तो उसे quote के अंदर रखें।

ईमेल वह चरण है जहाँ अधिकांश इंस्टॉलेशन रुक जाते हैं

अगस्त 2026 तक, विज़ार्ड आपको SMTP छोड़ने और इसके बजाय Discourse ID लॉगिन का उपयोग करने की अनुमति देता है, और app.yml में एक संबंधित DISCOURSE_SKIP_EMAIL_SETUP स्विच होता है, जिसे वहां ईमेल सेटअप सत्यापन को छोड़ने के रूप में वर्णित किया गया है। सॉफ़्टवेयर को पहली बार देखने के लिए इसे छोड़ना उचित है। किसी कम्युनिटी के लिए यह एक खराब विकल्प है, क्योंकि आउटबाउंड मेल के बिना कोई भी अकाउंट सक्रिय नहीं कर सकता या पासवर्ड रीसेट नहीं कर सकता।

व्यावहारिक समस्या यह है कि अधिकांश VPS प्रदाता आउटबाउंड port 25 को ब्लॉक कर देते हैं, इसलिए बॉक्स पर मौजूद एक साधारण मेल सर्वर मेल डिलीवर नहीं करेगा। port 587 पर, या implicit TLS (transport layer security) के साथ 465 पर एक authenticated relay का उपयोग करें। 465 के लिए, DISCOURSE_SMTP_FORCE_TLS: true सेट करें, जिसे sample config उस port के लिए अनुशंसित करता है। rebuild करने से पहले host से reachability का परीक्षण करें।

nc -vz smtp.example.com 587

एक सफल परिणाम वह है जिसमें अंत में succeeded! वाली एक ही लाइन दिखाई दे। यदि कोई कमांड हैंग हो जाती है और फिर time out हो जाती है, तो इसका मतलब है कि आपके VPS के बाहर जाने वाले रास्ते पर port ब्लॉक है, और कोई भी Discourse सेटिंग इसे ठीक नहीं कर सकती। ऐसे port पर जाएं जिसे आपका प्रदाता अनुमति देता है, या प्रदाता से इसे खोलने के लिए कहें।

एक बार साइट चालू हो जाने के बाद, Admin में Email पेज से एक टेस्ट मैसेज भेजें, फिर उसी पेज पर Skipped और Bounced टैब पढ़ें। ये वे टैब हैं जहाँ Discourse उन मेल को रिकॉर्ड करता है जिन्हें भेजने से उसने इनकार कर दिया या जिन्हें relay ने अस्वीकार कर दिया, और वे कारण का नाम भी बताते हैं, जो लॉग पढ़ने की तुलना में तेज़ है।

TLS: container को अपना certificate स्वयं प्राप्त करने दें

यदि Discourse ports 80 और 443 को नियंत्रित करता है, तो इसके इन-बिल्ट issuance का उपयोग करें। ऊपर दिखाई गई दो SSL template लाइनों को uncomment करें, फिर rebuild करें। यह template acme.sh को संचालित करता है, certificates को shared volume में /shared/ssl के अंतर्गत स्टोर करता है, उन्हें container के भीतर एक schedule पर renew करता है, और Discourse को HTTPS लागू करने के लिए सेट करता है।

इस प्रक्रिया के काम करने के लिए port 80 का इंटरनेट से पहुंच योग्य होना अनिवार्य है, क्योंकि HTTP challenge का उत्तर वहीं दिया जाता है। यदि firewall केवल 443 की अनुमति देता है, तो build तो पूरा हो जाएगा लेकिन certificate कभी जारी नहीं होगा। rebuild के तुरंत बाद ./launcher logs app के साथ परिणाम की जाँच करें।

क्या आपको nginx या Caddy को सामने रखना चाहिए?

यदि Discourse आपके VPS पर एकमात्र वेब सर्विस है, तो ऐसा न करें। कंटेनर पहले से ही एक ट्यून किए गए nginx को चलाता है, और एक दूसरा प्रॉक्सी एक अतिरिक्त हॉप, नवीनीकरण के लिए एक और सर्टिफिकेट और हेडर संबंधी बग्स का एक नया स्रोत जोड़ता है।

इसे तब सामने रखें जब वही VPS अन्य साइटों को भी सर्व कर रहा हो। templates सूची में templates/web.socketed.template.yml जोड़ें, दोनों expose लाइनों को कमेंट आउट करें, और दो SSL टेम्प्लेट को कमेंट आउट ही रहने दें। इसके बाद कंटेनर /var/discourse/shared/standalone/nginx.http.sock पर एक unix socket पर लिसन करता है और कोई भी पोर्ट होल्ड नहीं करता है, जिससे आपके अपने प्रॉक्सी के लिए 80 और 443 पोर्ट खाली हो जाते हैं।

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 के बाद का ट्रेलिंग कोलन nginx के unix socket सिंटैक्स का हिस्सा है, और इसके बिना sudo nginx -t कॉन्फ़िगरेशन को स्वीकार नहीं करेगा। X-Forwarded-Proto भी वैकल्पिक नहीं है। Discourse एब्सोल्यूट लिंक लिखता है, इसलिए उस हेडर के बिना यह HTTPS पेज पर http:// लिंक जारी करता है, और ब्राउज़र उन्हें मिक्स्ड कंटेंट के रूप में ब्लॉक कर देते हैं। कंटेनर के सॉकेट मोड में होने पर, TLS आपकी जिम्मेदारी बन जाता है, इसलिए Certbot on Ubuntu 24.04 and nginx का उपयोग करके होस्ट पर सर्टिफिकेट जारी करें। यदि आपने अभी तक किसी प्रॉक्सी का चयन नहीं किया है, तो the nginx, Caddy and Traefik comparison उन विकल्पों के बीच के अंतर को स्पष्ट करता है जिन्हें आप चुन सकते हैं।

Rebuilds, upgrades और वे commands जिनका आप वास्तव में उपयोग करेंगे

cd /var/discourse
./launcher rebuild app

rebuild चल रहे container को नष्ट कर देता है, app.yml से एक नया container bootstrap करता है और उसे start करता है। पूरी build प्रक्रिया के दौरान साइट offline रहती है, इसलिए प्रत्येक config बदलाव को कुछ मिनटों के scheduled downtime के रूप में देखें।

केवल env: के अंतर्गत मान बदलने के लिए इसकी आवश्यकता नहीं होती है। ./launcher destroy app && ./launcher start app पहले से build की गई image से container को फिर से बनाता है, जिसमें कुछ ही सेकंड लगते हैं। templates: या hooks: के अंतर्गत कोई भी बदलाव सीधे image को प्रभावित करता है, इसलिए इसके लिए पूर्ण rebuild की आवश्यकता होती है।

Upgrades दो तरीकों से आते हैं। Point releases को /admin/upgrade पर web interface से apply किया जाता है, जो docker_manager plugin द्वारा प्रदान किया जाता है जिसे app.yml build के दौरान clone करता है। Base image या templates में बदलाव git से आते हैं।

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

Rebuilds के दौरान छोटे servers अक्सर विफल हो जाते हैं, क्योंकि asset compilation पूरी system का memory peak होता है। यदि कोई build बीच में रुक जाती है और dmesg में Out of memory: Killed process जैसी line दिखाई देती है जो ruby process का नाम लेती है, तो इसका मतलब है कि build के दौरान memory समाप्त हो गई थी, भले ही साइट पहले ठीक चल रही थी। Swap जोड़ें और rebuild को फिर से चलाएँ।

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

logs container का output print करता है, enter उसके अंदर एक shell खोलता है, और cleanup उन containers को हटा देता है जो 24 घंटे से अधिक समय से बंद हैं। समय-समय पर cleanup चलाएँ, क्योंकि प्रत्येक rebuild एक पुराना container पीछे छोड़ देता है और छोटे VPS पर disk space चुपचाप समाप्त हो सकता है।

बैकअप, और वह फाइल जो बैकअप में शामिल नहीं होती

Admin में Backups पेज से बैकअप लें। यह आर्काइव होस्ट पर /var/discourse/shared/standalone/backups/default/ पर सेव होता है। यही कार्य शेल से भी चलाया जा सकता है।

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

discourse restore <filename> इसे रिवर्स करता है, और जब तक आप discourse enable_restore नहीं चलाते, तब तक रिस्टोर की अनुमति नहीं दी जाती। यह सुरक्षा इसलिए है ताकि कोई गलत कमांड लाइव फोरम को ओवरराइट न कर दे।

दो कमियां जिन्हें आपको स्वयं पूरा करना होगा। आर्काइव में डेटाबेस होता है, और इसमें अपलोडेड फाइलें तभी होती हैं जब बैकअप सेटिंग में अपलोड्स को शामिल करने का विकल्प ऑन हो, इसलिए भरोसा करने से पहले उस सेटिंग की जांच करें। इसमें कभी भी app.yml शामिल नहीं होता, इसलिए एक नए VPS पर रिस्टोर करने के बाद भी आपको अपना होस्टनेम और SMTP ब्लॉक सेट करना होगा, जिसका अर्थ है कि उस फाइल को भी सर्वर से बाहर कॉपी करना आवश्यक है।

आर्काइव उसी डिस्क पर रहता है जिस पर वह साइट है जिसकी यह सुरक्षा करता है, जो कि एक वास्तविक बैकअप नहीं है। इसे शेड्यूल के अनुसार कहीं और कॉपी करें।

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

एक व्यस्त फोरम के लिए RAM की लागत

Bootstrap, detected memory और CPU के आधार पर UNICORN_WORKERS और db_shared_buffers को सेट करता है, और sample config में shared buffers को कुल मेमोरी के एक चौथाई तक सीमित रखा जाता है। प्रत्येक unicorn worker एक पूर्ण Ruby process है, और Sidekiq उनके साथ background jobs चलाता है, इसलिए मेमोरी का उपयोग पंजीकृत सदस्यों की संख्या के बजाय concurrent requests के अनुसार बढ़ता है। कुछ सौ सदस्यों वाला एक शांत फोरम भारी workload नहीं है। सर्वर पर और क्या चल रहा है, यह आमतौर पर अधिक मायने रखता है, और यदि वहां कोई photo library है, तो PhotoPrism और Immich की तुलना में मापी गई RAM की न्यूनतम आवश्यकताएं आपको बताएंगी कि क्या Discourse rebuild को पूरा करने के लिए पर्याप्त headroom उपलब्ध है।

किसी लेख में दिए गए आंकड़ों के आधार पर सर्वर का आकार निर्धारित न करें, जिसमें यह लेख भी शामिल है। स्वयं मापें।

free -m
docker stats --no-stream

लगातार उपयोग में रहने वाला Swap और धीमे pages का मतलब है कि आपके पास RAM की कमी है। स्थिर मेमोरी के साथ धीमे pages का मतलब आमतौर पर कुछ और होता है, इसलिए बड़ा प्लान खरीदने से पहले ./launcher logs app पढ़ें। सर्वर के बाहर से भी एक जांच जोड़ें, क्योंकि जो फोरम रात के 3 बजे मेमोरी खत्म होने के कारण बंद हो जाता है, वह चुपचाप विफल हो जाता है: एक अलग host पर self-hosted Uptime Kuma status monitor आपके सदस्यों के बताने से पहले ही आपको सूचित कर देगा।

जब Discourse सही विकल्प न हो

Discourse एक बड़ा application है जिसे install करना कठिन है और app.yml में मौजूद हर setting के बदलाव के लिए इसे rebuild करना पड़ता है। इस मेहनत के बदले आपको बेहतरीन moderation tools और एक ऐसा search मिलता है जो archive बड़ा होने पर भी काम करता है। यदि तीस लोगों को केवल बातचीत के लिए एक जगह चाहिए, तो यह उनकी जरूरत से कहीं अधिक भारी-भरकम system है। पहले self-hosted forum software की तुलना पढ़ें, और Discourse को इसलिए चुनें क्योंकि आपको इसके features की आवश्यकता है, न कि सिर्फ इसलिए कि यह एक जाना-माना नाम है।

FAQ

क्या मैं बिना domain name के VPS पर Discourse install कर सकता हूँ?

नहीं। shipped configuration के अनुसार Discourse केवल IP address के साथ काम नहीं करेगा, इसके लिए DISCOURSE_HOSTNAME अनिवार्य है। Discourse उस hostname से absolute links बनाता है, इसलिए IP address का उपयोग करने पर links काम नहीं करेंगे और certificate जारी नहीं हो पाएगा। शुरू करने से पहले एक A record बनाएँ और dig +short forum.example.com के साथ पुष्टि करें कि यह आपके सर्वर के address पर resolve हो रहा है।

क्या installation पूरा करने के लिए SMTP configure करना जरूरी है?

अगस्त 2026 तक आप इसे छोड़ सकते हैं। setup wizard इसके बजाय Discourse ID logins का विकल्प देता है, और app.yml में एक switch है जो email setup validation को skip कर देता है। शुरुआती जाँच के बाद इसे configure जरूर करें, क्योंकि account activation और password reset ईमेल के माध्यम से ही होते हैं। port 587 या 465 पर authenticated relay का उपयोग करें, क्योंकि अधिकांश VPS providers outbound port 25 को block करते हैं।

मेरा Discourse rebuild बीच में ही क्यों fail हो गया?

इसका सामान्य कारण memory की कमी है। build के दौरान asset compilation के लिए running site की तुलना में अधिक memory की आवश्यकता होती है, इसलिए जो server forum चलाने के लिए पर्याप्त है, वह rebuild के समय fail हो सकता है। यदि dmesg में Out of memory: Killed process के साथ कोई ruby process दिखाई दे, तो swap जोड़ें (wizard का अपना swapfile 2 GB का है) और ./launcher rebuild app को फिर से चलाएँ। यदि build किसी YAML error पर रुकता है, तो यह app.yml में indentation की गलती की ओर इशारा करता है।

क्या Discourse को मेरे अपने nginx या Caddy के पीछे रखना चाहिए?

केवल तब, जब VPS पर अन्य sites भी चल रही हों। यदि सर्वर पर केवल Discourse है, तो container को ports 80 और 443 संभालने दें और अपना certificate जारी करने दें, इससे जटिलता कम रहती है। यदि मशीन साझा करनी है, तो templates/web.socketed.template.yml जोड़ें, expose lines को comment out करें, और /var/discourse/shared/standalone/nginx.http.sock पर unix socket के माध्यम से proxy करें। X-Forwarded-Proto को pass करें, अन्यथा Discourse HTTPS page पर http:// links दिखाएगा।

मैं self-hosted Discourse का backup कैसे लूँ?

Admin में Backups page का उपयोग करें, या ./launcher enter app के बाद discourse backup चलाएँ। archives host पर /var/discourse/shared/standalone/backups/default/ में सुरक्षित होते हैं। सुनिश्चित करें कि uploads को शामिल करने वाली setting enabled है, /var/discourse/containers/app.yml को archive के साथ copy करें, और दोनों को किसी अन्य मशीन पर ले जाएँ, क्योंकि site के साथ उसी disk पर रखा गया backup सर्वर failure की स्थिति में सुरक्षित नहीं रहता।