VPS پر Discourse، Flarum، NodeBB یا phpBB؟

آپ کو کون سا self-hosted forum software چلانا چاہیے؟

آج VPS (virtual private server) پر چلائے جا سکنے والے self-hosted forum software کے حقیقی اختیارات چار ہیں: Discourse، Flarum، NodeBB اور phpBB۔ اگر آپ 4 GB RAM فراہم کر سکتے ہیں اور کم از کم دو افراد moderation کے لیے دستیاب ہیں تو Discourse موزوں default انتخاب ہے۔ 1 GB RAM اور ایک moderator کی صورت میں Flarum یا phpBB چلائیں۔ ایسا پرسکون forum جسے آپ صاف اور منظم رکھ سکیں، اس forum سے بہتر ہے جسے آپ سنبھال نہ سکیں۔

Installation آسان حصہ ہے۔ ان میں سے ہر software ایک دوپہر میں چلایا جا سکتا ہے۔ forum ایک سال بعد بھی موجود رہے گا یا نہیں، اس کا فیصلہ flag queue اور mail path کرتے ہیں۔ اس لیے feature lists پڑھنے سے پہلے moderation اور email کے sections پڑھیں۔

فورم چلانے کے لیے درکار بنیادی اجزا کیا ہیں؟

فورم ایک نہیں بلکہ چار حصوں پر مشتمل ہوتا ہے: application process، ایسی database جس کا ڈیٹا application process کے ختم ہونے کے بعد بھی برقرار رہے، اپ لوڈ کیے گئے avatars اور attachments کی directory، اور mail بھیجنے کا قابلِ عمل طریقہ۔ application بدلی جا سکتی ہے۔ database نہیں بدلی جا سکتی، کیونکہ ہر post، ہر account اور ہر private message اسی میں محفوظ ہوتا ہے۔ اسی لیے ذیل کے sections میں ہر project کی منتخب کردہ database سب سے اہم نکتہ ہے۔ جب آپ سروس چھوڑنا چاہیں گے، اس دن آپ کے export کی ساخت اسی انتخاب سے طے ہوگی۔

دوسری لاگت انسانی ہے۔ public registration اور public posting کا مطلب ہے کہ bot signups شروع ہو جائیں گے، عموماً domain کے crawl میں ظاہر ہونے کے پہلے ہفتے کے اندر۔ چاروں اجزا کو محدود کیا جا سکتا ہے۔ صرف ایک project یہ workflow core میں فراہم کرتا ہے۔

Discourse: default انتخاب، اور اس کی حقیقی لاگت

Discourse، Ruby on Rails پر مبنی ہے۔ یہ ڈیٹا کے لیے PostgreSQL، cache اور job queues کے لیے Redis، اور پس منظر کے کام کے لیے Sidekiq استعمال کرتا ہے۔ معاونت یافتہ installation یہ سب کچھ ایک ہی Docker container میں رکھتی ہے، جو /var/discourse/containers/app.yml کی config file سے build ہوتا ہے۔ آپ کو یہ اجزا خود install نہیں کرنے پڑتے۔

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

اگر git اور Docker موجود نہ ہوں تو یہ script انہیں install کرتی ہے۔ پھر یہ discourse_docker کو /var/discourse میں clone کرتی ہے اور interactive discourse-setup wizard کو control دے دیتی ہے۔ wizard آپ سے hostname، admin email address اور SMTP (simple mail transfer protocol) کی تفصیلات پوچھتا ہے، app.yml لکھتا ہے، اور container build کرتا ہے۔ Ports 80 اور 443 خالی ہونے چاہییں، کیونکہ container اپنا nginx چلاتا ہے اور آپ کے لیے Let's Encrypt certificate طلب کرتا ہے۔

شائع شدہ کم از کم ضرورت 1 GB RAM ہے، swap کے ساتھ، اور اس کے علاوہ 10 GB disk space ہے۔ swap کی شرط کو لفظی طور پر سمجھیں۔ جب wizard کو لگتا ہے کہ machine کو swap درکار ہے تو setup script fallocate -l 2G /swapfile کے ذریعے 2 GB کی swapfile بناتی ہے۔ یہ swap محض اضافی چیز نہیں ہے۔ memory peak چلتی ہوئی site نہیں ہوتی۔ یہ ./launcher rebuild app ہوتا ہے، جو ہر upgrade کے دوران container کے اندر JavaScript اور CSS assets دوبارہ compile کرتا ہے۔ 1 GB کی ایسی machine پر جس میں swap نہ ہو، یہ مرحلہ درمیان میں terminate ہو جاتا ہے، rebuild screen پر کسی مفید error کے بغیر ختم ہوتی ہے، اور dmesg | tail میں Out of memory: Killed process line دکھائی دیتی ہے۔ اسے قابل اعتماد طریقے سے چلانے کے لیے 2 GB مختص کریں، اور forum مصروف ہونے کے بعد 4 GB رکھیں۔

Upgrades browser میں /admin/upgrade سے، یا shell سے چلائی جاتی ہیں:

cd /var/discourse
./launcher rebuild app

rebuild چلتے ہوئے container کو destroy کرتا ہے، app.yml سے نیا container bootstrap کرتا ہے، اور اسے start کرتا ہے۔ اس عمل میں کئی منٹ لگتے ہیں، اس لیے site اتنی دیر down رہتی ہے۔ ایک ہی container میں اس صورت حال سے بچنے کا کوئی طریقہ نہیں ہے۔ data.yml اور web_only.yml samples استعمال کرکے دو containers میں تقسیم کرنے سے web container rebuild ہونے کے دوران PostgreSQL چلتا رہتا ہے۔ جب users downtime محسوس کرنے لگیں تو یہ طریقہ اختیار کرنا مفید ہوتا ہے۔

Discourse کی RAM کی اصل ضرورت moderation کے مرحلے میں نمایاں ہوتی ہے۔ نئے accounts trust level 0 سے شروع ہوتے ہیں۔ ان پر links post کرنے کی تعداد اور رفتار کی سخت حدود ہوتی ہیں، پھر پڑھنے اور شرکت کرنے کے ساتھ ان کا trust level بڑھتا ہے۔ Flags ایک review queue میں پہنچتے ہیں، جہاں یہ record ہوتا ہے کہ کس نے کس flag پر کارروائی کی۔ Akismet اور StopForumSpam integrations official plugins ہیں۔ باقی تین کے لیے یہ functionality add-ons سے assemble کرنی پڑتی ہے۔

Discourse میں منتقلی کی سب سے مضبوط خصوصیت باہر سے اندر migration ہے۔ source tree میں موجود script/import_scripts/ directory میں ساٹھ سے زیادہ importers ہیں۔ ان میں phpbb3.rb، vbulletin.rb، xenforo.rb، vanilla.rb، mybb.rb، flarum_import.rb، ایک nodebb directory، اور mailing list archives کے لیے mbox importer شامل ہیں۔ یہ Ruby scripts ہیں جنہیں آپ پرانے database کی copy پر container کے اندر چلاتے ہیں۔ یہ عمل سست ہے، مگر اس کے لیے maintenance جاری رہتی ہے۔

Discourse سے باہر migration اس کا کمزور پہلو ہے۔ ./launcher enter app کے بعد discourse backup چلانے سے ایک .tar.gz بنتا ہے، جس میں PostgreSQL dump اور uploads directory شامل ہوتے ہیں۔ اسے کوئی دوسرا Discourse restore کر سکتا ہے۔ کوئی اور software اسے read نہیں کرتا، اس لیے Discourse چھوڑنے کا مطلب ہے کہ آپ کو اس dump کے خلاف خود SQL لکھنا ہوگا۔ 50,000 posts import کرنے سے پہلے طے کر لیں کہ آپ اس پابندی کے ساتھ رہ سکتے ہیں۔

Flarum: ہلکا PHP فورم

Flarum ایک عام PHP ایپلی کیشن ہے: nginx یا Apache کے پیچھے php-fpm، MySQL یا MariaDB database، اور disk پر files۔ دستاویزی requirements میں curl، dom، fileinfo، gd، json، mbstring، openssl، pdo_mysql، tokenizer اور zip extensions کے ساتھ PHP 7.3 یا اس کے بعد کا ورژن شامل ہے۔ اس کے علاوہ MySQL 5.6+ (یا 8.0.23+) یا MariaDB 10.0.5+ درکار ہے۔ Ubuntu 24.04 میں PHP 8.3 شامل ہے، جو اس کم از کم requirement سے زیادہ ہے۔

اس فہرست میں pdo_mysql کو نوٹ کریں۔ Flarum، PostgreSQL کو support نہیں کرتا اور SQLite کو بھی support نہیں کرتا۔ اگر آپ single-file database چاہتے ہیں تو نیچے phpBB موجود ہے۔

sudo apt update
sudo apt install -y nginx mariadb-server composer php-fpm php-mysql php-curl php-gd php-mbstring php-xml php-zip
sudo install -d -m 755 /srv/flarum
cd /srv/flarum
sudo COMPOSER_ALLOW_SUPERUSER=1 composer create-project flarum/flarum:^1.8.0 .
sudo chown -R www-data:www-data /srv/flarum

Web server کو /srv/flarum/public کی طرف point کریں، /srv/flarum کی طرف نہیں۔ Application code، config file اور database password، سب public سے ایک directory اوپر موجود ہوتے ہیں۔ اس لیے document root کو ایک level زیادہ اوپر رکھنے سے جو بھی درخواست کرے، اسے آپ کی credentials مل سکتی ہیں۔ Apache پر mod_rewrite اور AllowOverride All بھی درکار ہیں تاکہ فراہم کردہ .htaccess مؤثر ہو۔ nginx پر فراہم کردہ .nginx.conf کو اپنے server block کے اندر شامل کریں۔ اس کے بعد domain کھولیں۔ Flarum کا اپنا installer database اور admin account کی معلومات طلب کرے گا۔

اگست 2026 تک versions یہ ہیں: 1.8.17 موجودہ stable release ہے، جو جون 2026 میں جاری ہوئی، اور 2.0 release candidate 5 پر ہے۔ نئی community کو release candidate پر شروع نہ کریں۔ 2.0 آنے پر extensions کو load ہونے سے پہلے update کرنا ہوگا، اور یہی وہ upgrade ہے جو آپ کا پورا weekend لے سکتا ہے۔

اس کا footprint کم ہے۔ چند php-fpm workers، MariaDB کے لیے چند سو MB، اور static files کافی ہیں۔ نئی community 1 GB پر چل سکتی ہے۔

Moderation اس کی واضح کمزوری ہے۔ Core آپ کو reports اور per-group permissions فراہم کرتا ہے۔ Approval queues اور spam blocking extensions سے آتے ہیں، زیادہ تر FriendsOfFlarum collection سے۔ انہیں composer require کے ذریعے install کریں اور admin panel میں فعال کریں۔ یہ آج کام کرتا ہے۔ لیکن آپ phpBB یا Discourse کے مقابلے میں چھوٹے volunteer ecosystem پر زیادہ انحصار کر رہے ہیں۔ اگر کوئی extension maintain نہ ہو رہی ہو تو وہ آپ کے اگلے core upgrade کو روک دیتی ہے، کیونکہ composer اسے نئے version کے ساتھ resolve کرنے سے انکار کر دیتا ہے۔

Data باہر نکالنا آسان ہے: mysqldump database اور assets directory کو copy کریں۔ Data اندر لانا زیادہ مشکل ہے۔ Discourse، Flarum سے Discourse کی سمت کے لیے flarum_import.rb فراہم کرتا ہے، جس سے معلوم ہوتا ہے کہ data flow عموماً کس سمت ہوتا ہے۔ phpBB کو Flarum میں import کرنے کے لیے first-party tool کے بجائے community extensions استعمال ہوتی ہیں۔ اس لیے واحد copy پر اعتماد کرنے سے پہلے کسی copy کے خلاف اس کا test کریں۔

NodeBB: realtime پوسٹنگ، اور اس کے ساتھ آنے والی اضافی لاگت

NodeBB، Node.js پر مبنی ہے۔ یہ نئی پوسٹس websockets کے ذریعے کھلے ہوئے browsers کو بھیجتا ہے، اس لیے فعال thread refresh کے بغیر update ہو جاتا ہے۔ NodeBB منتخب کرنے کی بنیادی وجہ یہی ہے۔ README میں Node.js 22 یا اس کے بعد کا ورژن اور MongoDB 5+ یا Redis 7.2+ میں سے کسی ایک کا تقاضا کیا گیا ہے، جبکہ source tree میں PostgreSQL driver تیسرے آپشن کے طور پر شامل ہے۔

اس جملے میں بنیادی database کے طور پر Redis کا انتخاب مسئلہ بن سکتا ہے۔ Redis dataset کو memory میں رکھتا ہے، اس لیے forum کے ساتھ RAM کی ضرورت بھی بڑھتی ہے؛ یہ مستقل نہیں رہتی۔ MongoDB یا PostgreSQL ڈیٹا disk پر رکھتے ہیں اور صرف زیرِ استعمال ڈیٹا cache کرتے ہیں۔ Redis صرف اسی صورت میں منتخب کریں جب آپ اس کی واضح وجہ بتا سکیں۔

Ubuntu 24.04 میں Node.js 18 کے packages شامل ہیں، جو مطلوبہ کم از کم ورژن سے کم ہے؛ اس لیے پہلے موجودہ runtime انسٹال کریں۔

curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt install -y nodejs git build-essential
sudo adduser --system --group --home /srv/nodebb nodebb
sudo -u nodebb git clone -b v4.x https://github.com/NodeBB/NodeBB.git /srv/nodebb
cd /srv/nodebb
sudo -u nodebb ./nodebb setup

./nodebb setup interactive ہے۔ یہ پوچھتا ہے کہ کون سا database استعمال کرنا ہے اور اس تک کیسے پہنچنا ہے، پھر admin account بناتا ہے اور port منتخب کرتا ہے، جس کی default قدر 4567 ہے۔ NodeBB npm start کے ساتھ start نہیں ہوتا۔ ./nodebb script interface ہے، جبکہ ./nodebb log وہ جگہ ہے جہاں output جاتا ہے۔

./nodebb start daemon کو background میں چلاتا ہے، جو reboot ہونے والی machine کے لیے درست نہیں۔ اس کے بجائے loader کو systemd کے تحت foreground میں چلائیں۔

[Unit]
Description=NodeBB
After=network.target

[Service]
Type=simple
User=nodebb
WorkingDirectory=/srv/nodebb
ExecStart=/usr/bin/env node loader.js --no-daemon
Restart=on-failure

[Install]
WantedBy=multi-user.target

--no-daemon وہ حصہ ہے جسے اکثر نظرانداز کر دیا جاتا ہے۔ اس کے بغیر loader fork ہو جاتا ہے اور parent exit کر جاتا ہے، اس لیے systemctl status nodebb unit کو dead ظاہر کرتا ہے، جبکہ curl localhost:4567 پھر بھی requests کا جواب دیتا رہتا ہے؛ نتیجتاً systemctl stop nodebb کچھ بھی stop نہیں کرتا۔ reverse proxy کے پیچھے websocket upgrade headers کو آگے منتقل کرنا ضروری ہے۔ اگر nginx block میں proxy_set_header Upgrade $http_upgrade; اور proxy_set_header Connection "upgrade"; موجود نہ ہوں تو forum load ہو جاتا ہے، browser console میں ناکام socket.io requests بھر جاتی ہیں، اور reader کے refresh کرنے تک نئی پوسٹس ظاہر نہیں ہوتیں۔

Moderation کے لحاظ سے NodeBB، Flarum اور Discourse کے درمیان ہے۔ Admin panel میں flag queue، ہر category کے لیے الگ privileges اور reputation system موجود ہے۔ Anti-spam سہولت community plugins، مثلاً nodebb-plugin-spam-be-gone، سے آتی ہے، جو Akismet اور StopForumSpam کو مربوط کرتا ہے۔

Backups دستی طور پر لینے پڑتے ہیں، اور اس کا ذکر عموماً اس دن تک نہیں ہوتا جب backup کی ضرورت پڑ جائے۔ ./nodebb CLI میں backup command موجود نہیں ہے۔ Database کو خود mongodump یا pg_dump سے dump کریں، اور اس کے ساتھ public/uploads directory اور config.json بھی copy کریں۔ config.json میں database credentials اور site URL موجود ہوتے ہیں، اس لیے اس کے بغیر restore کرنے کا نتیجہ صرف نئی installation ہوتا ہے۔ First-party importer بھی موجود نہیں ہے۔ nodebb-plugin-import community project ہے جو موجودہ رفتار کے ساتھ update نہیں ہوا، جبکہ Discourse کے ساتھ NodeBB importer شامل ہے؛ لہٰذا یقینی طور پر کام کرنے والا migration راستہ Discourse تک جاتا ہے۔

phpBB: چھوٹا، سادہ، مگر اب بھی قابلِ استعمال

phpBB پرانا ہے، اور یہی اس کے حق میں دلیل ہے۔ 3.3 سیریز PHP 7.2.0 سے لے کر PHP 8.3 تک چلتی ہے، اور MySQL 4.1.3+، MariaDB 5.1+، PostgreSQL 8.3+، SQLite 3.6.15+، MS SQL Server اور Oracle کو سپورٹ کرتی ہے۔ اسے json، mbstring، XML سپورٹ اور getimagesize() فنکشن کا فعال ہونا درکار ہے۔

SQLite ہی وہ وجہ ہے جس کی بنا پر یہ اس فہرست میں شامل ہے۔ SQLite کے ساتھ forum، PHP فائلوں کی ایک directory اور ایک database file پر مشتمل ہوتا ہے۔ database server کی ضرورت نہیں ہوتی، tuning کے لیے کچھ نہیں ہوتا، اور backup کے لیے بھی کوئی اضافی چیز نہیں ہوتی۔ ایسے 1 GB VPS پر جو پہلے ہی کوئی اور سروس چلا رہا ہو، یہ فرق واقعی اہم ہے۔ چھوٹی community کے لیے SQLite استعمال کریں، اور جب بیک وقت posting بڑھنے لگے تو MySQL پر منتقل ہو جائیں، کیونکہ SQLite writes کو serialise کرتا ہے اور posts ایک دوسرے کے پیچھے queue ہونے لگتی ہیں۔

composer step یا container کی ضرورت نہیں ہے۔ PHP کے ساتھ web server install کریں، archive کو unpack کریں، اور browser installer چلائیں۔ مکمل stack setup کی وضاحت Ubuntu 24.04 پر standard LAMP stack میں کی گئی ہے۔

sudo apt update
sudo apt install -y apache2 php libapache2-mod-php php-mysql php-mbstring php-xml php-gd unzip

phpbb.com سے موجودہ 3.3 release download کریں، اسے اس directory میں unpack کریں جسے آپ کا vhost serve کرتا ہے، پھر installer جن paths میں لکھے گا انہیں web server user کے لیے writable بنائیں۔

sudo chown -R www-data:www-data /srv/phpbb
sudo chmod 660 /srv/phpbb/config.php
sudo chmod -R 770 /srv/phpbb/store /srv/phpbb/cache /srv/phpbb/files /srv/phpbb/images/avatars/upload

official instructions میں 666 اور 777 permissions بتائی گئی ہیں۔ یہ shared hosting کے لیے ہیں، جہاں آپ اس user کو control نہیں کرتے جس کے تحت PHP چلتا ہے۔ اپنے VPS پر آپ اسے control کرتے ہیں، اس لیے ownership www-data کو دیں اور باقی سب کو رسائی نہ دیں۔ Apache کی ایک تفصیل اکثر مسئلہ بنتی ہے: Ubuntu کی config صرف اپنے default document root کے اندر access دیتی ہے، اس لیے /srv/phpbb کی طرف اشارہ کرنے والے vhost میں Require all granted کے ساتھ matching <Directory> block بھی درکار ہوتا ہے، ورنہ phpBB تک پہنچنے سے پہلے ہی ہر request 403 Forbidden واپس کرتی ہے۔ browser میں /install/index.php پر setup مکمل کریں، پھر config.php کو واپس 640 پر set کریں اور install/ directory delete کر دیں۔ phpBB اس directory کے موجود رہنے تک اس کے بارے میں warning دیتا رہے گا۔

Spam phpBB کا معروف مسئلہ ہے، اور اسے حل کیا جا سکتا ہے۔ registration form ایک متوقع URL (ucp.php?mode=register) پر موجود ہوتا ہے، اس لیے domain crawl ہونے کے چند دنوں میں bots اسے تلاش کر لیتے ہیں۔ مؤثر حل admin panel میں Spambot countermeasures کے تحت موجود ہے: anti-spam method کو Question and Answer پر set کریں، اور ایسا سوال لکھیں جس کا جواب صرف آپ کی community کا کوئی رکن دے سکے۔ Image CAPTCHAs (completely automated public Turing tests) حل کرنے والی services انہیں فی ہزار معمولی قیمت پر فراہم کرتی ہیں۔ اپنے subject کے بارے میں سوال اس طریقے سے حل نہیں کیا جا سکتا۔

migration کے لیے phpBB سب سے زیادہ سپورٹ رکھنے والا source بھی ہے۔ Discourse کا phpbb3.rb اس پورے مضمون میں سب سے زیادہ استعمال ہونے والا importer ہے، اور phpBB support forums پر بیس سال کے جوابات موجود ہیں۔ منتقلی کے لیے mysqldump استعمال کریں، یا SQLite file copy کر لیں۔ جو چیز منتقل نہیں ہوتی وہ آپ کے styles اور extensions ہیں۔

فورم کے اندراج کی ای میلز کبھی موصول کیوں نہیں ہوتیں؟

ان چاروں پر رجسٹریشن کی تکمیل confirmation email سے مشروط ہے۔ اگر یہ ای میل موصول نہ ہو تو اکاؤنٹ کبھی فعال نہیں ہوتا، اور logs میں ایسا signup دکھائی دیتا ہے جو بس رک گیا ہو۔ outbound deliverability اس بات کا فیصلہ کرتی ہے کہ فورم کام کرے گا یا نہیں، اس لیے اسے installation کا حصہ سمجھیں۔

• زیادہ تر VPS providers outbound port 25 کو بطور ڈیفالٹ block کرتے ہیں، اس لیے براہِ راست delivery کی کوشش کرنے والا مقامی Postfix کہیں نہیں پہنچتا۔ mail log میں connect to gmail-smtp-in.l.google.com[...]:25: Connection timed out دکھائی دیتا ہے۔
• بالکل نیا IP address بھیجنے کی reputation نہیں رکھتا، اس لیے کامیاب delivery بھی spam folder میں پہنچ سکتی ہے۔ confirmation link کے معاملے میں یہ موصول نہ ہونے کے برابر ہے۔
• DNS میں SPF (sender policy framework) اور DKIM (domainkeys identified mail) records شائع نہ ہوں تو بڑے providers پیغام کو براہِ راست reject کر دیتے ہیں۔ Google کا rejection پیغام 550 5.7.26 Unauthenticated email from example.com is not accepted due to domain's DMARC policy ہے۔ DMARC (domain-based message authentication, reporting and conformance) اب بڑی تعداد میں ای میل بھیجنے والے ہر فرد یا ادارے سے متوقع ہے۔

عملی حل relay ہے۔ فورم کی SMTP settings کو port 587 پر کسی transactional mail provider کی طرف بھیجیں، provider کے فراہم کردہ SPF، DKIM اور DMARC records شائع کریں، اور mail.example.com جیسی subdomain سے ای میل بھیجیں تاکہ فورم کی reputation آپ کی ذاتی mail سے الگ رہے۔ mail server خود چلانا ممکن ہے، اور VPS پر مکمل self-hosted mail server میں اس کا طریقہ بیان کیا گیا ہے، لیکن فورم launch کرنے والا ہفتہ deliverability سیکھنے کے لیے مناسب وقت نہیں۔

فورم کا اعلان کرنے سے پہلے test کریں۔ Discourse میں container کے اندر سے:

cd /var/discourse
./launcher enter app
rake emails:test[you@example.com]

یہ task SMTP connection کی جانچ کرتا ہے اور ایک پیغام بھیجتا ہے۔ credentials غلط ہوں تو یہ failure کی وجہ بھی بتاتا ہے، عموماً Net::SMTPAuthenticationError کے طور پر۔ phpBB میں admin panel کے Client communication حصے کے تحت اس کا مساوی test موجود ہے۔ Flarum اور NodeBB کے لیے کسی بڑے provider کے حقیقی mailbox کے خلاف عارضی account register کریں اور موصول ہونے والے پیغام کے raw headers پڑھیں۔ spf=pass اور dkim=pass کا Authentication-Results header میں موجود ہونا وہ نتیجہ ہے جس کی آپ کو تلاش ہے۔

Discourse کے لیے ایک اہم نکتہ ہے۔ August 2026 تک setup wizard آپ کو SMTP چھوڑ کر Discourse ID استعمال کرنے کی اجازت دیتا ہے۔ اس صورت میں لوگوں کو emailed link کے بجائے external account سے sign in کرایا جاتا ہے۔ اس طرح relay کے بغیر launch کیا جا سکتا ہے۔ تاہم اس سے notification mail یا password resets دستیاب نہیں ہوتے، اس لیے community کے بڑھنے سے پہلے SMTP ضرور configure کریں۔

Forum کو TLS کے پیچھے کیسے رکھا جاتا ہے؟

Flarum اور phpBB عام virtual hosts ہیں، اس لیے آپ کے پہلے سے چلنے والے web server پر certbot کافی ہے۔ NodeBB اور Discourse مختلف ہیں: یہ applications مقامی ports پر listening کرتی ہیں، اور سامنے موجود کسی component کو TLS (transport layer security) terminate کرکے hostname کے مطابق traffic route کرنا ہوتا ہے۔ اگر forum اسی server پر دیگر services کے ساتھ چلتا ہے تو سب کے سامنے ایک ہی reverse proxy رکھیں۔ متعدد Docker Compose apps کے سامنے Traefik اسی مقصد کے لیے ہے۔

Discourse بطور default ports 80 اور 443 پر خود قبضہ کرتا ہے۔ یہ اپنے nginx اور اپنی Let's Encrypt template استعمال کرتا ہے۔ اسے موجودہ proxy کے پیچھے رکھنے کے لیے app.yml میں ترمیم کریں، templates/web.letsencrypt.ssl.template.yml line ہٹا دیں، exposed ports تبدیل کریں تاکہ container صرف مقامی address پر listen کرے، پھر ./launcher rebuild app چلائیں۔ بعد میں یہ تبدیلی کرنے سے rebuild اور چند منٹ کا downtime درکار ہوتا ہے۔ اس لیے installation سے پہلے فیصلہ کریں، بعد میں نہیں۔

آپ کی community کے سائز کے لیے کون سا forum موزوں ہے؟

فیصلے کا اصول features نہیں بلکہ لوگوں کی تعداد ہے۔

• چند سو members سے کم، ایک moderator، اور 1 GB RAM: SQLite پر phpBB استعمال کریں، یا اگر آپ جدید interface چاہتے ہیں اور MariaDB چلا سکتے ہیں تو Flarum استعمال کریں۔ دونوں ایک واحد PHP application ہیں، اس لیے patches برقرار رکھنا آسان رہتا ہے۔
• بڑھتی ہوئی community، دو یا اس سے زیادہ moderators، اور 4 GB RAM: Discourse استعمال کریں۔ جیسے ہی moderation ایک شخص کی ذہنی گنجائش سے باہر ہونے لگے، trust levels اور review queue اضافی وسائل کے قابل ہو جاتے ہیں۔
• اگر آپ کو مستقل threads کے بجائے live conversation زیادہ درکار ہے تو NodeBB استعمال کریں، یا تسلیم کریں کہ یہ chat ہے اور اس کے بجائے Docker Compose پر Rocket.Chat چلائیں۔ ایسا forum جس میں ایک ہفتے بعد پڑھنے کے قابل کچھ باقی نہ رہے، اسے chat server ہونا چاہیے۔
• اگر آپ کو discussion کے بجائے documentation درکار ہے تو ان میں سے کوئی بھی مناسب نہیں۔ BookStack، Wiki.js یا Outline اس ضرورت کو بہتر طور پر پورا کرتے ہیں، اور بار بار پوچھے گئے سوالات سے بھرا forum عموماً missing wiki کی علامت ہوتا ہے۔
• اگر آپ ابھی تک یہ طے کر رہے ہیں کہ سرور پر آخر کیا ہونا چاہیے تو 2026 کے لیے وسیع self-hosting shortlist بہتر نقطۂ آغاز ہے، جبکہ self-hosted Notion alternatives guide forums اور shared workspaces کے باہمی دائرے کا احاطہ کرتی ہے۔

آپ جو بھی منتخب کریں، forum اتنا ہی قابل اعتماد ہوتا ہے جتنا اس کا آخری restore کیا گیا backup۔ مقررہ schedule کے مطابق database dump بنائیں، اسی job میں uploads directory بھی copy کریں، اور نتیجے کو ایک بار کسی دوسری جگہ restore کر کے تصدیق کریں کہ dump قابل استعمال ہے۔ VPS پر مقررہ restic backups اس حصے کا احاطہ کرتی ہے، اور اس setup کا یہی وہ واحد حصہ ہے جس میں دوسری کوشش کی گنجائش نہیں۔

FAQ

خود میزبانی والے فورم کے لیے سرور کی کم از کم ضروریات کیا ہیں؟

phpBB، SQLite کے ساتھ، 1 GB RAM پر دیگر سروسز کے ساتھ چل جاتا ہے، کیونکہ اس کے لیے الگ database server درکار نہیں ہوتا۔ Flarum کے لیے 1 GB RAM کے علاوہ MariaDB درکار ہے۔ NodeBB، MongoDB کے ساتھ، 2 GB RAM پر مناسب طور پر چلتا ہے۔ Discourse اپنی کم از کم ضرورت 1 GB RAM، swap اور 10 GB disk بتاتا ہے، لیکن عملی طور پر کم از کم 2 GB RAM چاہیے، جبکہ مصروف فورم کے لیے 4 GB بہتر ہے، کیونکہ ./launcher rebuild app ہر upgrade کے وقت assets کو memory میں دوبارہ compile کرتا ہے اور اسی مرحلے پر چھوٹا server kernel کے out-of-memory handler کے ذریعے بند ہو جاتا ہے۔

کیا میں اپنے phpBB فورم کو Discourse میں منتقل کر سکتا ہوں؟

ہاں، اور یہاں یہی سب سے بہتر معاونت یافتہ migration path ہے۔ Discourse کے ساتھ script/import_scripts/phpbb3.rb شامل ہوتا ہے، جسے آپ phpBB database کی copy پر container کے اندر چلاتے ہیں، live database پر کبھی نہیں۔ Users، categories، topics، posts اور attachments منتقل ہو جاتے ہیں۔ Styles اور extensions منتقل نہیں ہوتے، اور پرانے topic URLs تبدیل ہو جاتے ہیں، اس لیے DNS تبدیل کرنے سے پہلے phpBB paths سے redirects کا منصوبہ بنائیں۔ بڑے boards میں کئی گھنٹے لگ سکتے ہیں، اس لیے پہلے scratch server پر import کی مشق کریں اور اس کا دورانیہ نوٹ کریں۔

نئے users کو activation email کبھی کیوں نہیں ملتی؟

زیادہ تر VPS providers outbound port 25 کو block کرتے ہیں، اس لیے local mail server بالکل delivery نہیں کر پاتا اور log میں recipient کے mail exchanger کے خلاف Connection timed out دکھائی دیتا ہے۔ جب delivery ممکن بھی ہو، تو نیا IP، جس کے لیے SPF یا DKIM records موجود نہ ہوں، reject یا filter کر دیا جاتا ہے، اور Google 550 5.7.26 Unauthenticated email ... is not accepted due to domain's DMARC policy کے ساتھ جواب دیتا ہے۔ port 587 پر relay کے ذریعے email بھیجیں اور وہ SPF، DKIM اور DMARC records publish کریں جو relay آپ کو فراہم کرتا ہے، پھر test registration سے تصدیق کریں اور موصول ہونے والے message کا Authentication-Results header پڑھیں۔

کس self-hosted forum software کے لیے moderation کا کام سب سے کم درکار ہوتا ہے؟

Discourse، کیونکہ اس کا workflow بنیادی نظام میں شامل ہے، بعد میں الگ سے جوڑا نہیں گیا۔ نئے accounts کو اس وقت تک rate limit کیا جاتا ہے جب تک وہ کافی مواد پڑھ نہ لیں، flags ایسی queue میں جمع ہوتے ہیں جس میں کارروائی کرنے والے user کا record محفوظ ہوتا ہے، اور Akismet plugin official ہے۔ Question and Answer anti-spam method فعال کرنے کے بعد phpBB بھی اس کے قریب پہنچ جاتا ہے، کیونکہ یہ زیادہ تر bot registration کو خود روک دیتا ہے۔ Flarum اور NodeBB انہی کاموں کے لیے community extensions پر انحصار کرتے ہیں۔ تاہم اصل عامل تبدیل نہیں ہوتا: moderation load اس بات کے مطابق بڑھتا ہے کہ کتنے لوگ post کرتے ہیں، نہ کہ وہ کس software میں post کرتے ہیں۔