VPS پر Docker کے ساتھ Discourse انسٹال کریں

VPS پر Discourse انسٹال کریں: ایک container، ایک config file

VPS پر Discourse انسٹال کرنے کے لیے project کا اپنا installer چلائیں، مختصر wizard کے سوالات کے جواب دیں، اور build مکمل ہونے کا انتظار کریں۔ Discourse ایک single Docker container کے طور پر release ہوتا ہے، جس میں Rails application، PostgreSQL، Redis اور nginx شامل ہوتے ہیں۔ بعد میں آپ جو کچھ تبدیل کریں گے، وہ ایک ہی file، /var/discourse/containers/app.yml، میں موجود ہوتا ہے، اور ہر تبدیلی rebuild کے ذریعے site تک پہنچتی ہے۔

Official install discourse_docker ہے: ایک launcher shell script اور YAML templates کا set۔ Discourse ایسی Compose file کو support نہیں کرتا جو آپ خود لکھیں، اور container کو دستی طور پر الگ حصوں میں تقسیم کرنے کے لیے نہیں بنایا گیا۔ اگر آپ VPS پر Docker Compose کے ساتھ services چلانے کے عادی ہیں تو مختلف structure کی توقع رکھیں۔ یہاں docker compose up -d موجود نہیں ہے، اور ./launcher rebuild app ہی deploy ہے۔

Discourse شروع کرنے سے پہلے درکار چیزیں

چار تقاضے اکثر نظر انداز ہو جاتے ہیں، اور login page تک پہنچنے سے پہلے ہی ہر ایک مسئلہ پیدا کر سکتا ہے۔

• Memory۔ ایک container میں PostgreSQL، Redis، Sidekiq اور Ruby web server چلتے ہیں۔ Build step assets compile کرتا ہے اور اسے running 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 پر ports 80 اور 443 خالی ہوں، الاّ یہ کہ آپ Discourse کو پہلے سے چلنے والے proxy کے پیچھے رکھنے کا ارادہ رکھتے ہوں۔

[
  {
    "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 کی سفارش کی گئی ہے۔ پہلی row کو اس مقدار کے طور پر سمجھیں جو installer کو مکمل ہونے دیتی ہے، نہ کہ اس مقدار کے طور پر جس پر آپ community چلانا چاہتے ہیں۔ یہ فرق اہم ہے، کیونکہ memory peak traffic کے دوران نہیں بلکہ build کے دوران آتی ہے۔

تنصیب سے پہلے domain کو server کی طرف point کریں

استعمال کیے جانے والے hostname کے لیے A record بنائیں، پھر خود server سے اس کی تصدیق کریں۔

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

دونوں commands کو ایک ہی address دکھانا چاہیے۔ ان کا متفق ہونا ضروری ہے، کیونکہ setup wizard آپ کے hostname کے خلاف connection test چلاتا ہے، اور اگر record اب بھی کسی دوسرے مقام کی طرف point کر رہا ہو تو یہ test ناکام ہو جاتا ہے۔ دو منٹ پہلے بنایا گیا record اب بھی cache میں موجود ہو سکتا ہے، اس لیے setup wizard سے الجھنے کے بجائے پرانے TTL (time to live) کے ختم ہونے کا انتظار کریں۔

ابھی فیصلہ کریں کہ record کو CDN کے ذریعے proxy کیا جائے گا یا نہیں۔ Proxied record آپ کے server کا address چھپا دیتا ہے، اور اس کے بعد container کی certificate request ناکام ہو جاتی ہے، کیونکہ ACME (automatic certificate management environment) challenge کا جواب Discourse کے بجائے proxy دیتا ہے۔ پہلی تنصیب کے لیے 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

اگر server پر 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. دکھاتا ہے۔ اگر server پر Docker موجود نہ ہو تو یہ Docker is not installed. Please install Docker first. کے ساتھ رک جاتا ہے، کیونکہ دستی clone آپ کے لیے کوئی چیز install نہیں کرتا۔

سیٹ اپ wizard کیا پوچھتا ہے، اور کیا لکھتا ہے

August 2026 تک discourse-setup ایک thin wrapper ہے۔ یہ discourse/setup-wizard:release کو container کے طور پر چلاتا ہے، host network استعمال کرتا ہے، اور Docker socket mount کرتا ہے تاکہ wizard اس machine کا معائنہ کر سکے جسے وہ configure کر رہا ہے۔ یہ hostname اور admin email addresses پوچھتا ہے، پھر آپ کا SMTP block لیتا ہے۔ یہ containers/app.yml لکھتا ہے، پھر rebuild کرتا ہے۔

شروع کرنے سے پہلے دو رویوں کو سمجھنا ضروری ہے۔ اگر machine میں memory کم ہو اور swap موجود نہ ہو تو wizard رک جاتا ہے اور اسے بنانے کی پیش کش کرتا ہے۔ اس کے بعد wrapper 2 GB کا /swapfile بناتا ہے، اسے /etc/fstab میں شامل کرتا ہے، vm.swappiness = 10 کو /etc/sysctl.d/30-discourse-swap.conf میں set کرتا ہے، اور wizard دوبارہ شروع کرتا ہے۔ wizard مکمل ہونے پر یہ Rebuilding app in 5 seconds (Ctrl+C to cancel)... دکھاتا ہے اور host پر ./launcher rebuild app چلاتا ہے۔ چھوٹے VPS پر اس build میں کئی منٹ لگتے ہیں۔ پہلی بار سب سے زیادہ وقت لگتا ہے کیونکہ ہر asset کو شروع سے compile کیا جاتا ہے۔

./discourse-setup --help ان flags کی فہرست دکھاتا ہے جو کسی خرابی کے وقت اہم ہوتے ہیں۔ --skip-rebuild config کو build کیے بغیر لکھتا ہے، جبکہ --skip-connection-test DNS اور port checks چھوڑ دیتا ہے۔ --skip-connection-test صرف اس وقت استعمال کریں جب آپ پہلے سے جانتے ہوں کہ test کیوں fail ہو رہا ہے، مثلاً جب host ایسے network firewall کے پیچھے ہو جسے آپ manage کرتے ہیں۔

پہلی 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 وہ address ہے جس پر site جواب دیتی ہے، اور Discourse اسی سے اپنے links بناتا ہے۔ اس لیے غلط value سے site ایک بار load ہونے کے بعد آپ کو کسی دوسرے مقام پر بھیج سکتی ہے۔ DISCOURSE_DEVELOPER_EMAILS comma-separated list ہے، اور پہلی signup کے وقت ان addresses کو خودکار طور پر admin بنا دیا جاتا ہے۔ اس میں اپنا address شامل کریں اور اسی address سے register کریں، کیونکہ اسی طرح پہلا admin account بنتا ہے۔

فائل میں SMTP password plain text میں محفوظ ہوتا ہے، اس لیے sudo chmod 700 /var/discourse/containers کے ذریعے directory کی access محدود کریں۔ یہ YAML بھی ہے، جس کا مطلب ہے کہ whitespace configuration کا حصہ ہے۔ misaligned key parse error کے ساتھ build ناکام کر دیتی ہے اور site دستیاب نہیں رہتی۔ ایک اہم مسئلہ sample file میں خود درج ہے۔ unquoted password کے اندر موجود # comment شروع کر دیتا ہے، اس لیے جس password میں یہ شامل ہو اسے quotes میں لکھیں۔

ای میل وہ مرحلہ ہے جس پر زیادہ تر تنصیبات رک جاتی ہیں

August 2026 تک wizard آپ کو SMTP چھوڑنے اور اس کے بجائے Discourse ID سے لاگ اِن کرنے کی اجازت دیتا ہے، اور app.yml میں اسی مقصد کے لیے DISCOURSE_SKIP_EMAIL_SETUP سوئچ موجود ہے۔ وہاں اسے ای میل setup validation چھوڑنے کے طور پر بیان کیا گیا ہے۔ سافٹ ویئر کو پہلی بار دیکھنے کے لیے یہ مرحلہ چھوڑنا مناسب ہے۔ لیکن community کے لیے یہ ناقص انتخاب ہے، کیونکہ outbound mail نہ ہونے کی صورت میں کوئی بھی account activate یا password reset نہیں کر سکے گا۔

عملی مسئلہ یہ ہے کہ زیادہ تر VPS providers outbound port 25 کو block کرتے ہیں، اس لیے سرور پر موجود سادہ mail server ای میل deliver نہیں کر سکے گا۔ port 587 پر authenticated relay استعمال کریں، یا implicit TLS (transport layer security) کے ساتھ port 465 استعمال کریں۔ port 465 کے لیے DISCOURSE_SMTP_FORCE_TLS: true set کریں؛ sample config اسی port کے لیے اس setting کی سفارش کرتا ہے۔ rebuild کرنے سے پہلے host سے reachability test کریں۔

nc -vz smtp.example.com 587

درست نتیجہ ایک single line ہوتا ہے جو succeeded! پر ختم ہوتی ہے۔ اگر command hang ہونے کے بعد timeout ہو جائے تو اس کا مطلب ہے کہ آپ کے VPS سے باہر جانے والے راستے میں port block ہے؛ Discourse کی کوئی setting اس مسئلے کو حل نہیں کر سکتی۔ کسی ایسے port پر منتقل ہوں جس کی آپ کا provider اجازت دیتا ہو، یا provider سے اسے کھولنے کی درخواست کریں۔

site up ہونے کے بعد Admin کے Email page سے test message بھیجیں، پھر اسی page پر Skipped اور Bounced tabs دیکھیں۔ Discourse ان tabs میں وہ mail record کرتا ہے جسے اس نے بھیجنے سے انکار کیا، اور وہ mail بھی جسے relay نے reject کیا۔ یہ tabs وجہ بھی بتاتے ہیں، اس لیے logs پڑھنے کے مقابلے میں مسئلہ جلد معلوم ہو جاتا ہے۔

TLS: container کو اپنا certificate حاصل کرنے دیں

اگر Discourse ports 80 اور 443 کا مالک ہے تو اس کا built-in issuance استعمال کریں۔ اوپر دکھائی گئی SSL template کی دونوں lines سے comment ہٹا دیں، پھر rebuild کریں۔ یہ template acme.sh کو configure کرتا ہے، certificates کو /shared/ssl کے تحت shared volume میں محفوظ کرتا ہے، container کے اندر schedule کے مطابق انہیں renew کرتا ہے، اور Discourse کو HTTPS پر force کرتا ہے۔

اس عمل کے لیے port 80 کا internet سے reachable رہنا ضروری ہے، کیونکہ HTTP challenge کا جواب وہیں دیا جاتا ہے۔ ایسا firewall جو صرف 443 کی اجازت دیتا ہو، build کو مکمل تو کر دیتا ہے لیکن certificate کبھی issue نہیں ہوتا۔ rebuild کے فوراً بعد ./launcher logs app سے نتیجہ check کریں۔

nginx یا Caddy کو سامنے رکھنا چاہیے؟

اگر VPS پر Discourse ہی واحد web service ہے تو ایسا نہ کریں۔ container پہلے ہی tuned nginx چلاتا ہے۔ دوسرا proxy ایک اضافی hop، renew کرنے کے لیے ایک اور certificate، اور header bugs کا نیا ذریعہ شامل کرتا ہے۔

جب یہی VPS دوسری websites بھی فراہم کرے تو اسے سامنے رکھیں۔ templates list میں templates/web.socketed.template.yml شامل کریں، دونوں expose lines کو comment out کریں، اور دونوں SSL templates کو commented رکھیں۔ اس کے بعد container /var/discourse/shared/standalone/nginx.http.sock پر unix socket کے ذریعے listen کرتا ہے اور کوئی port استعمال نہیں کرتا۔ یوں آپ کے اپنے proxy کے لیے 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 کے بعد آنے والا colon nginx کے unix socket syntax کا حصہ ہے، اور اس کے بغیر sudo nginx -t configuration قبول نہیں کرتا۔ X-Forwarded-Proto بھی optional نہیں ہے۔ 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 کا موازنہ اس انتخاب کے فوائد اور نقصانات بیان کرتا ہے۔

Rebuild، upgrades اور وہ commands جو آپ عملی طور پر استعمال کریں گے

cd /var/discourse
./launcher rebuild app

rebuild چلتے ہوئے container کو ختم کرتا ہے، app.yml سے نیا container تیار کرتا ہے، اور اسے start کرتا ہے۔ پورے build کے دوران site offline رہتی ہے، اس لیے ہر configuration change کو چند منٹ کے scheduled downtime کے طور پر دیکھیں۔

صرف env: کے اندر موجود values تبدیل کرنے کے لیے یہ ضروری نہیں۔ ./launcher destroy app && ./launcher start app پہلے سے بنائی گئی image سے container دوبارہ بناتا ہے، جس میں چند seconds لگتے ہیں۔ templates: یا hooks: کے اندر کسی بھی چیز میں تبدیلی image کو تبدیل کرتی ہے، اس لیے مکمل rebuild درکار ہوتا ہے۔

Upgrades دو طریقوں سے آتی ہیں۔ Point releases web interface میں /admin/upgrade سے apply کی جاتی ہیں۔ یہ سہولت docker_manager plugin فراہم کرتا ہے، جسے build کے دوران app.yml clone کرتا ہے۔ Base image یا templates میں تبدیلیاں git سے آتی ہیں۔

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

Rebuild کے دوران چھوٹے servers اکثر fail ہوتے ہیں، کیونکہ asset compilation پورے system میں memory کا سب سے زیادہ استعمال کرتی ہے۔ اگر build درمیان میں رک جائے اور dmesg میں Out of memory: Killed process جیسی line دکھائی دے، جس میں ruby process کا نام ہو، تو build کے دوران memory ختم ہو گئی تھی، چاہے اس سے پہلے site درست چل رہی ہو۔ Swap شامل کریں اور rebuild دوبارہ چلائیں۔

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

logs container کا output دکھاتا ہے، enter اس کے اندر shell کھولتا ہے، اور cleanup ایسے containers remove کرتا ہے جو 24 hours سے زیادہ عرصے سے stopped ہیں۔ وقتاً فوقتاً cleanup چلائیں، کیونکہ ہر rebuild ایک پرانا container چھوڑ دیتا ہے اور چھوٹے VPS کی disk خاموشی سے بھر جاتی ہے۔

بیک اپس، اور وہ فائل جو بیک اپ میں شامل نہیں ہوتی

Admin کے Backups صفحے سے بیک اپ لیں۔ آرکائیو میزبان پر /var/discourse/shared/standalone/backups/default/ میں محفوظ ہوتی ہے۔ یہی کام shell سے بھی چلایا جا سکتا ہے۔

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

discourse restore <filename> اسے بحال کرتا ہے، اور جب تک آپ discourse enable_restore نہ چلائیں، restore سے انکار کیا جاتا ہے۔ یہ حفاظتی رکاوٹ اس لیے موجود ہے تاکہ کوئی غلط command فعال forum کو overwrite نہ کر دے۔

دو خلا آپ کو خود پُر کرنے ہوں گے۔ آرکائیو میں database شامل ہوتا ہے، اور uploaded files صرف اسی وقت شامل ہوتی ہیں جب uploads شامل کرنے والی backup setting فعال ہو۔ اس لیے اعتماد کرنے سے پہلے یہ setting چیک کریں۔ اس میں app.yml کبھی شامل نہیں ہوتا۔ لہٰذا fresh VPS پر restore کرنے کے لیے آپ کو اپنا hostname اور SMTP block دوبارہ درکار ہوگا، جس کا مطلب ہے کہ اس فائل کی ایک نقل سرور سے باہر بھی محفوظ کرنی ہوگی۔

آرکائیو اسی disk پر بھی موجود ہوتی ہے جس پر محفوظ کی جانے والی site چل رہی ہے۔ یہ backup نہیں ہے۔ مقررہ شیڈول کے مطابق اسے کسی دوسری جگہ منتقل کریں۔

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

RAM میں مصروف فورم کی لاگت

bootstrap جس memory اور CPU کا پتا لگاتا ہے، اسی کی بنیاد پر UNICORN_WORKERS اور db_shared_buffers کی قدریں مقرر کرتا ہے، جبکہ نمونہ configuration shared buffers کو کل memory کے ایک چوتھائی تک محدود کرتی ہے۔ ہر unicorn worker ایک مکمل Ruby process ہوتا ہے، اور Sidekiq ان کے ساتھ background jobs چلاتا ہے، اس لیے memory کا استعمال registered members کی تعداد کے بجائے بیک وقت جاری requests کے مطابق بڑھتا ہے۔ چند سو members والا غیر مصروف فورم بھاری workload نہیں ہوتا۔

سرور کا سائز کسی article میں دی گئی تعداد، حتیٰ کہ اس article میں دی گئی تعداد، کی بنیاد پر مقرر نہ کریں۔ اپنی environment کی پیمائش کریں۔

free -m
docker stats --no-stream

مسلسل swap استعمال کے ساتھ صفحات کا سست کھلنا اس بات کی علامت ہے کہ RAM کم ہے۔ اگر memory مستحکم ہو لیکن صفحات سست ہوں تو عموماً وجہ کچھ اور ہوتی ہے، اس لیے بڑا plan خریدنے سے پہلے ./launcher logs app پڑھیں۔ بیرونی host سے بھی ایک check شامل کریں، کیونکہ 3am پر memory ختم ہونے والا فورم خاموشی سے ناکام ہو سکتا ہے: الگ host پر self-hosted Uptime Kuma status monitor آپ کے members کو معلوم ہونے سے پہلے آپ کو اطلاع دے گا۔

جب Discourse غلط انتخاب ہو

Discourse ایک بڑی ایپلی کیشن ہے۔ اس کی تنصیب بھاری ہے، اور app.yml میں موجود ہر setting کے لیے rebuild cycle درکار ہوتی ہے۔ اس لاگت کے بدلے حقیقی moderation tools ملتے ہیں، اور archive بڑا ہونے پر بھی search درست طور پر کام کرتی ہے۔ تیس افراد کے لیے، جو صرف بات چیت کی جگہ چاہتے ہیں، یہ ان کی گفتگو کی ضرورت سے زیادہ بڑی ایپلی کیشن ہے۔ پہلے self-hosted forum software کا تقابلی جائزہ پڑھیں، اور Discourse کا انتخاب اس لیے کریں کہ آپ کو اس کی فراہم کردہ سہولیات درکار ہیں، نہ کہ صرف اس لیے کہ آپ اس نام سے پہلے ہی واقف تھے۔

FAQ

کیا میں domain name کے بغیر VPS پر Discourse install کر سکتا ہوں؟

نہیں۔ فراہم کردہ configuration کے مطابق Discourse صرف bare IP number کے ساتھ کام نہیں کرے گا، اور DISCOURSE_HOSTNAME درکار ہے۔ Discourse اسی hostname سے absolute links بناتا ہے، اس لیے وہاں IP address دینے سے links ٹوٹ جاتے ہیں اور certificate issuance رک جاتی ہے۔ شروع کرنے سے پہلے A record بنائیں، اور dig +short forum.example.com سے تصدیق کریں کہ یہ آپ کے server کے address پر resolve ہو رہا ہے۔

کیا install مکمل کرنے کے لیے SMTP configure کرنا ضروری ہے؟

August 2026 تک آپ اسے چھوڑ سکتے ہیں۔ setup wizard اس کے بجائے Discourse ID logins پیش کرتا ہے، اور app.yml میں email setup validation چھوڑنے کے لیے switch موجود ہے۔ پہلی آزمائش سے آگے استعمال کے لیے اسے 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 درکار ہوتی ہے، اس لیے جو server 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 بھی چل رہی ہوں۔ اگر server پر صرف Discourse ہو تو container کو ports 80 اور 443 برقرار رکھنے دیں اور اپنا certificate خود جاری کرنے دیں۔ اس سے انتظامی اجزا کم رہتے ہیں۔ اگر machine مشترک ہو تو templates/web.socketed.template.yml شامل کریں، expose lines کو comment out کریں، اور unix socket /var/discourse/shared/standalone/nginx.http.sock پر 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 فعال ہے، /var/discourse/containers/app.yml کو archive کے ساتھ copy کریں، اور دونوں کو دوسری machine پر منتقل کریں، کیونکہ site والی اسی disk پر موجود backup اس failure سے محفوظ نہیں رہتا جس سے بچاؤ کے لیے وہ بنایا گیا تھا۔