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-এর যা প্রয়োজন

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

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

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

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

আগস্ট 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 টেমপ্লেট লাইন আনকমেন্ট করুন, তারপর রিবিল্ড করুন। এই টেমপ্লেটটি acme.sh পরিচালনা করে, /shared/ssl-এর অধীনে শেয়ার্ড ভলিউমে সার্টিফিকেট সংরক্ষণ করে, কন্টেইনারের ভেতরে নির্ধারিত সময়সূচী অনুযায়ী সেগুলো রিনিউ করে এবং Discourse-কে HTTPS ব্যবহারে বাধ্য করে।

এই পদ্ধতি কাজ করার জন্য ইন্টারনেট থেকে 80 পোর্ট অবশ্যই অ্যাক্সেসযোগ্য হতে হবে, কারণ HTTP চ্যালেঞ্জের উত্তর সেখানেই দেওয়া হয়। যদি ফায়ারওয়াল শুধুমাত্র 443 পোর্ট খোলা রাখে, তবে বিল্ড সম্পন্ন হলেও সার্টিফিকেট ইস্যু হবে না। রিবিল্ড করার পরপরই ./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 নিবন্ধটি দেখুন, যা আপনাকে সঠিক সিদ্ধান্ত নিতে সাহায্য করবে।

রিবিল্ড, আপগ্রেড এবং যে কমান্ডগুলো আপনি বাস্তবে ব্যবহার করবেন

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) ওপর নির্ভর করে। অল্প কয়েকশ সদস্যের একটি শান্ত ফোরাম খুব বেশি ভারী কাজের চাপ তৈরি করে না।

কোনো নিবন্ধে উল্লিখিত সংখ্যা দেখে সার্ভারের আকার নির্ধারণ করবেন না, এমনকি এই নিবন্ধের ক্ষেত্রেও নয়। আপনার নিজের সার্ভারের পরিমাপ নিজেই নিন।

free -m
docker stats --no-stream

যদি Swap সবসময় ব্যবহৃত হয় এবং পেজ লোড হতে দেরি হয়, তবে বুঝতে হবে আপনার RAM-এর ঘাটতি রয়েছে। মেমরির ব্যবহার স্থিতিশীল থাকা সত্ত্বেও পেজ ধীরগতির হলে সাধারণত অন্য কোনো সমস্যা থাকে, তাই বড় কোনো প্ল্যান কেনার আগে ./launcher logs app পড়ে দেখুন। সার্ভারের বাইরে থেকেও একটি চেক যুক্ত করুন, কারণ মেমরি ফুরিয়ে গেলে রাত 3টার দিকে ফোরাম নীরবে অচল হয়ে যেতে পারে: একটি আলাদা হোস্টে self-hosted Uptime Kuma status monitor ব্যবহার করলে আপনার সদস্যরা জানার আগেই আপনি বিষয়টি জানতে পারবেন।

কখন Discourse সঠিক পছন্দ নয়

Discourse একটি বড় অ্যাপ্লিকেশন যার ইনস্টলেশন প্রক্রিয়া বেশ জটিল এবং app.yml-এ থাকা যেকোনো সেটিংস পরিবর্তনের জন্য পুরো সিস্টেমটি পুনরায় বিল্ড (rebuild) করতে হয়। এই খরচের বিনিময়ে আপনি শক্তিশালী মডারেশন টুল এবং বিশাল আর্কাইভের মধ্যেও কার্যকর সার্চ সুবিধা পান। ত্রিশ জন মানুষের আলোচনার জন্য এটি প্রয়োজনের তুলনায় অনেক বেশি ভারী একটি সিস্টেম। তাই আগে self-hosted ফোরাম সফটওয়্যারের তুলনা পড়ুন এবং 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-এ একটি সুইচ আছে যা ইমেইল সেটআপ ভ্যালিডেশন এড়িয়ে যায়। প্রাথমিক পরীক্ষার পরবর্তী যেকোনো ব্যবহারের জন্য এটি কনফিগার করুন, কারণ অ্যাকাউন্ট অ্যাক্টিভেশন এবং পাসওয়ার্ড রিসেট ইমেইলের মাধ্যমেই সম্পন্ন হয়। port 587 বা 465-এ একটি authenticated relay ব্যবহার করুন, কারণ অধিকাংশ VPS প্রোভাইডার outbound port 25 ব্লক করে রাখে।

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

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

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

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

আমি কীভাবে self-hosted Discourse-এর ব্যাকআপ নেব?

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