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

शुरू करने से पहले दो व्यवहारों के बारे में जानना उपयोगी है। यदि मशीन में मेमोरी कम है और कोई स्वैप नहीं है, तो विज़ार्ड रुक जाता है और इसे बनाने का विकल्प देता है: रैपर तब 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 को पढ़ें

विज़ार्ड एक ऐसी फ़ाइल बनाता है जिसे अब आपको ही मैनेज करना है। इसे 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) के साथ विफल हो जाएगा और आपकी साइट नहीं चलेगी। एक समस्या का उल्लेख सैंपल फ़ाइल में ही किया गया है। यदि पासवर्ड में # हो और वह अनकोटेड (unquoted) हो, तो वह एक कमेंट की शुरुआत कर देता है। इसलिए, यदि पासवर्ड में # शामिल है, तो उसे कोट्स (quotes) के अंदर रखें।

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

अगस्त 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 सेट करें, जिसे सैंपल कॉन्फ़िगरेशन उस port के लिए अनुशंसित करता है। रीबिल्ड करने से पहले होस्ट से पहुंच (reachability) का परीक्षण करें।

nc -vz smtp.example.com 587

एक सफल परिणाम वह है जिसमें एक ही लाइन हो जो succeeded! पर समाप्त हो। एक कमांड जो हैंग हो जाती है और फिर टाइम आउट हो जाती है, इसका मतलब है कि आपके 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 के भीतर उन्हें निर्धारित समय पर renew करता है, और Discourse को HTTPS लागू करने के लिए सेट करता है।

इसके काम करने के लिए port 80 का internet से पहुंच योग्य होना अनिवार्य है, क्योंकि 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 के साथ सर्टिफिकेट जारी करें। यदि आपने अभी तक किसी प्रॉक्सी का चयन नहीं किया है, तो nginx, Caddy और Traefik की तुलना उस ट्रेड-ऑफ को कवर करती है जिसे आप कर रहे हैं।

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 उस image से container को फिर से बनाता है जिसे आपने पहले ही build कर लिया है, जिसमें कुछ ही सेकंड लगते हैं। 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 जैसी लाइन दिखाई देती है जो 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, detect की गई memory और CPU के आधार पर UNICORN_WORKERS और db_shared_buffers को सेट करता है, और sample config में shared buffers को कुल memory के एक चौथाई तक सीमित रखा जाता है। प्रत्येक unicorn worker एक पूर्ण Ruby process है, और Sidekiq उनके साथ background jobs चलाता है, इसलिए memory का उपयोग registered members की संख्या के बजाय concurrent requests के अनुसार बढ़ता है। कुछ सौ members वाला एक शांत फोरम भारी workload नहीं है।

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

free -m
docker stats --no-stream

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

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

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

FAQ

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

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

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

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

मेरा Discourse rebuild बीच में ही क्यों विफल हो गया?

इसका सामान्य कारण memory की कमी है। Build के दौरान asset compilation के लिए running site की तुलना में अधिक memory की आवश्यकता होती है, इसलिए जो सर्वर forum चलाने के लिए पर्याप्त है, वह rebuild के दौरान विफल हो सकता है। यदि 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 को पास करें, अन्यथा 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 enable है, /var/discourse/containers/app.yml को archive के साथ copy करें, और दोनों को किसी अन्य मशीन पर ले जाएँ, क्योंकि site वाली disk पर ही backup रखने से सर्वर failure की स्थिति में डेटा सुरक्षित नहीं रहता।