Paano Mag-install ng Discourse sa VPS gamit ang Docker

Mag-install ng Discourse sa isang VPS: isang container, isang config file

Para mag-install ng Discourse sa isang VPS, patakbuhin ang sariling installer ng project, sagutin ang maikling wizard, at hintaying matapos ang build. Ang Discourse ay nire-release bilang isang Docker container na naglalaman ng Rails application, PostgreSQL, Redis, at nginx. Lahat ng babaguhin mo sa susunod ay nasa isang file, /var/discourse/containers/app.yml, at bawat pagbabago ay nailalapat sa site sa pamamagitan ng rebuild.

Ang opisyal na installer ay discourse_docker: isang launcher shell script at isang set ng YAML template. Hindi sinusuportahan ng Discourse ang Compose file na ikaw mismo ang gagawa, at hindi dapat manu-manong paghiwa-hiwalayin ang container. Kung nakasanayan mo ang pagpapatakbo ng mga serbisyo sa VPS gamit ang Docker Compose, iba ang setup na ito. Walang docker compose up -d dito, at ang ./launcher rebuild app ang ginagamit para sa deploy.

Mga kailangan ng Discourse bago magsimula

May apat na requirement na madalas makaligtaan, at bawat isa ay nagdudulot ng problema bago pa makarating sa login page.

• Memory. Isang container ang nagpapatakbo ng PostgreSQL, Redis, Sidekiq, at Ruby web server. Nagko-compile ng assets ang build step at nangangailangan ito ng mas maraming memory kaysa sa tumatakbong site.
• Isang totoong domain name. Malinaw itong sinasabi sa kasamang sample config: “Hindi gagana ang Discourse gamit ang bare IP number.”
• Isang outbound mail path. Dumadaan sa SMTP (simple mail transfer protocol) ang account activation, password reset, admin invite, at digest mail.
• Walang ibang gumagamit sa host ng ports 80 at 443, maliban kung sadya mong ilagay ang Discourse sa likod ng proxy na tumatakbo na.

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

Itinatakda ng official install document ang minimum na 1 GB ng RAM na may swap at 10 GB ng disk, at inirerekomenda ang 2 GB ng RAM na may 20 GB ng disk. Ituring ang unang row bilang halagang kailangan para matapos ang installer, hindi bilang halagang kailangan para magpatakbo ng community. Mahalaga ang agwat dahil sa build nangyayari ang memory peak, hindi dahil sa network traffic.

Ituro ang domain sa server bago mag-install

Gumawa ng A record para sa hostname na gagamitin mo, pagkatapos ay kumpirmahin ito mula mismo sa server.

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

Dapat mag-print ng parehong address ang dalawang command. Kailangang magtugma ang mga ito dahil nagsasagawa ang setup wizard ng connection test laban sa iyong hostname, at mabibigo ang test na iyon kung may ibang tinuturohan pa ang record. Posibleng naka-cache pa ang record na ginawa mo dalawang minuto ang nakalipas, kaya hintaying lumipas ang dating TTL (time to live) sa halip na piliting ipagpatuloy ang wizard.

Magpasya ngayon kung ipo-proxy ng CDN ang record. Itinatago ng proxied record ang address ng server, kaya mabibigo ang certificate request ng container dahil ang ACME (automatic certificate management environment) challenge ay sinasagot ng proxy sa halip na ng Discourse. Panatilihing unproxied ang record para sa unang installation.

Patakbuhin ang official installer

Sa isang command, mai-install ang git at Docker gamit ang sariling install script ng Docker, mako-clone ang discourse_docker sa /var/discourse, at masisimulan ang setup wizard.

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

Kung naka-install na ang Docker sa server at gusto mong makita ang bawat hakbang, gawin nang manual ang parehong proseso.

sudo -s
git clone https://github.com/discourse/discourse_docker.git /var/discourse
cd /var/discourse
./discourse-setup

Patakbuhin ito bilang root. Kapag sinimulan bilang ordinaryong user, agad na hihinto ang discourse-setup at ipapakita ang This script must be run as root. Please sudo or log in as root first.. Kung walang Docker sa server, hihinto ito at ipapakita ang Docker is not installed. Please install Docker first. dahil walang awtomatikong ini-install ang manual clone.

Mga hinihingi ng setup wizard at mga isinusulat nito

Noong August 2026, ang discourse-setup ay isang thin wrapper. Pinapatakbo nito ang discourse/setup-wizard:release bilang container na gumagamit ng host network at may naka-mount na Docker socket, kaya maaaring suriin ng wizard ang machine na kino-configure nito. Hinihingi nito ang hostname at mga admin email address, pagkatapos ay ang SMTP block mo. Isinusulat nito ang containers/app.yml, pagkatapos ay nagsasagawa ng rebuild.

May dalawang behavior na dapat mong malaman bago magsimula. Kung kulang sa memory ang machine at walang swap, hihinto ang wizard at mag-aalok na gumawa nito: gagawa ang wrapper ng 2 GB /swapfile, idaragdag ito sa /etc/fstab, itatakda ang vm.swappiness = 10 sa /etc/sysctl.d/30-discourse-swap.conf, at muling sisimulan ang wizard. Kapag natapos ang wizard, ipi-print nito ang Rebuilding app in 5 seconds (Ctrl+C to cancel)... at patatakbuhin ang ./launcher rebuild app sa host. Tumatagal nang ilang minuto ang build na ito sa maliit na VPS, at pinakamabagal ang unang build dahil kino-compile mula sa simula ang bawat asset.

Inililista ng ./discourse-setup --help ang mahahalagang flag kapag may problema. Isinusulat ng --skip-rebuild ang config nang hindi nagbu-build, at nilalaktawan ng --skip-connection-test ang mga DNS at port check. Gamitin lang ang --skip-connection-test kapag alam mo na kung bakit nagfa-fail ang test, halimbawa kapag nasa likod ng network firewall na ikaw ang nagma-manage ang host.

Basahin ang app.yml bago ang unang rebuild

Gumagawa ang wizard ng file na ikaw na ang kailangang mag-maintain. Buksan ito gamit ang sudo nano /var/discourse/containers/app.yml. Ito ang mga bahagi na halos lahat ng pangunahing setting ay nakadepende.

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"

Ang DISCOURSE_HOSTNAME ang address kung saan sumasagot ang site, at dito binubuo ng Discourse ang mga link nito. Kaya kapag mali ang value, maglo-load ang site nang isang beses at pagkatapos ay ire-redirect ka sa ibang address. Ang DISCOURSE_DEVELOPER_EMAILS ay comma-separated list, at awtomatikong nagiging admin ang mga address na iyon sa unang signup. Ilagay roon ang sarili mong address at gamitin iyon sa pag-register, dahil sa paraang ito ginagawa ang unang admin account.

Naka-store sa plain text ang SMTP password sa file, kaya paghigpitan ang access sa directory gamit ang sudo chmod 700 /var/discourse/containers. YAML din ang file, kaya mahalaga ang whitespace sa configuration. Kapag hindi naka-align ang isang key, mabibigo ang build dahil sa parse error at wala kang magiging site. May isang trap na nakadokumento mismo sa sample file. Kapag may # sa password na walang quotation marks, nagsisimula ito ng comment. Kaya lagyan ng quotation marks ang anumang password na may ganito.

Ang Email ang hakbang na kadalasang nagpapatigil sa karamihan ng installs

Simula August 2026, pinapayagan ng wizard na i-skip ang SMTP at gamitin na lang ang mga Discourse ID login. May katumbas na app.yml switch ang DISCOURSE_SKIP_EMAIL_SETUP, na inilalarawan doon bilang pag-skip sa validation ng email setup. Makatuwiran ang pag-skip para sa unang pagtingin sa software. Hindi ito magandang piliin para sa isang community, dahil kung walang outbound mail, walang makakapag-activate ng account o makakapag-reset ng password.

Ang praktikal na problema ay bina-block ng karamihan ng VPS provider ang outbound port 25, kaya hindi makakapag-deliver ang plain mail server sa server. Gumamit ng authenticated relay sa port 587, o sa 465 gamit ang implicit TLS (transport layer security). Para sa 465, i-set ang DISCOURSE_SMTP_FORCE_TLS: true, gaya ng inirerekomenda ng sample config para sa port na iyon. I-test muna ang reachability mula sa host bago ka mag-rebuild.

nc -vz smtp.example.com 587

Ang tamang resulta ay isang linya na nagtatapos sa succeeded!. Kung nag-hang ang command at kalaunan ay nag-time out, ibig sabihin ay naka-block ang port sa outbound path mula sa VPS mo, at walang Discourse setting na makakapag-ayos nito. Lumipat sa port na pinapayagan ng provider, o hilingin sa provider na buksan ito.

Kapag naka-up na ang site, magpadala ng test message mula sa Email page sa Admin, pagkatapos ay basahin ang Skipped at Bounced tabs sa parehong page. Dito nire-record ng Discourse ang mail na tinanggihan nitong ipadala at ang mail na tinanggihan ng relay. Nakasaad din dito ang dahilan, kaya mas mabilis ito kaysa sa pagbabasa ng logs.

TLS: hayaan ang container na kumuha ng sarili nitong certificate

Kung hawak ng Discourse ang ports 80 at 443, gamitin ang built-in nitong certificate issuance. Alisin ang comment sa dalawang SSL template line na ipinakita sa itaas, pagkatapos ay mag-rebuild. Kino-configure ng template ang acme.sh, ini-store ang mga certificate sa shared volume sa ilalim ng /shared/ssl, nire-renew ang mga ito ayon sa schedule sa loob ng container, at kino-configure ang Discourse na piliting gumamit ng HTTPS.

Dapat manatiling reachable mula sa internet ang port 80 para gumana ito, dahil doon sinasagot ang HTTP challenge. Kapag 443 lang ang pinapayagan ng firewall, matatapos ang build pero hindi kailanman mai-issue ang certificate. Suriin ang resulta gamit ang ./launcher logs app kaagad pagkatapos ng rebuild.

Dapat bang ilagay ang nginx o Caddy sa unahan?

Kung ang Discourse lang ang web service sa VPS, huwag na. May tuned na nginx na ang container, kaya ang pangalawang proxy ay nagdaragdag ng isang hop, panibagong certificate na kailangang i-renew, at bagong pinagmumulan ng mga header bug.

Ilagay ito sa unahan kapag ang parehong VPS ay nagsisilbi rin ng ibang site. Idagdag ang templates/web.socketed.template.yml sa listahan ng templates, i-comment out ang dalawang linya ng expose, at panatilihing naka-comment out ang dalawang SSL template. Makikinig ang container sa isang unix socket sa /var/discourse/shared/standalone/nginx.http.sock at wala itong anumang port na binuksan. Dahil dito, magagamit mo ang 80 at 443 para sa sarili mong proxy.

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;
  }
}

Bahagi ng syntax ng unix socket ng nginx ang colon sa hulihan ng .sock. Tinatanggihan ng sudo nginx -t ang configuration kapag wala ito. Hindi rin optional ang X-Forwarded-Proto. Gumagawa ang Discourse ng absolute link, kaya kapag wala ang header na iyon, naglalabas ito ng http:// link sa HTTPS page. Haharangan ito ng mga browser bilang mixed content. Kapag socket na ang gamit ng container, ikaw na ang bahala sa TLS. Kaya mag-issue ng certificate sa host gamit ang Certbot sa Ubuntu 24.04 at nginx. Kung hindi ka pa nakakapili ng proxy, ipinapaliwanag ng paghahambing ng nginx, Caddy at Traefik ang mga trade-off ng pagpiling iyon.

Mga rebuild, upgrade, at mga command na aktuwal mong gagamitin

cd /var/discourse
./launcher rebuild app

Sinisira ng rebuild ang tumatakbong container, gumagawa ng bago mula sa app.yml, at sinisimulan ito. Offline ang site sa buong build, kaya ituring ang bawat pagbabago sa configuration bilang naka-schedule na downtime na ilang minuto.

Hindi kailangan iyon kapag mga value lamang sa ilalim ng env: ang binago. Muling ginagawa ng ./launcher destroy app && ./launcher start app ang container mula sa image na dati mo nang na-build, at ilang segundo lamang ito. Binabago ng anumang nasa ilalim ng templates: o hooks: ang image mismo, kaya kailangan nito ang buong rebuild.

Dumarating ang mga upgrade sa dalawang paraan. Ina-apply ang point release mula sa web interface sa /admin/upgrade, gamit ang docker_manager plugin na kino-clone ng app.yml habang nagbu-build. Galing sa git ang mga pagbabago sa base image o sa mga template.

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

Dito kadalasang pumapalya ang maliliit na server sa mga rebuild, dahil ang asset compilation ang pinakamataas na memory peak ng buong system. Kapag huminto ang build sa kalagitnaan at may ipinakitang linyang gaya ng Out of memory: Killed process ang dmesg, na tumutukoy sa isang ruby process, naubusan ito ng memory habang nagbu-build kahit maayos na tumatakbo ang site bago iyon. Magdagdag ng swap at patakbuhin muli ang rebuild.

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

Ipinapakita ng logs ang output ng container, binubuksan ng enter ang shell sa loob nito, at inaalis ng cleanup ang mga container na mahigit 24 oras nang nakahinto. Patakbuhin paminsan-minsan ang cleanup, dahil nag-iiwan ng lumang container ang bawat rebuild at tahimik na nauubusan ng disk space ang maliit na VPS.

Mga backup at ang file na hindi kasama sa backup

Gumawa ng mga backup mula sa Backups page sa Admin. Mapupunta ang archive sa host sa /var/discourse/shared/standalone/backups/default/. Maaari ring patakbuhin ang parehong job mula sa shell.

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

Binabaligtad ito ng discourse restore <filename>, at tatanggihan ang restore hangga’t hindi mo pinapatakbo ang discourse enable_restore. Nariyan ang guard upang hindi aksidenteng ma-overwrite ng isang command ang live na forum.

May dalawang puwang na kailangan mong punan. Nasa archive ang database. Kasama lamang dito ang mga uploaded file kapag naka-on ang backup setting na nagsasama ng uploads, kaya suriin muna ang setting na iyon bago mo ito pagkatiwalaan. Hindi nito kailanman isinasama ang app.yml, kaya kapag nag-restore sa bagong VPS, kailangan mo pa rin ang hostname at SMTP block. Ibig sabihin, kailangan mo ring kopyahin ang file na iyon palabas ng server.

Nasa iisang disk din ang archive at ang site na pinoprotektahan nito. Hindi iyon maituturing na backup. Kunin ito at ilipat sa ibang lokasyon ayon sa iskedyul.

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

Magkano ang RAM ng isang abalang forum

Itinatakda ng bootstrap ang UNICORN_WORKERS at db_shared_buffers batay sa memory at CPU na natukoy nito, at nililimitahan ng sample config ang shared buffers sa isang-kapat ng kabuuang memory. Ang bawat unicorn worker ay isang buong Ruby process, at nagpapatakbo ang Sidekiq ng mga background job kasabay ng mga ito. Kaya nakabatay ang paggamit ng memory sa sabay-sabay na request, hindi sa bilang ng mga registered member. Hindi mabigat na workload ang isang tahimik na forum na may ilang daang member.

Huwag i-size ang server batay sa isang numerong nasa artikulo, kabilang na ang artikulong ito. Sukatin ang sarili mong workload.

free -m
docker stats --no-stream

Kapag palaging ginagamit ang swap at mabagal ang mga page, kulang ang RAM mo. Kung stable ang memory pero mabagal ang mga page, malamang iba ang sanhi. Basahin muna ang ./launcher logs app bago bumili ng mas malaking plan. Magdagdag din ng check mula sa labas ng server, dahil tahimik na nagfa-fail ang forum kapag nauubusan ito ng memory nang 3am: ipinapaalam sa iyo ng self-hosted Uptime Kuma status monitor sa hiwalay na host ang problema bago pa ito mapansin ng mga member mo.

Kapag hindi angkop ang Discourse

Malaking application ang Discourse, mabigat i-install, at kailangan ng rebuild sa bawat setting na nasa app.yml. Kapalit ng gastos na ito ang mahusay na moderation tooling at search na gumagana pa rin kahit malaki na ang archive. Para sa tatlumpung taong gusto lang ng lugar para mag-usap, mas malaki ang kailangang machine kaysa sa pangangailangan ng usapan. Basahin muna ang paghahambing ng self-hosted forum software, at piliin ang Discourse dahil kailangan mo ang mga function nito, hindi dahil pamilyar ka na sa pangalan nito.

FAQ

Maaari ko bang i-install ang Discourse sa isang VPS nang walang domain name?

Hindi. Nakasaad sa configuration na kasama sa Discourse na hindi ito gagana gamit ang bare IP address, at kailangan ang DISCOURSE_HOSTNAME. Gumagawa ang Discourse ng absolute links mula sa hostname na iyon, kaya masisira ang mga link at mapipigilan ang pag-issue ng certificate kapag IP address ang ginamit. Gumawa ng A record bago magsimula, at kumpirmahin gamit ang dig +short forum.example.com na nagre-resolve ito sa address ng server mo.

Kailangan ko bang i-configure ang SMTP para matapos ang installation?

Simula August 2026, maaari mo itong laktawan. Nag-aalok ang setup wizard ng Discourse ID logins sa halip, at may switch ang app.yml para laktawan ang validation ng email setup. Para sa higit pa sa paunang pagsubok, i-configure ito dahil ipinapadala sa email ang account activation at password reset. Gumamit ng authenticated relay sa port 587 o 465, dahil bina-block ng karamihan sa VPS provider ang outbound port 25.

Bakit nabigo ang Discourse rebuild ko sa kalagitnaan?

Memory ang karaniwang sanhi. Mas malaki ang memory na kailangan ng asset compilation habang nagbu-build kaysa sa tumatakbong site, kaya maaaring mabigo ang rebuild kahit maayos na nase-serve ng server ang forum. Kung ipinapakita ng dmesg ang Out of memory: Killed process na tumutukoy sa isang ruby process, magdagdag ng swap (2 GB ang swapfile ng wizard) at patakbuhin muli ang ./launcher rebuild app. Kung YAML error naman ang dahilan ng paghinto ng build, malamang na may maling indentation sa app.yml.

Dapat bang nasa likod ng sarili kong nginx o Caddy ang Discourse?

Kapag nagse-serve rin ang VPS ng iba pang site, oo. Kung Discourse lang ang nasa server, hayaang gamitin ng container ang ports 80 at 443 at mag-issue ng sarili nitong certificate para mas kaunti ang kailangang i-manage. Para pagsaluhan ang machine, idagdag ang templates/web.socketed.template.yml, i-comment out ang mga linyang expose, at mag-proxy sa unix socket na /var/discourse/shared/standalone/nginx.http.sock. Ipasa ang X-Forwarded-Proto, kung hindi ay gagawa ang Discourse ng http:// links sa HTTPS page.

Paano ako magba-back up ng self-hosted Discourse?

Gamitin ang Backups page sa Admin, o patakbuhin ang discourse backup pagkatapos ng ./launcher enter app. Napupunta ang mga archive sa host sa /var/discourse/shared/standalone/backups/default/. Tiyaking naka-enable ang setting na nagsasama ng uploads, kopyahin ang /var/discourse/containers/app.yml kasama ng archive, at ilipat ang dalawa sa ibang machine dahil hindi makakaligtas sa failure na dapat nitong salagin ang backup na nasa parehong disk ng site.