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 proyekto, sagutin ang maikling wizard, at maghintay matapos ang build. Inilalabas ng Discourse bilang iisang Docker container ang Rails application, PostgreSQL, Redis, at nginx. Nasa iisang file ang lahat ng babaguhin mo sa susunod, /var/discourse/containers/app.yml, at napupunta sa site ang bawat pagbabago 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 idinisenyo ang container para manu-manong paghiwa-hiwalayin. Kung nakasanayan mong magpatakbo ng mga serbisyo sa VPS gamit ang Docker Compose, asahan ang ibang setup. Walang docker compose up -d dito, at ang ./launcher rebuild app ang deploy.

Ano ang kailangan ng Discourse bago magsimula

May apat na requirement na madalas nakaliligtaan. Bawat isa ay maaaring maging sanhi ng problema bago pa makarating sa login page.

• Memory. Isang container ang nagpapatakbo ng PostgreSQL, Redis, Sidekiq, at Ruby web server. Kino-compile ng build step ang mga asset at nangangailangan ito ng mas malaking memory kaysa sa tumatakbong site.
• Tunay na domain name. Malinaw itong sinasabi sa kasamang sample config: "Hindi gagana ang Discourse gamit ang bare IP number."
• Outbound mail path. Dumadaan sa SMTP (simple mail transfer protocol) ang account activation, password reset, admin invite, at digest mail.
• Libreng ports 80 at 443 sa host, maliban kung sadya mong ilagay ang Discourse sa likod ng proxy na pinapatakbo mo na.

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

Itinatakda ng opisyal na install document ang minimum na 1 GB ng RAM na may swap at 10 GB ng disk. Inirerekomenda naman nito ang 2 GB ng RAM at 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 nangyayari ang pinakamataas na paggamit ng memory sa build, hindi sa 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 pareho ang address na ilabas ng dalawang command. Kailangan magtugma ang mga ito dahil nagpapatakbo ang setup wizard ng connection test gamit ang iyong hostname. Mabibigo ang test kung sa ibang address pa rin nakaturo ang record. Maaari ring naka-cache pa ang record na ginawa mo dalawang minuto ang nakalipas. Hintaying lumipas ang dating TTL (time to live) sa halip na pilitin ang wizard.

Magpasya ngayon kung ipo-proxy ng CDN ang record. Itinatago ng proxied record ang address ng server. Dahil dito, 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 sa unang installation.

Patakbuhin ang official installer

Isang command ang nag-i-install ng git, nag-i-install ng Docker gamit ang sariling install script ng Docker, nagki-clone ng discourse_docker sa /var/discourse, at nagsisimula ng 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 mano-mano 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 para sa iyo.

Mga itinatanong ng setup wizard at mga isinusulat nito

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

May dalawang behavior na dapat malaman bago ka 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 ng 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 mali. Isinusulat ng --skip-rebuild ang config nang hindi nagsasagawa ng build, at nilalaktawan ng --skip-connection-test ang mga pagsusuri sa DNS at port. Gamitin lamang ang --skip-connection-test kung alam mo na kung bakit nabibigo ang test, halimbawa kapag nasa likod ng network firewall na kontrolado mo 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 behavior ang tinutukoy.

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 magre-redirect sa ibang lokasyon. Ang DISCOURSE_DEVELOPER_EMAILS ay comma-separated list, at awtomatikong nagiging admin ang mga address na iyon sa unang signup. Ilagay doon ang sarili mong address at gamitin iyon sa pag-register, dahil ganoon ginagawa ang unang admin account.

Naka-store sa plain text ang SMTP password sa file, kaya higpitan ang access sa directory gamit ang sudo chmod 700 /var/discourse/containers. YAML din ito, kaya mahalaga ang whitespace sa configuration: kapag mali ang alignment ng key, mabibigo ang build dahil sa parse error at wala kang magiging site. May isang karaniwang pagkakamali na nakadokumento mismo sa sample file. Ang # sa loob ng password na hindi naka-quote ay nagsisimula ng comment, kaya i-quote ang anumang password na naglalaman nito.

Email ang hakbang na kadalasang nagpapahinto sa karamihan ng installation

Simula Agosto 2026, hinahayaan ng wizard na laktawan ang SMTP at gamitin ang Discourse ID logins. May katumbas na app.yml switch ang DISCOURSE_SKIP_EMAIL_SETUP, na inilalarawan doon bilang paglalaktaw sa validation ng email setup. Makatuwiran ang paglaktaw kung gusto mo lang munang tingnan ang software. Hindi ito magandang piliin para sa isang community, dahil walang makakapag-activate ng account o makakapag-reset ng password kung walang outbound mail.

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 port 465 na may implicit TLS (transport layer security). Para sa port 465, itakda ang DISCOURSE_SMTP_FORCE_TLS: true, na inirerekomenda ng sample config para sa port na iyon. Subukan muna ang reachability mula sa host bago ka mag-rebuild.

nc -vz smtp.example.com 587

Ang tamang resulta ay isang linyang nagtatapos sa succeeded!. Kapag nag-hang ang command at kalaunan ay nag-timeout, ibig sabihin ay bina-block ang port sa outbound path mula sa iyong VPS, at walang Discourse setting na makakapag-ayos nito. Gumamit ng port na pinapayagan ng provider, o hilingin sa provider na buksan ito.

Kapag gumagana 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 itinatala ng Discourse ang mail na tumanggi itong ipadala at ang mail na tinanggihan ng relay. Nakalista rin dito ang dahilan, kaya mas mabilis ito kaysa magbasa ng logs.

TLS: hayaan ang container na kumuha ng sarili nitong certificate

Kung ang Discourse ang gumagamit sa ports 80 at 443, gamitin ang built-in nitong certificate issuance. I-uncomment ang dalawang SSL template line na ipinakita sa itaas, pagkatapos ay mag-rebuild. Kinokontrol ng template ang acme.sh, iniimbak ang mga certificate sa shared volume sa ilalim ng /shared/ssl, nire-renew ang mga ito ayon sa iskedyul sa loob ng container, at kino-configure ang Discourse na piliting gamitin ang HTTPS.

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

Maglagay ba ng nginx o Caddy sa harap?

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

Maglagay ng proxy sa harap nito kapag iba pang site ang sine-serve ng parehong VPS. Idagdag ang templates/web.socketed.template.yml sa listahan ng templates, i-comment out ang dalawang linyang expose, at manatiling 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, kaya 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 trailing colon pagkatapos ng .sock, at tatanggihan ng sudo nginx -t ang configuration kapag wala ito. Hindi rin optional ang X-Forwarded-Proto. Gumagawa ang Discourse ng mga absolute link, kaya kung wala ang header na iyon, naglalabas ito ng http:// links sa HTTPS page at bina-block ng mga browser ang mga ito bilang mixed content. Kapag gumagamit na ng socket ang container, ikaw na ang mamamahala sa TLS, kaya mag-issue ng certificate sa host gamit ang Certbot sa Ubuntu 24.04 at nginx. Kung hindi ka pa nakapipili 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 kasalukuyang tumatakbong container, gumagawa ng bagong container mula sa app.yml, at sinisimulan ito. Offline ang site sa buong proseso ng build. Ituring ang bawat pagbabago sa configuration bilang nakaiskedyul na downtime na ilang minuto.

Hindi ito kailangan kapag mga value lamang sa ilalim ng env: ang binabago. Muling ginagawa ng ./launcher destroy app && ./launcher start app ang container mula sa image na na-build mo na. Ilang segundo lamang ito. Binabago ng anumang nasa ilalim ng templates: o hooks: ang image mismo. Kailangan nito ang buong rebuild.

Dumarating ang mga upgrade sa dalawang paraan. Ina-apply ang point release mula sa web interface sa /admin/upgrade. Ibinibigay ito ng docker_manager plugin na kino-clone ng app.yml habang nagbu-build. Mula sa git nagmumula 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: ang asset compilation ang pinakamataas na memory usage ng buong system. Kapag huminto ang build sa kalagitnaan at may linyang tulad ng Out of memory: Killed process sa output ng dmesg na tumutukoy sa isang ruby process, naubusan ng memory ang build kahit maayos na tumatakbo ang site bago nito. Magdagdag ng swap at patakbuhin muli ang rebuild.

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

Inilalabas 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 tumigil. Paminsan-minsang patakbuhin ang cleanup, dahil nag-iiwan ng lumang container ang bawat rebuild at tahimik na nauubusan ng disk space ang isang maliit na VPS.

Mga backup, at ang file na hindi kasama sa backup

Gumawa ng mga backup mula sa Backups page sa Admin. Napupunta 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 hindi pinapayagan ang restore hangga't hindi mo pinapatakbo ang discourse enable_restore. Nariyan ang guard upang hindi aksidenteng ma-overwrite ng isang command ang aktibong forum.

May dalawang puwang na kailangan mong punan. Kasama sa archive ang database. Kasama rin dito ang mga uploaded file kung naka-on ang backup setting na nagsasama ng uploads, kaya suriin muna ang setting na iyon bago mo ito pagkatiwalaan. Hindi nito kailanman kasama ang app.yml. Kaya kapag nag-restore sa isang 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 tunay na backup. Kopyahin ang archive sa ibang lokasyon ayon sa schedule.

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

Magkano sa RAM ang 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. 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 rehistradong member. Hindi mabigat na workload ang isang tahimik na forum na may ilang daang member. Karaniwang mas mahalaga kung ano pa ang nakikihati sa server. Kung photo library iyon, sasabihin sa iyo ng nasukat na minimum RAM sa paghahambing ng PhotoPrism at Immich kung may sapat pang headroom ang server para matapos ang Discourse rebuild.

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

free -m
docker stats --no-stream

Ibig sabihin ng palaging paggamit ng swap kasabay ng mababagal na page na kulang ang RAM. Kung matatag ang memory pero mabagal ang mga page, malamang ibang bagay ang sanhi. Basahin muna ang ./launcher logs app bago bumili ng mas malaking plan. Magdagdag din ng check mula sa labas ng server. Tahimik na nagfa-fail ang forum kapag nauubusan ito ng memory sa 3am. Ipapaalam sa iyo ng self-hosted Uptime Kuma status monitor sa hiwalay na host ang problema bago pa ito mapansin ng mga member.

Kapag hindi angkop ang Discourse

Malaking application ang Discourse, mabigat i-install, at kailangan itong i-rebuild sa bawat setting na nasa app.yml. Kapalit nito ang mahusay na moderation tooling at search na gumagana pa rin kahit malaki na ang archive. Para sa 30 taong gusto lang ng lugar para mag-usap, mas malaki ang kailangan nitong machine kaysa sa pangangailangan ng pag-uusap. Basahin muna ang paghahambing ng self-hosted forum software, at piliin ang Discourse dahil kailangan mo ang mga kakayahan nito, hindi dahil ito ang pangalang dati mo nang alam.

FAQ

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

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

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

Simula Agosto 2026, maaari mo itong laktawan. Nag-aalok ang setup wizard ng mga Discourse ID login sa halip, at may switch ang app.yml para laktawan ang validation ng email setup. Para sa paggamit na lampas 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 maraming memory ang kailangan ng asset compilation habang nagbu-build kaysa sa tumatakbong site, kaya maaaring mabigo pa rin ang rebuild kahit maayos na nagsi-serve ng forum ang server. Kung ipinapakita ng dmesg ang Out of memory: Killed process na tumutukoy sa isang ruby process, magdagdag ng swap—2 GB ang sariling 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 iba pang site din ang nagsi-serve ng VPS. Kung Discourse lamang ang nasa server, hayaan ang container na gumamit ng ports 80 at 443 at mag-isyu ng sarili nitong certificate. Mas kaunti ang kailangang i-configure sa ganitong setup. Para pagsaluhan ang machine, idagdag ang templates/web.socketed.template.yml, i-comment out ang mga linyang expose, at mag-proxy sa unix socket sa /var/discourse/shared/standalone/nginx.http.sock. I-forward ang X-Forwarded-Proto; kung hindi, maglalabas ang Discourse ng http:// links sa isang HTTPS page.

Paano ako gagawa ng backup 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/. Kumpirmahing naka-enable ang setting na nagsasama ng uploads, kopyahin ang /var/discourse/containers/app.yml kasama ng archive, at ilipat ang pareho sa ibang machine. Hindi makakaligtas sa failure na dapat nitong tugunan ang backup kapag nasa parehong disk ito ng site.