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

VPS پر Discourse انسٹال کریں: ایک container، ایک configuration فائل

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

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

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

چار تقاضے اکثر نظر انداز ہو جاتے ہیں، اور لاگ اِن صفحے تک پہنچنے سے پہلے ہی ہر ایک مسئلہ پیدا کر سکتا ہے۔

• میموری۔ ایک ہی container میں PostgreSQL، Redis، Sidekiq اور Ruby web server چلتے ہیں۔ build step assets کو compile کرتا ہے اور چلتی ہوئی site کے مقابلے میں زیادہ میموری درکار ہوتی ہے۔
• حقیقی domain name۔ فراہم کردہ sample config میں یہ بات واضح لکھی ہے: "Discourse صرف 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 ہو سکتا ہے، اس لیے wizard سے الجھنے کے بجائے پرانے TTL (time to live) کے ختم ہونے کا انتظار کریں۔

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

اگر Docker پہلے سے server پر موجود ہے اور آپ ہر step خود دیکھنا چاہتے ہیں تو یہی کام دستی طور پر کریں۔

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. کے ساتھ رک جاتا ہے، کیونکہ manual clone آپ کے لیے کچھ install نہیں کرتا۔

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

August 2026 تک discourse-setup ایک thin wrapper ہے۔ یہ discourse/setup-wizard:release کو host network اور mounted Docker socket کے ساتھ container کے طور پر چلاتا ہے، تاکہ wizard اس machine کا جائزہ لے سکے جسے وہ configure کر رہا ہے۔ یہ hostname اور administrator کے 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 میں کئی منٹ لگتے ہیں۔ پہلا build سب سے زیادہ وقت لیتا ہے، کیونکہ ہر asset کو scratch سے compile کیا جاتا ہے۔

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

پہلی 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 وہاں درج کریں اور اسی سے register کریں، کیونکہ پہلا admin account اسی طریقے سے بنتا ہے۔

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

ای میل وہ مرحلہ ہے جہاں زیادہ تر انسٹالیشن رک جاتی ہیں

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

عملی مسئلہ یہ ہے کہ زیادہ تر VPS providers outbound port 25 کو block کرتے ہیں، اس لیے server پر موجود سادہ 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

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

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

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

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

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

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

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

جب یہی VPS دوسری sites بھی serve کرے تو اسے سامنے رکھیں۔ 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 بھی اختیاری نہیں ہے۔ 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 کا موازنہ آپ کے انتخاب کے trade-offs بیان کرتا ہے۔

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، docker_manager plugin کے فراہم کردہ /admin/upgrade سے web interface کے ذریعے apply کی جاتی ہیں؛ build کے دوران app.yml اسی plugin کو clone کرتا ہے۔ Base image یا templates میں تبدیلیاں git سے آتی ہیں۔

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

Rebuild کے دوران چھوٹے servers ناکام ہو جاتے ہیں، کیونکہ 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 کو حذف کرتا ہے جو 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 پھر بھی درکار ہوگا۔ اس فائل کی بھی server سے باہر ایک copy رکھیں۔

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

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 مشترکہ buffers کو کل memory کے ایک چوتھائی تک محدود رکھتا ہے۔ ہر unicorn worker ایک مکمل Ruby process ہوتا ہے، اور Sidekiq ان کے ساتھ background jobs چلاتا ہے۔ اس لیے memory استعمال registered members کی تعداد کے بجائے concurrent requests کے مطابق بڑھتا ہے۔ چند سو members والا غیر مصروف forum بھاری workload نہیں ہوتا۔ عموماً اس بات کی زیادہ اہمیت ہوتی ہے کہ server پر اس کے علاوہ کیا چل رہا ہے۔ اگر وہ photo library ہے تو PhotoPrism اور Immich کا تقابلی جائزہ میں ناپی گئی RAM کی کم از کم سطحیں بتا دیں گی کہ آیا Discourse rebuild مکمل ہونے کے لیے کافی headroom باقی ہے۔

Article میں دی گئی کسی تعداد کی بنیاد پر server کا سائز مقرر نہ کریں، اس article کی بھی نہیں۔ اپنی environment کی پیمائش کریں۔

free -m
docker stats --no-stream

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

جب Discourse مناسب انتخاب نہیں ہے

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

FAQ

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

نہیں۔ فراہم کردہ configuration واضح کرتی ہے کہ Discourse صرف IP address کے ساتھ کام نہیں کرے گا، اور 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 درمیان میں کیوں fail ہوا؟

عام وجہ memory ہوتی ہے۔ Build کے دوران asset compilation کو چلتی ہوئی site کے مقابلے میں زیادہ memory درکار ہوتی ہے، اس لیے جو server forum کو درست طور پر serve کر رہا ہو وہ بھی 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 بھی چل رہی ہوں۔ اگر server پر صرف Discourse ہو تو container کو ports 80 اور 443 برقرار رکھنے دیں اور اپنا certificate خود جاری کرنے دیں؛ اس سے کم اجزا manage کرنے پڑتے ہیں۔ مشین share کرنے کے لیے 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 سے محفوظ نہیں رہتا جس سے بچنے کے لیے وہ بنایا گیا ہے۔