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). एका कंटेनरमध्ये PostgreSQL, Redis, Sidekiq आणि Ruby वेब सर्व्हर चालतात. बिल्ड प्रक्रियेत ॲसेट्स कंपाईल होतात, ज्यासाठी चालू असलेल्या साइटपेक्षा जास्त मेमरी लागते.
• एक वास्तविक डोमेन नाव (Real domain name). अधिकृत सॅम्पल कॉन्फिगरेशनमध्ये स्पष्टपणे नमूद केले आहे: "Discourse केवळ IP नंबरवर काम करणार नाही."
• आउटबाउंड मेल मार्ग (Outbound mail path). खाते सक्रिय करणे, पासवर्ड रीसेट करणे, ॲडमिन आमंत्रणे आणि डायजेस्ट मेल हे सर्व SMTP (Simple Mail Transfer Protocol) द्वारे पाठवले जातात.
• होस्टवर पोर्ट 80 आणि 443 मोकळे असणे आवश्यक आहे, जोपर्यंत तुम्ही मुद्दाम Discourse ला आधीच कार्यरत असलेल्या प्रॉक्सीच्या मागे ठेवत नाही.

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

अधिकृत इन्स्टॉलेशन दस्तऐवजानुसार किमान 1 GB RAM (swap सह) आणि 10 GB डिस्कची आवश्यकता आहे, तर शिफारस केलेली क्षमता 2 GB RAM आणि 20 GB डिस्क अशी आहे. पहिली संख्या ही केवळ इन्स्टॉलर पूर्ण होण्यासाठी आवश्यक आहे, ती संख्या नाही ज्यावर तुम्ही कम्युनिटी चालवू शकाल. हा फरक महत्त्वाचा आहे कारण मेमरीचा वापर ट्रॅफिकमुळे नाही, तर बिल्ड प्रक्रियेमुळे शिखरावर पोहोचतो.

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

तुम्ही वापरणार असलेल्या होस्टनेमसाठी एक A record तयार करा आणि त्यानंतर सर्व्हरवरूनच त्याची खात्री करा.

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

दोन्ही कमांड्सनी एकच पत्ता दर्शवला पाहिजे. हे दोन्ही पत्ते जुळणे आवश्यक आहे, कारण सेटअप विझार्ड तुमच्या होस्टनेमवर कनेक्शन टेस्ट रन करतो. जर रेकॉर्ड अजूनही जुन्या पत्त्याकडे निर्देश करत असेल, तर ही टेस्ट अपयशी ठरते. तुम्ही दोन मिनिटांपूर्वी तयार केलेले रेकॉर्ड अजूनही कॅशेमध्ये असू शकते, त्यामुळे विझार्डशी संघर्ष करण्याऐवजी जुन्या TTL (time to live) कालावधीची वाट पहा.

हे रेकॉर्ड CDN द्वारे प्रॉक्सी करायचे आहे की नाही, याचा निर्णय आताच घ्या. प्रॉक्सी केलेले रेकॉर्ड तुमचा सर्व्हर पत्ता लपवते. अशा स्थितीत कंटेनरची प्रमाणपत्र विनंती (certificate request) अपयशी ठरते, कारण ACME (automatic certificate management environment) चॅलेंजला Discourse ऐवजी प्रॉक्सी उत्तर देते. पहिल्या इन्स्टॉलेशनसाठी रेकॉर्ड '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 हे एक पातळ रॅपर (wrapper) आहे. हे discourse/setup-wizard:release ला होस्ट नेटवर्क आणि माउंट केलेल्या Docker socket सह कंटेनर म्हणून चालवते, जेणेकरून विझार्ड कॉन्फिगर करत असलेल्या मशीनची तपासणी करू शकेल. हे होस्टनेम आणि ॲडमिन ईमेल पत्ते विचारते, त्यानंतर SMTP ब्लॉकबद्दल माहिती घेते. हे containers/app.yml लिहिते आणि त्यानंतर पुन्हा बिल्ड (rebuild) करते.

सुरू करण्यापूर्वी दोन गोष्टी जाणून घेणे महत्त्वाचे आहे. जर मशीनमध्ये मेमरी कमी असेल आणि स्वॅप (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 वर हा बिल्ड पूर्ण होण्यासाठी काही मिनिटे लागतात आणि पहिला बिल्ड सर्वात संथ असतो कारण प्रत्येक ॲसेट शून्यापासून (from scratch) कंपाईल केला जातो.

जेव्हा काहीतरी चुकीचे घडते तेव्हा महत्त्वाचे असलेले फ्लॅग्स ./discourse-setup --help मध्ये सूचीबद्ध आहेत. --skip-rebuild बिल्ड न करता कॉन्फिगरेशन लिहिते आणि --skip-connection-test DNS आणि पोर्ट तपासणी वगळते. --skip-connection-test चा वापर फक्त तेव्हाच करा जेव्हा तुम्हाला चाचणी का अयशस्वी होत आहे हे आधीच माहित असेल, उदाहरणार्थ जेव्हा होस्ट तुमच्या नियंत्रणाखालील नेटवर्क फायरवॉलच्या मागे असतो.

पहिली रीबिल्ड करण्यापूर्वी 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 ही स्वल्पविरामाने वेगळी केलेली यादी आहे. यातील पत्ते पहिल्या साइनअपवर आपोआप ॲडमिन बनतात. तुमचा स्वतःचा पत्ता तिथे टाका आणि त्याद्वारे नोंदणी करा, कारण अशा प्रकारेच पहिले ॲडमिन खाते तयार होते.

ही फाईल तुमचा SMTP पासवर्ड प्लेन टेक्स्टमध्ये साठवते, म्हणून sudo chmod 700 /var/discourse/containers वापरून डिरेक्टरी सुरक्षित करा. ही फाईल YAML फॉरमॅटमध्ये आहे, ज्याचा अर्थ असा की व्हाईटस्पेस (whitespace) हे कॉन्फिगरेशनचा भाग आहेत: चुकीच्या पद्धतीने अलाईन केलेली की (key) बिल्ड प्रक्रियेत पार्स एरर (parse error) निर्माण करते आणि तुमची साईट सुरू होत नाही. एक अडचण सॅम्पल फाईलमध्येच नमूद केली आहे. जर पासवर्डमध्ये # असेल आणि तो पासवर्ड अवतरण चिन्हांमध्ये (quotes) नसेल, तर तो भाग कमेंट म्हणून मानला जातो. त्यामुळे, ज्या पासवर्डमध्ये # आहे, तो नेहमी अवतरण चिन्हांमध्ये लिहा.

ईमेल ही पायरी बहुतेक इन्स्टॉलेशन्समध्ये अडथळा ठरते

ऑगस्ट 2026 पासून, विझार्ड तुम्हाला SMTP वगळून त्याऐवजी Discourse ID लॉगिन वापरण्याची परवानगी देते आणि app.yml मध्ये एक संबंधित DISCOURSE_SKIP_EMAIL_SETUP स्विच आहे, ज्याचे वर्णन ईमेल सेटअप पडताळणी वगळणे असे केले आहे. सॉफ्टवेअरच्या प्राथमिक चाचणीसाठी हे वगळणे योग्य आहे. मात्र, कम्युनिटीसाठी हा एक चुकीचा पर्याय आहे, कारण आउटबाउंड मेलशिवाय कोणीही खाते सक्रिय करू शकत नाही किंवा पासवर्ड रीसेट करू शकत नाही.

व्यावहारिक समस्या अशी आहे की बहुतेक VPS प्रदाते आउटबाउंड पोर्ट 25 ब्लॉक करतात, त्यामुळे सर्व्हरवरील साधा मेल सर्व्हर संदेश पाठवू शकत नाही. पोर्ट 587 वर किंवा implicit TLS (transport layer security) सह 465 वर ऑथेंटिकेटेड रिले वापरा. 465 साठी, DISCOURSE_SMTP_FORCE_TLS: true सेट करा, ज्याची शिफारस सॅम्पल कॉन्फिगरेशनमध्ये त्या पोर्टसाठी केली आहे. रीबिल्ड करण्यापूर्वी होस्टवरून पोहोचण्यायोग्यता (reachability) तपासा.

nc -vz smtp.example.com 587

यशस्वी निकालामध्ये succeeded! वर संपणारी एकच ओळ दिसते. जर कमांड हँग होऊन टाइमआउट होत असेल, तर याचा अर्थ तुमच्या VPS च्या बाहेर जाणाऱ्या मार्गावर तो पोर्ट ब्लॉक केलेला आहे आणि कोणतीही Discourse सेटिंग हे दुरुस्त करू शकत नाही. तुमच्या प्रदात्याने परवानगी दिलेल्या पोर्टवर जा किंवा तो पोर्ट उघडण्यासाठी प्रदात्याला विनंती करा.

एकदा साइट सुरू झाली की, Admin मधील Email पेजवरून एक चाचणी संदेश पाठवा, त्यानंतर त्याच पेजवरील Skipped आणि Bounced टॅब तपासा. या टॅबमध्ये Discourse ने पाठवण्यास नकार दिलेले आणि रिलेने नाकारलेले मेल नोंदवलेले असतात. तिथे त्याचे कारणही दिलेले असते, जे लॉग वाचण्यापेक्षा अधिक जलद असते.

TLS: कंटेनरला स्वतःचे प्रमाणपत्र मिळवू द्या

जर Discourse कडे पोर्ट 80 आणि 443 चे नियंत्रण असेल, तर त्याच्या अंगभूत (built-in) प्रमाणपत्र जारी करण्याच्या सुविधेचा वापर करा. वर दर्शविलेल्या दोन SSL टेम्पलेट ओळी अनकमेंट करा आणि त्यानंतर rebuild करा. हे टेम्पलेट acme.sh चालवते, प्रमाणपत्रे /shared/ssl अंतर्गत असलेल्या शेअर केलेल्या व्हॉल्यूममध्ये साठवते, कंटेनरच्या आत ठरलेल्या वेळापत्रकानुसार त्यांचे नूतनीकरण करते आणि Discourse ला HTTPS सक्तीने वापरण्यासाठी सेट करते.

हे कार्य करण्यासाठी पोर्ट 80 इंटरनेटवरून पोहोचण्यायोग्य असणे आवश्यक आहे, कारण HTTP चॅलेंजला तिथेच उत्तर दिले जाते. जर फायरवॉलने फक्त 443 पोर्टला परवानगी दिली असेल, तर तुमची बिल्ड प्रक्रिया पूर्ण होईल पण प्रमाणपत्र कधीही जारी होणार नाही. rebuild केल्यानंतर लगेच ./launcher logs app वापरून निकालाची खात्री करा.

Nginx किंवा Caddy समोर ठेवावे का?

जर VPS वर Discourse ही एकमेव वेब सेवा असेल, तर तसे करू नका. कंटेनरमध्ये आधीच ट्यून केलेले Nginx असते. दुसरा प्रॉक्सी जोडल्यामुळे एक अतिरिक्त टप्पा (hop) वाढतो, प्रमाणपत्राचे नूतनीकरण (renewal) करावे लागते आणि हेडरशी संबंधित त्रुटींची शक्यता वाढते.

जेव्हा त्याच VPS वर इतर वेबसाइट्स चालवल्या जातात, तेव्हाच प्रॉक्सी वापरा. templates/web.socketed.template.yml ला templates यादीत जोडा, दोन्ही expose ओळी कमेंट आउट करा आणि दोन SSL टेम्पलेट्स कमेंट आउट केलेलीच ठेवा. त्यानंतर कंटेनर /var/discourse/shared/standalone/nginx.http.sock वरील unix socket वर ऐकतो (listen) आणि कोणतेही पोर्ट वापरत नाही, ज्यामुळे 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 पूर्ण (absolute) लिंक्स तयार करते, त्यामुळे त्या हेडरशिवाय ते HTTPS पेजवर http:// लिंक्स तयार करते आणि ब्राउझर त्यांना 'mixed content' म्हणून ब्लॉक करतात. कंटेनर सॉकेटवर असताना, TLS व्यवस्थापनाची जबाबदारी तुमची असते, म्हणून Certbot on Ubuntu 24.04 and nginx वापरून होस्टवर प्रमाणपत्र मिळवा. जर तुम्ही अद्याप प्रॉक्सी निवडला नसेल, तर the nginx, Caddy and Traefik comparison मध्ये तुम्ही करत असलेल्या निवडीचे फायदे-तोटे दिले आहेत.

रीबिल्ड्स, अपग्रेड्स आणि तुम्ही प्रत्यक्षात वापरणार असलेली कमांड्स

cd /var/discourse
./launcher rebuild app

rebuild चालू असलेला कंटेनर नष्ट करते, app.yml मधून नवीन कंटेनर बूटस्ट्रॅप करते आणि तो सुरू करते. संपूर्ण बिल्ड प्रक्रियेदरम्यान साइट ऑफलाइन असते, त्यामुळे प्रत्येक कॉन्फिगरेशन बदल हा काही मिनिटांचा नियोजित डाउनटाइम आहे असे समजा.

केवळ env: अंतर्गत असलेली मूल्ये बदलल्यास याची गरज नसते. ./launcher destroy app && ./launcher start app तुम्ही आधीच तयार केलेल्या इमेजमधून कंटेनर पुन्हा तयार करते, ज्याला काही सेकंद लागतात. templates: किंवा hooks: अंतर्गत केलेले कोणतेही बदल थेट इमेजमध्ये बदल घडवतात, त्यामुळे त्यासाठी पूर्ण रीबिल्ड आवश्यक असतो.

अपग्रेड्स दोन प्रकारे मिळतात. पॉइंट रिलीज /admin/upgrade वरील वेब इंटरफेसवरून लागू केले जातात, जे docker_manager प्लगइनद्वारे पुरवले जातात. हे प्लगइन app.yml बिल्ड दरम्यान क्लोन करते. बेस इमेज किंवा टेम्पलेट्समधील बदल git द्वारे येतात.

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

रीबिल्ड्सच्या वेळी लहान सर्व्हर्स निकामी होतात, कारण ॲसेट कंपायलेशन ही संपूर्ण सिस्टमची मेमरी वापरण्याची सर्वोच्च वेळ असते. जर बिल्ड मध्येच थांबला आणि dmesg मध्ये Out of memory: Killed process अशी ओळ दिसत असेल, ज्यामध्ये ruby प्रोसेसचा उल्लेख असेल, तर याचा अर्थ बिल्ड दरम्यान मेमरी संपली आहे, जरी साइट त्याआधी व्यवस्थित चालत होती. अशा वेळी swap जोडा आणि रीबिल्ड पुन्हा चालवा.

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

logs कंटेनरचे आउटपुट प्रिंट करते, enter कंटेनरच्या आत शेल उघडते आणि cleanup 24 तासांपेक्षा जास्त काळ थांबलेले कंटेनर काढून टाकते. अधूनमधून cleanup चालवा, कारण प्रत्येक रीबिल्ड एक जुना कंटेनर मागे सोडते आणि लहान VPS वरील डिस्क हळूहळू पूर्ण भरते.

बॅकअप्स आणि ज्या फाईलमध्ये बॅकअप नसतो

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 वर रिस्टोर करताना तुम्हाला तुमचे hostname आणि SMTP ब्लॉक पुन्हा सेट करावे लागतात, याचा अर्थ ती फाईल देखील सर्व्हरवरून बाहेर कॉपी करून ठेवणे आवश्यक आहे.

तसेच, ही अर्काईव्ह ज्या साईटचे संरक्षण करते त्याच डिस्कवर असते, ज्याला तांत्रिकदृष्ट्या बॅकअप म्हणता येणार नाही. त्यामुळे, शेड्यूलनुसार ती फाईल दुसऱ्या ठिकाणी कॉपी करा.

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

व्यस्त फोरमसाठी लागणारी RAM

बूटस्ट्रॅप (bootstrap) उपलब्ध मेमरी आणि CPU नुसार UNICORN_WORKERS आणि db_shared_buffers सेट करते, तर नमुना कॉन्फिगरेशनमध्ये shared buffers एकूण मेमरीच्या एक चतुर्थांश मर्यादित ठेवले आहेत. प्रत्येक unicorn वर्कर ही एक पूर्ण Ruby प्रक्रिया असते आणि Sidekiq त्यांच्यासोबत बॅकग्राउंड जॉब्स चालवते, त्यामुळे मेमरीचा वापर हा नोंदणीकृत सदस्यांच्या संख्येपेक्षा समवर्ती विनंत्यांवर (concurrent requests) अवलंबून असतो. काही शे सदस्य असलेला शांत फोरम खूप जास्त लोड निर्माण करत नाही. सर्व्हरवर इतर कोणत्या सेवा चालत आहेत हे अधिक महत्त्वाचे असते; जर तिथे फोटो लायब्ररी असेल, तर PhotoPrism आणि Immich तुलना मधील RAM चा वापर पाहून Discourse रीबिल्ड पूर्ण करण्यासाठी पुरेशी जागा शिल्लक आहे का, हे तुम्ही ठरवू शकता.

केवळ लेखातील आकड्यांवरून सर्व्हरचा आकार ठरवू नका, यात या लेखाचाही समावेश आहे. तुमच्या स्वतःच्या गरजा मोजा.

free -m
docker stats --no-stream

जर Swap सतत वापरला जात असेल आणि पेजेस हळू लोड होत असतील, तर तुमच्याकडे RAM कमी पडत आहे. मेमरीचा वापर स्थिर असूनही पेजेस हळू लोड होत असतील, तर त्याचे कारण काही वेगळे असू शकते, म्हणून मोठे प्लॅन घेण्यापूर्वी ./launcher logs app वाचा. सर्व्हरच्या बाहेरूनही तपासणी करा, कारण रात्री 3 वाजता मेमरी संपल्यामुळे बंद पडलेला फोरम शांतपणे अपयशी ठरतो: वेगळ्या होस्टवर असलेला self-hosted Uptime Kuma स्टेटस मॉनिटर तुमच्या सदस्यांना समजण्यापूर्वीच तुम्हाला याची माहिती देईल.

जेव्हा Discourse हा चुकीचा पर्याय असतो

Discourse हे एक मोठे ॲप्लिकेशन आहे, ज्याची इन्स्टॉलेशन प्रक्रिया जड आहे आणि app.yml मध्ये असलेल्या प्रत्येक सेटिंगसाठी त्याला पुन्हा बिल्ड (rebuild) करावे लागते. या खर्चाच्या बदल्यात तुम्हाला उत्तम मॉडरेशन टूल्स आणि मोठ्या आर्काइव्हमध्येही प्रभावीपणे काम करणारी सर्च सुविधा मिळते. जर तीस लोकांच्या गटाला फक्त गप्पा मारण्यासाठी जागा हवी असेल, तर त्यांच्या गरजेपेक्षा हे खूप मोठे साधन आहे. प्रथम self-hosted फोरम सॉफ्टवेअरची तुलना वाचा आणि Discourse निवडा कारण तुम्हाला त्याच्या वैशिष्ट्यांची गरज आहे, केवळ ते नाव तुम्हाला आधीपासून माहित आहे म्हणून नाही.

FAQ

मी डोमेन नावाशिवाय VPS वर Discourse इन्स्टॉल करू शकतो का?

नाही. Discourse च्या कॉन्फिगरेशननुसार ते केवळ IP ॲड्रेसवर चालत नाही, त्यासाठी DISCOURSE_HOSTNAME आवश्यक आहे. Discourse त्या होस्टनेमवरून पूर्ण लिंक्स तयार करते, त्यामुळे IP ॲड्रेस वापरल्यास लिंक्स तुटतात आणि प्रमाणपत्र मिळवण्यात (certificate issuance) अडथळा येतो. सुरुवात करण्यापूर्वी एक A record तयार करा आणि dig +short forum.example.com वापरून ते तुमच्या सर्व्हरच्या ॲड्रेसवर रिझॉल्व्ह होत असल्याची खात्री करा.

इन्स्टॉलेशन पूर्ण करण्यासाठी SMTP कॉन्फिगर करणे आवश्यक आहे का?

ऑगस्ट 2026 पासून तुम्ही हे वगळू शकता. सेटअप विझार्ड आता Discourse ID लॉगिनचा पर्याय देतो आणि app.yml मध्ये ईमेल सेटअप व्हॅलिडेशन वगळण्यासाठी एक स्विच उपलब्ध आहे. प्राथमिक तपासणीनंतर मात्र ते कॉन्फिगर करा, कारण अकाउंट ॲक्टिव्हेशन आणि पासवर्ड रीसेट ईमेलद्वारेच केले जातात. पोर्ट 587 किंवा 465 वर ऑथेंटिकेटेड रिले वापरा, कारण बहुतेक VPS प्रोव्हायडर्स आउटबाउंड पोर्ट 25 ब्लॉक करतात.

माझे Discourse रीबिल्ड मध्येच का थांबले?

बहुतेकदा मेमरीच्या कमतरतेमुळे असे घडते. बिल्ड दरम्यान ॲसेट कंपायलेशनसाठी चालू असलेल्या साइटपेक्षा जास्त मेमरी लागते, त्यामुळे जी मशीन फोरम चालवण्यासाठी पुरेशी आहे, ती रीबिल्ड करताना अपयशी ठरू शकते. जर dmesg मध्ये Out of memory: Killed process द्वारे ruby प्रोसेस दिसत असेल, तर स्वॅप (swap) जोडा (विझार्डचा स्वतःचा स्वॅपफाइल 2 GB चा असतो) आणि पुन्हा ./launcher rebuild app चालवा. जर बिल्ड YAML एररमुळे थांबत असेल, तर app.yml मधील इंडेंटेशनमध्ये चूक असू शकते.

Discourse माझ्या स्वतःच्या Nginx किंवा Caddy च्या मागे असावे का?

केवळ तेव्हाच, जेव्हा VPS वर इतर साइट्स देखील होस्ट केलेल्या असतील. जर सर्व्हरवर फक्त Discourse असेल, तर कंटेनरला पोर्ट 80 आणि 443 वापरू द्या आणि ते स्वतःचे प्रमाणपत्र मिळवेल, ज्यामुळे गुंतागुंत कमी होते. मशीन शेअर करायची असल्यास, templates/web.socketed.template.yml जोडा, expose ओळी कमेंट करा आणि /var/discourse/shared/standalone/nginx.http.sock वरील unix socket कडे प्रॉक्सी करा. X-Forwarded-Proto पास करा, अन्यथा Discourse HTTPS पेजवर http:// लिंक्स तयार करेल.

मी स्वतः होस्ट केलेल्या Discourse चा बॅकअप कसा घेऊ?

ॲडमिनमधील बॅकअप पेज वापरा किंवा ./launcher enter app नंतर discourse backup चालवा. आर्काइव्ह्ज होस्टवर /var/discourse/shared/standalone/backups/default/ येथे सेव्ह होतात. अपलोड्स समाविष्ट करण्याचे सेटिंग चालू असल्याची खात्री करा, /var/discourse/containers/app.yml फाईल आर्काइव्हसोबत कॉपी करा आणि दोन्ही दुसऱ्या मशीनवर हलवा, कारण साइटच्याच डिस्कवर असलेला बॅकअप सर्व्हर फेल्युअरच्या वेळी सुरक्षित राहत नाही.