آموزش نصب Discourse روی VPS با Docker

نصب Discourse روی یک VPS: یک کانتینر، یک فایل پیکربندی

برای نصب Discourse روی یک VPS، باید نصب‌کننده اختصاصی پروژه را اجرا کنید، به چند پرسش کوتاه پاسخ دهید و منتظر پایان فرآیند build بمانید. Discourse به صورت یک کانتینر Docker واحد عرضه می‌شود که برنامه Rails، دیتابیس PostgreSQL، سرویس Redis و وب‌سرور nginx را در خود جای داده است. تمام تنظیماتی که بعداً تغییر خواهید داد در یک فایل به نام /var/discourse/containers/app.yml قرار دارند و هر تغییری از طریق بازسازی (rebuild) کانتینر روی سایت اعمال می‌شود.

روش نصب رسمی به این صورت است: discourse_docker؛ شامل یک اسکریپت شل launcher و مجموعه‌ای از قالب‌های YAML. سرویس Discourse از فایل Compose که خودتان بنویسید پشتیبانی نمی‌کند و کانتینر آن برای جداسازی دستی طراحی نشده است. اگر به اجرای سرویس‌ها روی VPS با Docker Compose عادت دارید، انتظار ساختار متفاوتی را داشته باشید. در اینجا خبری از docker compose up -d نیست و ./launcher rebuild app همان عملیات استقرار (deploy) محسوب می‌شود.

پیش‌نیازهای Discourse پیش از شروع

چهار مورد از الزامات وجود دارد که معمولاً نادیده گرفته می‌شوند و هر کدام از آن‌ها پیش از رسیدن به صفحه ورود، مشکل‌ساز خواهند شد.

• حافظه (RAM). یک کانتینر شامل PostgreSQL، Redis، Sidekiq و یک وب‌سرور Ruby است. مرحله build، دارایی‌ها (assets) را کامپایل می‌کند و به حافظه بیشتری نسبت به زمان اجرای سایت نیاز دارد.
• یک نام دامنه واقعی. فایل پیکربندی نمونه که همراه نرم‌افزار ارائه شده، به‌صراحت می‌گوید: "Discourse با یک آدرس IP خام کار نخواهد کرد."
• مسیر ارسال ایمیل خروجی. فعال‌سازی حساب، بازنشانی رمز عبور، دعوت‌نامه‌های مدیریت و ایمیل‌های خلاصه فعالیت، همگی از طریق SMTP (پروتکل انتقال نامه ساده) ارسال می‌شوند.
• پورت‌های 80 و 443 روی میزبان باید آزاد باشند، مگر اینکه عمداً Discourse را پشت یک پروکسی که از قبل اجرا کرده‌اید، قرار دهید.

[
  {
    "label": "Documented minimum",
    "ram_gb": 1,
    "storage_gb": 10
  },
  {
    "label": "Documented recommended",
    "ram_gb": 2,
    "storage_gb": 20
  }
]

مستندات رسمی نصب، حداقل مقدار 1 گیگابایت رم (به همراه swap) و 10 گیگابایت فضای دیسک را تعیین کرده و مقدار 2 گیگابایت رم با 20 گیگابایت فضای دیسک را توصیه می‌کند. عدد اول را به عنوان حداقل مقداری در نظر بگیرید که اجازه می‌دهد عملیات نصب به پایان برسد، نه عددی که برای اداره یک انجمن به آن نیاز دارید. این تفاوت اهمیت دارد زیرا اوج مصرف حافظه در مرحله build رخ می‌دهد، نه در زمان ترافیک عادی سایت.

پیش از نصب، دامنه را به سمت سرور هدایت کنید

یک رکورد A برای نام‌میزبانی (hostname) که قصد استفاده از آن را دارید ایجاد کنید، سپس آن را از داخل خود سرور تأیید نمایید.

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

هر دو دستور باید یک آدرس مشابه را چاپ کنند. این دو باید با هم مطابقت داشته باشند، زیرا ویزارد راه‌اندازی یک تست اتصال روی نام‌میزبان شما اجرا می‌کند و رکوردی که هنوز به جای دیگری اشاره می‌کند، در این تست شکست می‌خورد. رکوردی که 2 دقیقه پیش ایجاد کرده‌اید ممکن است هنوز در حافظه کش (cache) باشد؛ بنابراین به‌جای درگیر شدن با ویزارد، منتظر بمانید تا TTL (زمان زنده ماندن) قبلی منقضی شود.

اکنون تصمیم بگیرید که آیا رکورد توسط یک CDN پروکسی می‌شود یا خیر. رکورد پروکسی‌شده، آدرس سرور شما را مخفی می‌کند و در نتیجه درخواست گواهی کانتینر با شکست مواجه می‌شود، زیرا چالش ACME (محیط مدیریت خودکار گواهی) به‌جای 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 سبک است. این ابزار discourse/setup-wizard:release را به عنوان یک container با استفاده از host network و mount کردن Docker socket اجرا می‌کند تا ویزارد بتواند ماشینی که در حال پیکربندی آن است را بررسی کند. ویزارد نام دامنه (hostname) و آدرس‌های ایمیل مدیر سیستم را می‌پرسد و سپس اطلاعات SMTP شما را دریافت می‌کند. در نهایت، فایل containers/app.yml را می‌نویسد و عملیات rebuild را انجام می‌دهد.

پیش از شروع، آگاهی از دو رفتار این ابزار مفید است. اگر حافظهٔ سیستم کم باشد و swap فعال نباشد، ویزارد متوقف شده و پیشنهاد ایجاد آن را می‌دهد: در این صورت، wrapper یک فایل /swapfile با حجم 2 GB ایجاد کرده، آن را به /etc/fstab می‌افزاید، مقدار vm.swappiness = 10 را در /etc/sysctl.d/30-discourse-swap.conf تنظیم می‌کند و دوباره ویزارد را اجرا می‌نماید. پس از پایان کار ویزارد، عبارت Rebuilding app in 5 seconds (Ctrl+C to cancel)... نمایش داده شده و دستور ./launcher rebuild app روی میزبان اجرا می‌شود. این عملیات build روی یک VPS کوچک چندین دقیقه زمان می‌برد و اولین اجرا کندترین حالت است، زیرا تمام دارایی‌ها (assets) از ابتدا کامپایل می‌شوند.

دستور ./discourse-setup --help پرچم‌هایی (flags) را فهرست می‌کند که هنگام بروز خطا اهمیت دارند. --skip-rebuild فایل پیکربندی را بدون انجام build می‌نویسد و --skip-connection-test بررسی‌های DNS و پورت را نادیده می‌گیرد. از --skip-connection-test تنها زمانی استفاده کنید که دلیل شکست تست را می‌دانید؛ برای مثال، زمانی که میزبان پشت یک فایروال شبکه قرار دارد که شما آن را مدیریت می‌کنید.

پیش از اولین بازسازی، فایل 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 است، به این معنی که فاصله‌گذاری بخشی از پیکربندی محسوب می‌شود: یک کلید نامتراز باعث شکست در build با خطای تجزیه (parse error) شده و سایت شما را از دسترس خارج می‌کند. یک تله در خود فایل نمونه مستند شده است. یک # در داخل رمز عبوری که داخل کوتیشن قرار نگرفته باشد، یک کامنت را آغاز می‌کند؛ بنابراین هر رمز عبوری که حاوی این کاراکتر است را داخل کوتیشن قرار دهید.

ایمیل مرحله‌ای است که اکثر نصب‌ها را متوقف می‌کند

از اوت 2026، ویزارد به شما اجازه می‌دهد از SMTP صرف‌نظر کرده و به‌جای آن از ورود با Discourse ID استفاده کنید. همچنین app.yml دارای یک سوئیچ DISCOURSE_SKIP_EMAIL_SETUP منطبق است که در آنجا به‌عنوان نادیده گرفتن اعتبارسنجی تنظیمات ایمیل توصیف شده است. نادیده گرفتن این مرحله برای بررسی اولیه نرم‌افزار منطقی است. اما برای یک انجمن، انتخاب ضعیفی محسوب می‌شود؛ زیرا بدون ایمیل خروجی، هیچ‌کس نمی‌تواند حساب خود را فعال کند یا رمز عبور را بازیابی نماید.

مشکل عملی این است که اکثر ارائه‌دهندگان VPS پورت خروجی 25 را مسدود می‌کنند، بنابراین یک سرور ایمیل ساده روی آن ماشین، پیامی ارسال نخواهد کرد. از یک رله احراز هویت‌شده روی پورت 587، یا روی پورت 465 با TLS (امنیت لایه انتقال) ضمنی استفاده کنید. برای پورت 465، مقدار DISCOURSE_SMTP_FORCE_TLS: true را تنظیم کنید که در پیکربندی نمونه برای آن پورت توصیه شده است. پیش از بازسازی (rebuild)، دسترسی‌پذیری را از روی میزبان تست کنید.

nc -vz smtp.example.com 587

نتیجه سالم، یک خط واحد است که به succeeded! ختم می‌شود. دستوری که معلق می‌ماند و سپس با خطای timeout مواجه می‌شود، به این معنی است که پورت در مسیر خروجی VPS شما مسدود شده است و هیچ تنظیماتی در Discourse این مشکل را حل نمی‌کند. به پورتی بروید که ارائه‌دهنده شما اجازه می‌دهد، یا از آن‌ها بخواهید پورت را باز کنند.

هنگامی که سایت بالا آمد، یک پیام تست از صفحه Email در بخش Admin ارسال کنید، سپس زبانه‌های Skipped و Bounced را در همان صفحه بخوانید. این زبانه‌ها جایی هستند که Discourse ایمیل‌هایی را که از ارسال آن‌ها خودداری کرده و ایمیل‌هایی که توسط رله رد شده‌اند ثبت می‌کند و دلیل آن را نیز ذکر می‌کند؛ این روش سریع‌تر از خواندن لاگ‌ها است.

TLS: اجازه دهید کانتینر گواهی خود را دریافت کند

اگر Discourse پورت‌های 80 و 443 را در اختیار دارد، از قابلیت صدور داخلی آن استفاده کنید. دو خط مربوط به قالب SSL که در بالا نشان داده شده است را از حالت کامنت خارج کرده و سپس rebuild را انجام دهید. این قالب acme.sh را هدایت می‌کند، گواهی‌ها را در volume مشترک تحت مسیر /shared/ssl ذخیره می‌نماید، آن‌ها را طبق زمان‌بندی داخل کانتینر تمدید می‌کند و Discourse را برای اجبار به استفاده از HTTPS تنظیم می‌نماید.

برای اینکه این فرآیند کار کند، پورت 80 باید از اینترنت در دسترس باشد، زیرا چالش HTTP در آنجا پاسخ داده می‌شود. فایروالی که فقط اجازه دسترسی به پورت 443 را می‌دهد، منجر به buildای می‌شود که به پایان می‌رسد اما گواهی هرگز صادر نمی‌شود. بلافاصله پس از rebuild، نتیجه را با ./launcher logs app بررسی کنید.

آیا باید از Nginx یا Caddy در مقابل استفاده کرد؟

اگر Discourse تنها سرویس وب روی VPS شماست، این کار را نکنید. کانتینر از قبل یک Nginx بهینه‌شده را اجرا می‌کند و پروکسی دوم، یک گام اضافی، یک گواهی دیگر برای تمدید و منبع جدیدی برای خطاهای Header ایجاد می‌کند.

زمانی از پروکسی در مقابل استفاده کنید که همان VPS میزبان سایت‌های دیگری نیز باشد. عبارت templates/web.socketed.template.yml را به لیست templates اضافه کنید، هر دو خط expose را کامنت کنید و دو قالب SSL را در حالت کامنت باقی بگذارید. در این حالت، کانتینر روی یک unix socket در مسیر /var/discourse/shared/standalone/nginx.http.sock گوش می‌دهد و هیچ پورتی را اشغال نمی‌کند؛ بنابراین پورت‌های 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;
  }
}

دو نقطه (colon) انتهای .sock بخشی از سینتکس unix socket در Nginx است و sudo nginx -t بدون آن پیکربندی را نمی‌پذیرد. عبارت X-Forwarded-Proto نیز اختیاری نیست. Discourse لینک‌های مطلق تولید می‌کند، بنابراین بدون آن Header، لینک‌های http:// را در یک صفحه HTTPS منتشر می‌کند و مرورگرها آن‌ها را به عنوان محتوای ترکیبی (mixed content) مسدود می‌کنند. با اتصال کانتینر از طریق socket، مدیریت TLS بر عهده شماست؛ بنابراین گواهی را روی میزبان با استفاده از Certbot روی Ubuntu 24.04 و nginx صادر کنید. اگر هنوز پروکسی خود را انتخاب نکرده‌اید، مقایسه Nginx، Caddy و Traefik به بررسی تفاوت‌ها و انتخاب شما کمک می‌کند.

بازسازی‌ها، ارتقاها و دستوراتی که واقعاً از آن‌ها استفاده خواهید کرد

cd /var/discourse
./launcher rebuild app

دستور rebuild کانتینر در حال اجرا را از بین می‌برد، یک کانتینر جدید از روی app.yml ایجاد می‌کند و آن را استارت می‌زند. سایت در تمام مدت بازسازی آفلاین است، بنابراین هر تغییر در پیکربندی را به عنوان زمان ازکارافتادگی برنامه‌ریزی‌شده (scheduled downtime) به مدت چند دقیقه در نظر بگیرید.

تغییر مقادیر فقط در بخش env: نیازی به این کار ندارد. دستور ./launcher destroy app && ./launcher start app کانتینر را از روی ایمیجی که قبلاً ساخته‌اید بازسازی می‌کند که تنها چند ثانیه طول می‌کشد. هر تغییری در templates: یا hooks:، خودِ ایمیج را تغییر می‌دهد، بنابراین به بازسازی کامل نیاز دارد.

ارتقاها به دو روش انجام می‌شوند. نسخه‌های جزئی (Point releases) از طریق رابط وب در /admin/upgrade اعمال می‌شوند که توسط افزونه docker_manager فراهم شده است؛ افزونه‌ای که app.yml در طول فرآیند ساخت، آن را کلون می‌کند. تغییرات در ایمیج پایه یا قالب‌ها از طریق git اعمال می‌شوند.

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

بازسازی‌ها جایی هستند که سرورهای کوچک در آن شکست می‌خورند، زیرا کامپایل دارایی‌ها (asset compilation) اوج مصرف حافظه در کل سیستم است. اگر فرآیند ساخت در میانه راه متوقف شد و dmesg خطی مشابه Out of memory: Killed process را نشان داد که به یک پردازش ruby اشاره دارد، یعنی سیستم در طول ساخت با کمبود حافظه مواجه شده است، حتی اگر سایت پیش از آن به خوبی کار می‌کرده است. فضای swap اضافه کنید و بازسازی را دوباره اجرا کنید.

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

دستور logs خروجی کانتینر را چاپ می‌کند، enter یک shell داخل آن باز می‌کند و cleanup کانتینرهایی را که بیش از 24 ساعت متوقف بوده‌اند حذف می‌کند. دستور cleanup را هر از گاهی اجرا کنید، زیرا هر بازسازی یک کانتینر قدیمی باقی می‌گذارد و فضای دیسک در یک VPS کوچک به آرامی پر می‌شود.

پشتیبان‌گیری و فایلی که در نسخه پشتیبان وجود ندارد

از صفحه Backups در بخش Admin، نسخه پشتیبان تهیه کنید. فایل آرشیو در مسیر /var/discourse/shared/standalone/backups/default/ روی میزبان ذخیره می‌شود. همین عملیات از طریق shell نیز قابل اجرا است.

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

دستور discourse restore <filename> عملیات را معکوس می‌کند و تا زمانی که discourse enable_restore را اجرا نکنید، بازیابی انجام نخواهد شد. این محافظ برای آن است که یک دستور اشتباه، انجمن فعال را بازنویسی نکند.

دو شکاف وجود دارد که باید خودتان آن‌ها را پر کنید. آرشیو شامل پایگاه داده است و فایل‌های آپلود شده را تنها زمانی در بر می‌گیرد که تنظیمات پشتیبان‌گیری شامل آپلودها فعال باشد؛ بنابراین پیش از اعتماد به نسخه پشتیبان، این تنظیم را بررسی کنید. آرشیو هرگز شامل app.yml نیست، بنابراین بازیابی روی یک VPS جدید همچنان به نام میزبان (hostname) و تنظیمات SMTP شما نیاز دارد؛ این یعنی باید آن فایل را جداگانه از سرور کپی کنید.

همچنین، آرشیو روی همان دیسکی قرار می‌گیرد که سایت تحت حفاظت روی آن است، که این به معنای پشتیبان‌گیری واقعی نیست. طبق یک زمان‌بندی مشخص، فایل‌ها را به مکان دیگری منتقل کنید.

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

هزینه رم برای یک انجمن پرتردد

فرآیند bootstrap مقادیر UNICORN_WORKERS و db_shared_buffers را بر اساس حافظه و CPU شناسایی‌شده تنظیم می‌کند و فایل پیکربندی نمونه، سقف shared buffers را روی یک‌چهارم کل حافظه قرار می‌دهد. هر worker در unicorn یک پردازش کامل Ruby است و Sidekiq نیز وظایف پس‌زمینه را در کنار آن‌ها اجرا می‌کند؛ بنابراین میزان مصرف حافظه با تعداد درخواست‌های همزمان رابطه مستقیم دارد، نه تعداد اعضای ثبت‌نام‌شده. یک انجمن کم‌تردد با چند صد عضو، بار کاری سنگینی محسوب نمی‌شود.

اندازه سرور را بر اساس اعداد موجود در مقالات، از جمله همین مقاله، تعیین نکنید. میزان مصرف خود را اندازه‌گیری کنید.

free -m
docker stats --no-stream

استفاده مداوم از Swap در کنار کندی صفحات به معنای کمبود رم است. اگر حافظه ثابت است اما صفحات کند هستند، احتمالاً مشکل جای دیگری است؛ بنابراین پیش از ارتقای پلن، ./launcher logs app را مطالعه کنید. همچنین، بررسی وضعیت را از خارج از سرور انجام دهید، زیرا انجمنی که ساعت 3 بامداد با کمبود حافظه مواجه می‌شود، بدون اطلاع قبلی از دسترس خارج خواهد شد: یک مانیتور وضعیت Uptime Kuma که به‌صورت self-hosted روی یک میزبان مجزا اجرا می‌شود، پیش از آنکه اعضای انجمن متوجه شوند، شما را مطلع خواهد کرد.

چه زمانی Discourse انتخاب مناسبی نیست

Discourse یک برنامه بزرگ با نصب سنگین و چرخه بازسازی (rebuild) برای هر تنظیمی است که در app.yml قرار دارد. این هزینه، ابزارهای مدیریت محتوای واقعی و قابلیتی برای جستجو را فراهم می‌کند که حتی در آرشیوهای بزرگ نیز کارآمد است. برای سی نفری که فقط به فضایی برای گفتگو نیاز دارند، این نرم‌افزار بیش از حد نیازِ آن گفتگو، منابع ماشین را مصرف می‌کند. ابتدا مقایسه نرم‌افزارهای انجمن‌ساز خودمیزبان را مطالعه کنید و Discourse را به این دلیل انتخاب کنید که به قابلیت‌های آن نیاز دارید، نه صرفاً به این دلیل که نام آن را از قبل شنیده‌اید.

FAQ

آیا می‌توانم Discourse را روی یک VPS بدون نام دامنه نصب کنم؟

خیر. پیکربندی پیش‌فرض اعلام می‌کند که Discourse با یک آدرس IP خام کار نمی‌کند و DISCOURSE_HOSTNAME الزامی است. Discourse لینک‌های مطلق را بر اساس آن نام میزبان می‌سازد، بنابراین استفاده از آدرس IP باعث شکستن لینک‌ها و جلوگیری از صدور گواهی می‌شود. پیش از شروع، یک رکورد A ایجاد کنید و با استفاده از dig +short forum.example.com تأیید کنید که به آدرس سرور شما اشاره می‌کند.

آیا برای تکمیل نصب باید SMTP را پیکربندی کنم؟

از اوت 2026 می‌توانید از این مرحله بگذرید. ویزارد نصب، ورود از طریق Discourse ID را پیشنهاد می‌دهد و app.yml دارای سوئیچی است که اعتبارسنجی تنظیمات ایمیل را نادیده می‌گیرد. برای هر استفاده‌ای فراتر از بررسی اولیه، آن را پیکربندی کنید، زیرا فعال‌سازی حساب و بازنشانی رمز عبور هر دو از طریق ایمیل انجام می‌شوند. از یک relay احراز هویت‌شده روی پورت 587 یا 465 استفاده کنید، زیرا اکثر ارائه‌دهندگان VPS پورت 25 خروجی را مسدود می‌کنند.

چرا بازسازی (rebuild) Discourse من در میانه راه با خطا مواجه شد؟

کمبود حافظه معمول‌ترین دلیل است. کامپایل دارایی‌ها (assets) در طول فرآیند ساخت، به حافظه بیشتری نسبت به زمان اجرای سایت نیاز دارد، بنابراین سروری که به‌خوبی انجمن را میزبانی می‌کند ممکن است در بازسازی شکست بخورد. اگر dmesg نشان‌دهنده Out of memory: Killed process برای یک فرآیند ruby باشد، swap اضافه کنید (فایل swap پیش‌فرض ویزارد 2 گیگابایت است) و دوباره ./launcher rebuild app را اجرا کنید. ساختنی که روی خطای YAML متوقف می‌شود، نشان‌دهنده اشتباه در تورفتگی (indentation) در app.yml است.

آیا Discourse باید پشت Nginx یا Caddy شخصی من قرار بگیرد؟

فقط زمانی که VPS میزبان سایت‌های دیگری نیز باشد. اگر سرور اختصاصی است، اجازه دهید کانتینر پورت‌های 80 و 443 را در اختیار داشته باشد و گواهی خود را صادر کند؛ این کار باعث کاهش پیچیدگی می‌شود. برای اشتراک‌گذاری سرور، templates/web.socketed.template.yml را اضافه کنید، خطوط expose را کامنت کنید و درخواست‌ها را به unix socket در /var/discourse/shared/standalone/nginx.http.sock پروکسی کنید. هدر X-Forwarded-Proto را عبور دهید، در غیر این صورت Discourse لینک‌های http:// را در صفحه HTTPS تولید می‌کند.

چگونه از یک Discourse خودمیزبانی‌شده (self-hosted) نسخه پشتیبان بگیرم؟

از صفحه Backups در بخش مدیریت استفاده کنید یا پس از ./launcher enter app، دستور discourse backup را اجرا کنید. آرشیوها روی میزبان در مسیر /var/discourse/shared/standalone/backups/default/ قرار می‌گیرند. تنظیمات مربوط به شامل شدن فایل‌های آپلود شده را تأیید کنید، /var/discourse/containers/app.yml را در کنار آرشیو کپی کنید و هر دو را به ماشین دیگری منتقل کنید، زیرا پشتیبانی که روی همان دیسک سایت قرار دارد، در صورت خرابی دیسک از بین می‌رود.