VPS-এ Docker ব্যবহার করে Discourse ইনস্টল করার নিয়ম

একটি VPS-এ Discourse ইনস্টল করা: একটি কন্টেইনার, একটি কনফিগারেশন ফাইল

একটি VPS-এ Discourse ইনস্টল করতে আপনাকে প্রজেক্টের নিজস্ব ইনস্টলার চালাতে হবে, একটি সংক্ষিপ্ত উইজার্ডের উত্তর দিতে হবে এবং বিল্ড সম্পন্ন হওয়া পর্যন্ত অপেক্ষা করতে হবে। Discourse একটি একক Docker কন্টেইনার হিসেবে আসে, যার মধ্যে Rails অ্যাপ্লিকেশন, PostgreSQL, Redis এবং Nginx অন্তর্ভুক্ত থাকে। পরবর্তীতে আপনি যা কিছু পরিবর্তন করবেন তার সবকিছুই একটি ফাইলে থাকে, যার নাম /var/discourse/containers/app.yml, এবং প্রতিটি পরিবর্তনের পর সাইটটিতে তা কার্যকর করতে একটি রিবিল্ড (rebuild) করতে হয়।

অফিসিয়াল ইনস্টলেশন পদ্ধতি হলো discourse_docker: একটি launcher শেল স্ক্রিপ্ট এবং কিছু YAML টেমপ্লেটের সেট। Discourse আপনার নিজের তৈরি করা কোনো Compose ফাইল সমর্থন করে না এবং কন্টেইনারটিকে ম্যানুয়ালি আলাদা করার উদ্দেশ্যে তৈরি করা হয়নি। আপনি যদি Docker Compose ব্যবহার করে VPS-এ সার্ভিস চালানোর অভ্যস্ত হন, তবে এখানে ভিন্ন একটি কাঠামো আশা করুন। এখানে কোনো docker compose up -d নেই এবং ./launcher rebuild app-ই হলো ডেপ্লয়মেন্টের মাধ্যম।

শুরু করার আগে Discourse-এর যা প্রয়োজন

চারটি প্রয়োজনীয়তা ব্যবহারকারীদের সমস্যায় ফেলে, এবং লগইন পেজে পৌঁছানোর আগেই প্রতিটি বিষয় বাধা হয়ে দাঁড়ায়।

• মেমরি। একটি কন্টেইনারে PostgreSQL, Redis, Sidekiq এবং একটি Ruby ওয়েব সার্ভার চলে। বিল্ড ধাপে অ্যাসেট কম্পাইল করার জন্য চলমান সাইটের চেয়ে বেশি মেমরির প্রয়োজন হয়।
• একটি আসল ডোমেইন নাম। প্রদত্ত নমুনা কনফিগারেশনে স্পষ্টভাবে বলা আছে: "Discourse শুধুমাত্র একটি IP নম্বর দিয়ে কাজ করবে না।"
• আউটবাউন্ড মেইল পাথ। অ্যাকাউন্ট অ্যাক্টিভেশন, পাসওয়ার্ড রিসেট, অ্যাডমিন ইনভাইট এবং ডাইজেস্ট মেইল—সবই 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

উভয় কমান্ডেই একই IP address প্রদর্শন করতে হবে। এগুলোকে অবশ্যই একই হতে হবে, কারণ সেটআপ উইজার্ড আপনার হোস্টনামের বিপরীতে একটি কানেকশন টেস্ট চালায়। যদি রেকর্ডটি অন্য কোথাও নির্দেশ করে, তবে সেই টেস্টটি ব্যর্থ হবে। দুই মিনিট আগে তৈরি করা রেকর্ডটিও ক্যাশে (cached) থাকতে পারে, তাই উইজার্ডের সাথে ঝামেলা না করে পুরনো TTL (time to live) শেষ হওয়া পর্যন্ত অপেক্ষা করুন।

এখনই সিদ্ধান্ত নিন রেকর্ডটি কোনো CDN দ্বারা প্রক্সি করা হবে কি না। একটি প্রক্সি করা রেকর্ড আপনার সার্ভারের ঠিকানা গোপন রাখে, যার ফলে কন্টেইনারের সার্টিফিকেট রিকোয়েস্ট ব্যর্থ হয়। কারণ 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 একটি পাতলা র‍্যাপার (thin wrapper) হিসেবে কাজ করে। এটি হোস্ট নেটওয়ার্ক এবং মাউন্ট করা Docker socket-সহ discourse/setup-wizard:release-কে একটি কন্টেইনার হিসেবে চালায়, যাতে উইজার্ডটি যে মেশিনটি কনফিগার করছে তা পরীক্ষা করতে পারে। এটি হোস্টনাম এবং অ্যাডমিন ইমেইল অ্যাড্রেস জিজ্ঞাসা করে, এরপর আপনার SMTP ব্লকের তথ্য চায়। এটি containers/app.yml লেখে এবং তারপর পুনরায় বিল্ড (rebuild) করে।

শুরু করার আগে দুটি আচরণ জেনে রাখা ভালো। মেশিনে যদি মেমোরি কম থাকে এবং কোনো swap না থাকে, তবে উইজার্ডটি থেমে যায় এবং 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-এ এই বিল্ড সম্পন্ন হতে কয়েক মিনিট সময় লাগে এবং প্রথমবার এটি সবচেয়ে ধীরগতির হয়, কারণ প্রতিটি অ্যাসেট নতুন করে কম্পাইল করা হয়।

./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 হলো কমা দিয়ে আলাদা করা একটি তালিকা, এবং প্রথমবার সাইন-আপ করার সময় এই ঠিকানাগুলো স্বয়ংক্রিয়ভাবে অ্যাডমিন হিসেবে গণ্য হয়। আপনার নিজের ঠিকানা সেখানে দিন এবং তা দিয়ে রেজিস্টার করুন, কারণ এভাবেই প্রথম অ্যাডমিন অ্যাকাউন্ট তৈরি হয়।

ফাইলটি আপনার SMTP পাসওয়ার্ড প্লেইন টেক্সটে সংরক্ষণ করে, তাই sudo chmod 700 /var/discourse/containers দিয়ে ডিরেক্টরিটির অ্যাক্সেস সীমাবদ্ধ করুন। এটি YAML ফরম্যাটে থাকে, যার মানে হলো হোয়াইটস্পেস বা ফাঁকা জায়গাই কনফিগারেশন: কোনো কি (key) ভুলভাবে অ্যালাইন করা থাকলে তা পার্স এরর (parse error) ঘটিয়ে বিল্ড ব্যর্থ করবে এবং আপনার সাইটটি আর কাজ করবে না। একটি সাধারণ ফাঁদ স্যাম্পল ফাইলের ভেতরেই উল্লেখ করা আছে। আনকোটেড পাসওয়ার্ডের ভেতরে থাকা # একটি কমেন্ট হিসেবে গণ্য হয়, তাই পাসওয়ার্ডে এই চিহ্ন থাকলে তা অবশ্যই কোটেশনের ভেতরে রাখুন।

ইমেইল সেটআপ হলো সেই ধাপ যা অধিকাংশ ইনস্টলেশন আটকে দেয়

আগস্ট 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 সেট করুন, যা স্যাম্পল কনফিগারেশনে এই পোর্টের জন্য সুপারিশ করা হয়েছে। রিবিল্ড করার আগে হোস্ট থেকে সংযোগের সক্ষমতা পরীক্ষা করে নিন।

nc -vz smtp.example.com 587

একটি সফল ফলাফলের শেষে succeeded! লেখা একটি লাইন থাকবে। যদি কমান্ডটি হ্যাং হয়ে টাইম-আউট হয়ে যায়, তবে বুঝতে হবে আপনার VPS থেকে বাইরের পথে পোর্টটি ব্লক করা আছে এবং কোনো Discourse সেটিং দিয়ে এটি ঠিক করা সম্ভব নয়। আপনার প্রোভাইডার যে পোর্ট ব্যবহারের অনুমতি দেয় সেখানে চলে যান অথবা প্রোভাইডারকে পোর্টটি খুলে দিতে অনুরোধ করুন।

সাইট চালু হওয়ার পর, অ্যাডমিন প্যানেলের Email পেজ থেকে একটি টেস্ট মেসেজ পাঠান, তারপর একই পেজে থাকা Skipped এবং Bounced ট্যাবগুলো দেখুন। এই ট্যাবগুলোতে Discourse সেই মেইলগুলোর রেকর্ড রাখে যা পাঠাতে অস্বীকার করা হয়েছে বা রিলে প্রত্যাখ্যান করেছে, এবং সেখানে কারণও উল্লেখ থাকে, যা লগ ফাইল পড়ার চেয়ে দ্রুত সমাধান দেয়।

TLS: কন্টেইনারকে নিজস্ব সার্টিফিকেট নিতে দিন

যদি Discourse-এর কাছে 80 এবং 443 পোর্ট থাকে, তবে এর বিল্ট-ইন ইস্যুয়েন্স পদ্ধতি ব্যবহার করুন। উপরে দেখানো দুটি SSL টেমপ্লেট লাইনের কমেন্ট সরিয়ে দিন (uncomment), তারপর rebuild করুন। এই টেমপ্লেটটি acme.sh পরিচালনা করে, /shared/ssl-এর অধীনে শেয়ার করা ভলিউমে সার্টিফিকেট জমা রাখে, কন্টেইনারের ভেতরে নির্ধারিত সময়সূচী অনুযায়ী সেগুলো রিনিউ করে এবং Discourse-কে HTTPS ব্যবহারে বাধ্য করে।

এই প্রক্রিয়াটি কাজ করার জন্য ইন্টারনেট থেকে 80 পোর্ট অবশ্যই reachable বা প্রবেশযোগ্য থাকতে হবে, কারণ HTTP challenge-এর উত্তর সেখানেই দেওয়া হয়। যদি ফায়ারওয়াল শুধুমাত্র 443 পোর্ট খোলা রাখে, তবে বিল্ড সম্পন্ন হলেও সার্টিফিকেট কখনোই ইস্যু হবে না। rebuild করার পরপরই ./launcher logs app ব্যবহার করে ফলাফল যাচাই করুন।

Nginx বা Caddy-কে কি সামনে রাখা উচিত?

যদি VPS-এ শুধুমাত্র Discourse ওয়েব সার্ভিসটি চলে, তবে তা করবেন না। কন্টেইনারটি ইতিমধ্যেই একটি টিউন করা 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 ব্যবহার করে সার্টিফিকেট ইস্যু করুন। যদি এখনো কোনো প্রক্সি নির্বাচন না করে থাকেন, তবে the nginx, Caddy and Traefik comparison নিবন্ধটি দেখুন, যা আপনার প্রয়োজনীয় বিষয়গুলোর তুলনা তুলে ধরে।

Rebuild, upgrade এবং আপনার প্রয়োজনীয় কমান্ডসমূহ

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-এ রিস্টোর করার সময় আপনার হোস্টনাম এবং SMTP ব্লক পুনরায় কনফিগার করতে হবে। এর অর্থ হলো, এই ফাইলটিও সার্ভার থেকে আলাদা কোথাও কপি করে রাখা প্রয়োজন।

আর্কাইভটি যে সাইটের ডেটা রক্ষা করছে, সেই একই ডিস্কে জমা থাকে, যা প্রকৃত ব্যাকআপ নয়। তাই নিয়মিত বিরতিতে এটি অন্য কোথাও সরিয়ে নিন।

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

একটি ব্যস্ত ফোরামের জন্য RAM-এর খরচ

বুটস্ট্র্যাপ প্রক্রিয়াটি শনাক্তকৃত মেমরি এবং CPU-এর ওপর ভিত্তি করে UNICORN_WORKERS এবং db_shared_buffers সেট করে, এবং নমুনা কনফিগারেশনে মোট মেমরির এক-চতুর্থাংশ পর্যন্ত shared buffers সীমাবদ্ধ রাখা হয়। প্রতিটি unicorn worker একটি পূর্ণাঙ্গ 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) করতে হয়। এই খরচের বিনিময়ে আপনি শক্তিশালী মডারেশন টুল এবং এমন একটি সার্চ ইঞ্জিন পান, যা আর্কাইভ অনেক বড় হলেও কার্যকর থাকে। ত্রিশ জনের একটি দলের আলোচনার জন্য এটি প্রয়োজনের তুলনায় অনেক বেশি ভারী। তাই আগে সেলফ-হোস্টেড ফোরাম সফটওয়্যারের তুলনা পড়ুন এবং Discourse তখনই বেছে নিন যখন আপনার এর বিশেষ ফিচারগুলো প্রয়োজন, শুধুমাত্র পরিচিত নাম বলে নয়।

FAQ

আমি কি ডোমেইন নাম ছাড়া VPS-এ Discourse ইনস্টল করতে পারি?

না। সরবরাহকৃত কনফিগারেশন অনুযায়ী, Discourse শুধুমাত্র একটি IP ঠিকানায় কাজ করবে না এবং এর জন্য DISCOURSE_HOSTNAME প্রয়োজন। Discourse সেই hostname থেকে পূর্ণাঙ্গ লিঙ্ক তৈরি করে, তাই সেখানে IP ঠিকানা ব্যবহার করলে লিঙ্কগুলো কাজ করবে না এবং certificate ইস্যু করা বাধাগ্রস্ত হবে। শুরু করার আগে একটি A record তৈরি করুন এবং dig +short forum.example.com ব্যবহার করে নিশ্চিত করুন যে এটি আপনার সার্ভারের ঠিকানায় resolve হচ্ছে।

ইনস্টলেশন শেষ করতে কি আমাকে SMTP কনফিগার করতেই হবে?

আগস্ট 2026 থেকে আপনি এটি এড়িয়ে যেতে পারেন। সেটআপ উইজার্ড বিকল্প হিসেবে Discourse ID লগইন অফার করে এবং app.yml-এ একটি সুইচ আছে যা ইমেইল সেটআপ ভ্যালিডেশন এড়িয়ে যায়। প্রাথমিক পরীক্ষার পরবর্তী যেকোনো ব্যবহারের জন্য এটি কনফিগার করুন, কারণ অ্যাকাউন্ট অ্যাক্টিভেশন এবং পাসওয়ার্ড রিসেট ইমেইলের মাধ্যমেই সম্পন্ন হয়। পোর্ট 587 বা 465-এ একটি authenticated relay ব্যবহার করুন, কারণ অধিকাংশ VPS প্রোভাইডার আউটবাউন্ড পোর্ট 25 ব্লক করে রাখে।

আমার Discourse রিবিল্ড কেন মাঝপথে ব্যর্থ হলো?

সাধারণত মেমরির অভাব এর কারণ। বিল্ডের সময় অ্যাসেট কম্পাইল করার জন্য চলমান সাইটের চেয়ে বেশি মেমরি প্রয়োজন হয়, তাই যে সার্ভারটি ফোরাম চালানোর জন্য যথেষ্ট, সেটি রিবিল্ডের সময় ব্যর্থ হতে পারে। যদি dmesg-এ Out of memory: Killed process-এর মাধ্যমে কোনো ruby প্রসেস দেখা যায়, তবে swap যোগ করুন (উইজার্ডের নিজস্ব swapfile 2 GB) এবং পুনরায় ./launcher rebuild app চালান। যদি বিল্ডটি YAML এরর-এর কারণে থেমে যায়, তবে বুঝতে হবে app.yml-এ ইনডেন্টেশনের ভুল আছে।

Discourse কি আমার নিজস্ব Nginx বা Caddy-এর পেছনে থাকা উচিত?

শুধুমাত্র তখনই, যখন VPS-এ অন্য সাইটও হোস্ট করা থাকে। সার্ভারে একা থাকলে, কন্টেইনারকে পোর্ট 80 এবং 443 ব্যবহার করতে দিন এবং এটি নিজেই certificate ইস্যু করবে, এতে জটিলতা কম থাকে। মেশিনটি শেয়ার করতে চাইলে templates/web.socketed.template.yml যোগ করুন, expose লাইনগুলো কমেন্ট আউট করুন এবং /var/discourse/shared/standalone/nginx.http.sock-এ থাকা unix socket-এ প্রক্সি করুন। X-Forwarded-Proto পাস করুন, অন্যথায় Discourse HTTPS পেজে http:// লিঙ্ক তৈরি করবে।

আমি কীভাবে সেলফ-হোস্টেড Discourse-এর ব্যাকআপ নেব?

অ্যাডমিন প্যানেলের Backups পেজ ব্যবহার করুন অথবা ./launcher enter app চালানোর পর discourse backup রান করুন। আর্কাইভগুলো হোস্টের /var/discourse/shared/standalone/backups/default/ ডিরেক্টরিতে জমা হয়। আপলোড অন্তর্ভুক্ত করার সেটিংটি চালু আছে কি না নিশ্চিত করুন, আর্কাইভের সাথে /var/discourse/containers/app.yml কপি করুন এবং উভয়ই অন্য কোনো মেশিনে সরিয়ে নিন। কারণ সাইট যে ডিস্কে আছে, সেই একই ডিস্কে ব্যাকআপ রাখলে সার্ভার ফেইল করলে ব্যাকআপটিও নষ্ট হয়ে যাবে।