آموزش نصب 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
  }
]

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

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

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

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

هر دو دستور باید یک آدرس یکسان را نمایش دهند. این دو باید با هم مطابقت داشته باشند، زیرا ویزارد نصب، یک تست اتصال به نام‌دامنه شما انجام می‌دهد و اگر رکورد همچنان به جای دیگری اشاره کند، این تست با شکست مواجه می‌شود. رکوردی که همین دو دقیقه پیش ایجاد کرده‌اید ممکن است همچنان در حافظه کش (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) و 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 کوچک چند دقیقه طول می‌کشد و اولین بار کندترین حالت است، زیرا تمام دارایی‌ها از ابتدا کامپایل می‌شوند.

دستور ./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 فهرستی است که با کاما جدا می‌شود و آدرس‌های موجود در آن، هنگام اولین ثبت‌نام به‌طور خودکار به وضعیت مدیر (admin) در می‌آیند. آدرس خود را در آنجا قرار دهید و با همان آدرس ثبت‌نام کنید، زیرا اولین حساب کاربری مدیر به این روش ایجاد می‌شود.

این فایل رمز عبور SMTP شما را به‌صورت متن ساده ذخیره می‌کند، بنابراین دسترسی به دایرکتوری را با sudo chmod 700 /var/discourse/containers محدود کنید. این فایل همچنین از فرمت YAML استفاده می‌کند، به این معنی که فاصله‌ها بخشی از پیکربندی هستند: یک کلید که به‌درستی تراز نشده باشد، باعث شکست در build با خطای تجزیه (parse error) شده و سایت شما را غیرفعال می‌کند. یکی از تله‌های رایج در خود فایل نمونه مستند شده است. یک # در داخل رمز عبوری که داخل کوتیشن قرار نگرفته باشد، یک کامنت را آغاز می‌کند؛ بنابراین هر رمز عبوری که حاوی این کاراکتر است را داخل کوتیشن قرار دهید.

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

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

مشکل عملی این است که اکثر ارائه‌دهندگان VPS پورت خروجی 25 را مسدود می‌کنند، بنابراین یک سرور ایمیل ساده روی آن ماشین، پیامی ارسال نخواهد کرد. از یک relay احراز هویت‌شده روی پورت 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 ایمیل‌هایی را که از ارسال آن‌ها امتناع کرده یا توسط relay رد شده‌اند ثبت می‌کند و دلیل آن را ذکر می‌نماید؛ این روش بسیار سریع‌تر از خواندن لاگ‌ها است.

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 لینک‌های مطلق (absolute links) می‌نویسد، بنابراین بدون آن 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 در طول فرآیند ساخت (build) کلون می‌کند. تغییرات در ایمیج پایه یا قالب‌ها از طریق 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 نیز کارهای پس‌زمینه را در کنار آن‌ها اجرا می‌کند؛ بنابراین میزان مصرف حافظه با تعداد درخواست‌های همزمان رابطه دارد، نه تعداد اعضای ثبت‌نام‌شده. یک انجمن خلوت با چند صد عضو، بار کاری سنگینی محسوب نمی‌شود. معمولاً آنچه اهمیت بیشتری دارد، سایر سرویس‌های موجود روی سرور است؛ اگر یک کتابخانه عکس روی سرور دارید، حداقل‌های رم اندازه‌گیری‌شده در مقایسه PhotoPrism و Immich به شما می‌گوید که آیا Discourse برای تکمیل فرآیند rebuild فضای کافی در اختیار دارد یا خیر.

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

free -m
docker stats --no-stream

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

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

Discourse یک برنامه بزرگ با نصب سنگین است و برای هر تغییری در تنظیمات موجود در app.yml، نیاز به چرخه بازسازی (rebuild) دارد. این هزینه، ابزارهای مدیریت محتوای واقعی و قابلیت جستجویی را برای شما فراهم می‌کند که حتی در آرشیوهای بزرگ نیز کارآمد باقی می‌ماند. برای گروهی 30 نفره که تنها به فضایی برای گفتگو نیاز دارند، این نرم‌افزار فراتر از نیازهای آن مکالمه است. ابتدا مقایسه نرم‌افزارهای انجمن‌ساز self-hosted را مطالعه کنید و 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 را در کنار آرشیو کپی کنید و هر دو را به دستگاه دیگری منتقل کنید، زیرا پشتیبانی که روی همان دیسک سایت قرار دارد، در صورت خرابی دیسک از بین می‌رود.