VPS uzerine Docker ile Discourse kurulumu rehberi

Bir VPS üzerinde Discourse kurulumu: tek container, tek yapılandırma dosyası

Bir VPS üzerinde Discourse kurmak için projenin kendi yükleyicisini çalıştırır, kısa bir sihirbazı yanıtlar ve derleme işlemini beklersiniz. Discourse; Rails uygulaması, PostgreSQL, Redis ve nginx barındıran tek bir Docker container'ı olarak sunulur. Daha sonra değiştireceğiniz her şey tek bir dosyada, /var/discourse/containers/app.yml içinde yer alır ve her değişiklik siteye bir yeniden derleme (rebuild) işlemi ile yansıtılır.

Resmi kurulum yöntemi discourse_docker şeklindedir: bir launcher kabuk betiği ve bir dizi YAML şablonu. Discourse, kendi yazdığınız bir Compose dosyasını desteklemez ve container'ın elle parçalara ayrılması amaçlanmamıştır. Eğer Docker Compose ile bir VPS üzerinde servis çalıştırmaya alışkınsanız, farklı bir yapı ile karşılaşacağınızı bilmelisiniz. Burada docker compose up -d yoktur ve dağıtım işlemi ./launcher rebuild app ile gerçekleştirilir.

Başlamadan önce Discourse gereksinimleri

Dört temel gereksinim kullanıcıları zorlar ve her biri giriş sayfasına ulaşmadan önce sorun yaratır.

• Bellek. Tek bir container; PostgreSQL, Redis, Sidekiq ve Ruby web sunucusunu çalıştırır. Derleme adımı varlıkları (assets) derler ve çalışan siteden daha fazla belleğe ihtiyaç duyar.
• Gerçek bir alan adı. Dağıtılan örnek yapılandırma dosyası bunu açıkça belirtir: "Discourse, salt IP adresi ile çalışmaz."
• Giden posta yolu. Hesap aktivasyonu, parola sıfırlama, yönetici davetleri ve özet postaların tümü SMTP (simple mail transfer protocol) üzerinden gönderilir.
• 80 ve 443 numaralı portların sunucuda boş olması; Discourse'u halihazırda kullandığınız bir proxy'nin arkasına taşımadığınız sürece bu gereklidir.

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

Resmi kurulum belgesi, swap alanı ile birlikte minimum 1 GB RAM ve 10 GB disk alanı belirler; önerilen değerler ise 2 GB RAM ve 20 GB disk alanıdır. İlk satırdaki değerleri, kurulumun tamamlanmasını sağlayan alt sınır olarak kabul edin; bu değerler bir topluluğu barındırmak için hedeflediğiniz performans değerleri değildir. Bu fark önemlidir çünkü bellek kullanımındaki zirve noktası trafik değil, derleme aşamasıdır.

Kurulumdan önce alan adını sunucuya yönlendirin

Kullanacağınız ana makine adı (hostname) için bir A kaydı oluşturun ve ardından bunu sunucunun kendisinden doğrulayın.

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

Her iki komut da aynı adresi döndürmelidir. Bu iki değerin eşleşmesi zorunludur; çünkü kurulum sihirbazı ana makine adınız üzerinden bir bağlantı testi gerçekleştirir ve başka bir yeri işaret eden bir kayıt bu testi geçemez. İki dakika önce oluşturduğunuz bir kayıt hala önbellekte olabilir; bu nedenle sihirbazla uğraşmak yerine eski TTL (time to live) süresinin dolmasını bekleyin.

Kaydın bir CDN tarafından proxy edilip edilmeyeceğine şimdiden karar verin. Proxy edilmiş bir kayıt, sunucu adresinizi gizler; bu durumda ACME (otomatik sertifika yönetim ortamı) sınaması Discourse yerine proxy tarafından yanıtlandığı için container sertifika isteği başarısız olur. İlk kurulum sırasında kaydı proxy edilmemiş (unproxied) durumda tutun.

Resmi yükleyiciyi çalıştırın

Tek bir komut git kurulumunu yapar, Docker'ı kendi yükleme betiği ile kurar, discourse_docker deposunu /var/discourse dizinine kopyalar ve kurulum sihirbazını başlatır.

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

Eğer Docker sunucuda zaten yüklüyse ve her adımı kendiniz görmek istiyorsanız, aynı işlemleri manuel olarak gerçekleştirin.

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

Komutu root yetkileriyle çalıştırın. Normal bir kullanıcı ile başlatıldığında, discourse-setup derhal This script must be run as root. Please sudo or log in as root first. hatasıyla durur. Sunucuda Docker yüklü değilse, manuel kopyalama işlemi sizin yerinize hiçbir kurulum yapmayacağı için süreç Docker is not installed. Please install Docker first. hatasıyla sonlanır.

Kurulum sihirbazının sordukları ve yazdıkları

Ağustos 2026 itibarıyla discourse-setup ince bir sarmalayıcıdır. Sihirbazın yapılandırdığı makineyi inceleyebilmesi için discourse/setup-wizard:release uygulamasını, host ağı ve Docker soketi bağlı olacak şekilde bir container olarak çalıştırır. Sunucu adı ve yönetici e-posta adreslerini, ardından SMTP bloğunuzu ister. containers/app.yml dosyasını yazar ve ardından yeniden derleme yapar.

Başlamadan önce bilinmesi gereken iki davranış vardır. Makinenin belleği düşükse ve swap alanı yoksa, sihirbaz durur ve oluşturmayı teklif eder: sarmalayıcı daha sonra 2 GB boyutunda bir /swapfile oluşturur, bunu /etc/fstab dosyasına ekler, /etc/sysctl.d/30-discourse-swap.conf içinde vm.swappiness = 10 ayarını yapar ve sihirbazı yeniden başlatır. Sihirbaz tamamlandığında Rebuilding app in 5 seconds (Ctrl+C to cancel)... çıktısını verir ve host üzerinde ./launcher rebuild app komutunu çalıştırır. Bu derleme işlemi küçük bir VPS üzerinde birkaç dakika sürer; her varlık sıfırdan derlendiği için ilk derleme en yavaş olanıdır.

./discourse-setup --help, bir sorun olduğunda önemli olan bayrakları listeler. --skip-rebuild yapılandırmayı derleme yapmadan yazar, --skip-connection-test ise DNS ve port kontrollerini atlar. --skip-connection-test bayrağını yalnızca testin neden başarısız olduğunu bildiğiniz durumlarda kullanın; örneğin host, kontrolünüz altındaki bir ağ güvenlik duvarının arkasında yer alıyorsa.

İlk yeniden derleme öncesinde app.yml dosyasını okuyun

Sihirbaz, artık sizin sorumluluğunuzda olan bir dosya oluşturur. Bu dosyayı sudo nano /var/discourse/containers/app.yml ile açın. Dosyanın içeriği, sistemin neredeyse tüm davranışlarını belirler.

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, sitenin yanıt vereceği adrestir ve Discourse bağlantılarını bu adrese göre oluşturur; dolayısıyla hatalı bir değer girilmesi, sitenin bir kez yüklenip ardından sizi başka bir yere yönlendirmesine neden olur. DISCOURSE_DEVELOPER_EMAILS virgülle ayrılmış bir listedir ve bu listedeki adresler, ilk kayıt sırasında otomatik olarak yönetici yetkisi kazanır. Kendi e-posta adresinizi buraya ekleyin ve kayıt işlemini bu adresle yapın; ilk yönetici hesabı bu şekilde oluşturulur.

Dosya, SMTP parolanızı düz metin olarak saklar, bu nedenle dizine erişimi sudo chmod 700 /var/discourse/containers ile kısıtlayın. Dosya YAML formatındadır ve bu formatta boşluk karakterleri yapılandırmanın bir parçasıdır; yanlış hizalanmış bir anahtar, derleme işleminin ayrıştırma hatasıyla başarısız olmasına ve sitenizin çalışmamasına yol açar. Örnek dosyanın içinde belirtilen bir tuzak mevcuttur. Tırnak içine alınmamış bir parolanın içindeki # karakteri bir yorum satırı başlatır; bu nedenle, bu karakteri içeren tüm parolaları tırnak içine alın.

E-posta kurulumu çoğu kurulumu durduran adımdır

Ağustos 2026 itibarıyla kurulum sihirbazı, SMTP ayarlarını atlamanıza ve bunun yerine Discourse ID girişlerini kullanmanıza olanak tanır; ayrıca app.yml, e-posta kurulum doğrulamasını atlama işlevi gören eşleşen bir DISCOURSE_SKIP_EMAIL_SETUP anahtarı içerir. Yazılıma ilk kez göz atmak için bu adımı atlamak makuldür. Ancak bir topluluk için bu kötü bir tercihtir; çünkü giden e-posta trafiği olmadığında hiç kimse hesap aktivasyonu yapamaz veya şifre sıfırlayamaz.

Pratik sorun, çoğu VPS sağlayıcısının 25 numaralı giden portu engellemesidir; bu nedenle sunucu üzerindeki standart bir posta sunucusu teslimat yapamaz. 587 numaralı port üzerinden veya örtük TLS (transport layer security) ile 465 numaralı port üzerinden kimlik doğrulamalı bir aktarıcı (relay) kullanın. 465 numaralı port için, örnek yapılandırmada bu port için önerilen DISCOURSE_SMTP_FORCE_TLS: true ayarını yapılandırın. Yeniden oluşturma (rebuild) işleminden önce ana makineden erişilebilirliği test edin.

nc -vz smtp.example.com 587

Sağlıklı bir sonuç, succeeded! ile biten tek bir satırdır. Komutun yanıt vermeyip zaman aşımına uğraması, portun VPS'nizden çıkan yolda engellendiği anlamına gelir ve hiçbir Discourse ayarı bunu düzeltemez. Sağlayıcınızın izin verdiği bir porta geçin veya sağlayıcınızdan portu açmasını talep edin.

Site ayağa kalktıktan sonra, Admin panelindeki Email sayfasından bir test mesajı gönderin ve ardından aynı sayfadaki Skipped (Atlanan) ve Bounced (Geri Dönen) sekmelerini inceleyin. Bu sekmeler, Discourse'un göndermeyi reddettiği veya aktarıcının geri çevirdiği postaları kaydettiği yerdir; burada belirtilen nedenler, günlük kayıtlarını okumaktan daha hızlı sonuç verir.

TLS: sertifikayı container'ın kendi almasını sağlama

Discourse 80 ve 443 numaralı portları yönetiyorsa, kendi yerleşik sertifika oluşturma mekanizmasını kullanın. Yukarıda gösterilen iki SSL şablonu satırının yorum işaretlerini kaldırın ve ardından yeniden derleyin. Şablon acme.sh sürecini yönetir, sertifikaları /shared/ssl altındaki paylaşımlı birimde saklar, bunları container içinde belirli bir takvime göre yeniler ve Discourse'u HTTPS kullanmaya zorlayacak şekilde yapılandırır.

HTTP sınaması (challenge) bu port üzerinden yanıtlandığı için, bu işlemin çalışması adına 80 numaralı portun internetten erişilebilir olması gerekir. Yalnızca 443 numaralı porta izin veren bir güvenlik duvarı, derleme işleminin tamamlanmasına ancak sertifikanın hiçbir zaman oluşturulamamasına neden olur. Yeniden derleme işleminden hemen sonra sonucu ./launcher logs app ile kontrol edin.

Nginx veya Caddy'yi ön tarafa koymalı mısınız?

Eğer Discourse, VPS üzerindeki tek web servisi ise bunu yapmayın. Konteyner zaten optimize edilmiş bir nginx çalıştırır; ikinci bir proxy ise fazladan bir sekme, yenilenmesi gereken bir sertifika ve yeni bir başlık (header) hatası kaynağı ekler.

Aynı VPS üzerinde başka siteler de barındırıyorsa ön tarafa bir proxy ekleyin. Şablon listesine templates/web.socketed.template.yml ekleyin, her iki expose satırını yorum satırı haline getirin ve iki SSL şablonunu yorum satırı olarak bırakın. Konteyner bu durumda /var/discourse/shared/standalone/nginx.http.sock adresindeki bir unix socket üzerinde dinleme yapar ve hiçbir portu işgal etmez; bu da 80 ve 443 portlarını kendi proxy'niz için serbest bırakır.

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 sonrasındaki iki nokta üst üste işareti, nginx'in unix socket sözdiziminin bir parçasıdır ve sudo nginx -t bu işaret olmadan yapılandırmayı reddeder. X-Forwarded-Proto de isteğe bağlı değildir. Discourse mutlak bağlantılar (absolute links) yazar; bu başlık olmadan HTTPS sayfasında http:// bağlantıları üretir ve tarayıcılar bunları karma içerik (mixed content) olarak engelleyebilir. Konteyner socket üzerinden bağlandığında TLS yönetimi sizin sorumluluğunuzdadır; bu nedenle sertifikayı ana makine üzerinde Ubuntu 24.04 ve nginx üzerinde Certbot kullanarak oluşturun. Henüz bir proxy seçmediyseniz, nginx, Caddy ve Traefik karşılaştırması yapacağınız tercihin getireceği sonuçları açıklar.

Yeniden oluşturma işlemleri, yükseltmeler ve fiilen kullanacağınız komutlar

cd /var/discourse
./launcher rebuild app

rebuild, çalışan container'ı siler, app.yml üzerinden yenisini oluşturur ve başlatır. Site, oluşturma süreci boyunca çevrimdışı kalır; bu nedenle her yapılandırma değişikliğini birkaç dakikalık planlı kesinti olarak değerlendirin.

Yalnızca env: altındaki değerleri değiştirmek için bu işleme gerek yoktur. ./launcher destroy app && ./launcher start app, container'ı halihazırda oluşturduğunuz imajdan saniyeler içinde yeniden yaratır. templates: veya hooks: altındaki herhangi bir değişiklik imajın kendisini etkilediği için tam bir yeniden oluşturma gerektirir.

Yükseltmeler iki şekilde gerçekleşir. Ara sürümler, app.yml tarafından oluşturma sırasında klonlanan docker_manager eklentisi aracılığıyla /admin/upgrade üzerindeki web arayüzünden uygulanır. Temel imaj veya şablonlardaki değişiklikler ise git üzerinden gelir.

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

Yeniden oluşturma işlemleri, küçük sunucuların başarısız olduğu noktalardır; çünkü varlık derleme (asset compilation) süreci, tüm sistemin bellek kullanımının zirve yaptığı andır. İşlem sırasında duran ve dmesg çıktısında ruby sürecini işaret eden Out of memory: Killed process gibi bir satır gösteren bir oluşturma işlemi, site öncesinde düzgün çalışıyor olsa bile bellek yetersizliğinden kaynaklanmıştır. Swap alanı ekleyin ve yeniden oluşturma işlemini tekrar çalıştırın.

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

logs, container'ın çıktısını yazdırır, enter içinde bir kabuk (shell) açar ve cleanup, 24 saatten uzun süredir durdurulmuş olan container'ları kaldırır. cleanup komutunu zaman zaman çalıştırın; çünkü her yeniden oluşturma işlemi geride eski bir container bırakır ve küçük bir VPS üzerindeki disk alanı sessizce tükenir.

Yedekler ve yedeğin içermediği dosyalar

Yedekleri Admin panelindeki Backups sayfasından alın. Arşiv, sunucuda /var/discourse/shared/standalone/backups/default/ dizinine kaydedilir. Aynı işlem bir kabuk (shell) üzerinden de çalıştırılabilir.

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

discourse restore <filename> komutu işlemi tersine çevirir; discourse enable_restore komutunu çalıştırmadığınız sürece geri yükleme işlemleri reddedilir. Bu koruma mekanizması, hatalı bir komutun canlı bir forumun üzerine yazmasını engellemek için mevcuttur.

Kapatmanız gereken iki açık bulunmaktadır. Arşiv veritabanını içerir; yüklenen dosyaları ise yalnızca yüklemeleri içeren yedekleme ayarı açık olduğunda barındırır, bu nedenle güvenmeden önce ilgili ayarı kontrol edin. Arşiv hiçbir zaman app.yml dosyasını içermez; bu yüzden yeni bir VPS üzerine yapılan geri yüklemede hostname ve SMTP bloğunuzu tekrar yapılandırmanız gerekir. Bu, söz konusu dosyanın da sunucudan dışarı kopyalanması gerektiği anlamına gelir.

Arşiv ayrıca koruduğu siteyle aynı disk üzerinde durur; bu bir yedekleme değildir. Arşivi düzenli bir program dahilinde başka bir yere aktarın.

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

Yoğun bir forumun RAM maliyeti

Bootstrap süreci, tespit ettiği bellek ve CPU miktarına göre UNICORN_WORKERS ve db_shared_buffers değerlerini ayarlar; örnek yapılandırma dosyası ise paylaşımlı arabellekleri (shared buffers) toplam belleğin dörtte biri ile sınırlar. Her unicorn işçisi tam bir Ruby sürecidir ve Sidekiq arka plan işlerini bunların yanında çalıştırır; bu nedenle bellek kullanımı, kayıtlı üye sayısından ziyade eşzamanlı istek sayısına göre artar. Birkaç yüz üyeli sakin bir forum ağır bir iş yükü oluşturmaz. Sunucuyu paylaşan diğer uygulamalar genellikle daha belirleyicidir; eğer bu bir fotoğraf kütüphanesi ise, PhotoPrism ve Immich karşılaştırması içindeki ölçülen RAM taban değerleri, bir Discourse yeniden derleme işleminin tamamlanması için yeterli alanın kalıp kalmadığını size gösterecektir.

Sunucu boyutunu, bu makale dahil olmak üzere herhangi bir yazıdaki sayıya göre belirlemeyin. Kendi ölçümlerinizi yapın.

free -m
docker stats --no-stream

Sürekli kullanımda olan swap alanı ve yavaş sayfalar, RAM kapasitenizin yetersiz olduğu anlamına gelir. Sabit bellek kullanımı ile birlikte yavaş sayfalar genellikle başka bir soruna işaret eder; bu nedenle daha üst bir plana geçmeden önce ./launcher logs app kısmını okuyun. Ayrıca sunucu dışından bir denetim mekanizması ekleyin; çünkü gece saat 03:00'te belleği tükenen bir forum sessizce çöker: ayrı bir ana makine üzerindeki kendi kendine barındırılan Uptime Kuma durum izleyicisi, durumu üyelerinizden önce size bildirir.

Discourse'un yanlış tercih olduğu durumlar

Discourse, kurulumu ağır olan ve app.yml içinde yer alan her ayar değişikliği için yeniden derleme (rebuild) döngüsü gerektiren büyük bir uygulamadır. Bu maliyet, gelişmiş moderasyon araçları ve arşiv büyüdüğünde dahi çalışmaya devam eden bir arama motoru sağlar. Sohbet etmek için bir yere ihtiyaç duyan otuz kişilik bir grup için bu, ihtiyacın çok üzerinde bir sistem kaynağı tüketimidir. Öncelikle kendi kendine barındırılan forum yazılımlarının karşılaştırmasını okuyun ve Discourse'u sadece bildiğiniz bir isim olduğu için değil, sunduğu özelliklere gerçekten ihtiyaç duyduğunuz için seçin.

FAQ

Discourse'u alan adı olmadan bir VPS üzerine kurabilir miyim?

Hayır. Sunulan yapılandırma, Discourse'un çıplak bir IP adresi ile çalışmayacağını belirtir ve DISCOURSE_HOSTNAME gereklidir. Discourse, mutlak bağlantıları bu ana bilgisayar adından oluşturur; bu nedenle orada bir IP adresi kullanmak bağlantıları bozar ve sertifika düzenlenmesini engeller. Başlamadan önce bir A kaydı oluşturun ve dig +short forum.example.com ile bu kaydın sunucunuzun adresine çözümlendiğini doğrulayın.

Kurulumu tamamlamak için SMTP yapılandırmam gerekiyor mu?

Ağustos 2026 itibarıyla bu adımı atlayabilirsiniz. Kurulum sihirbazı bunun yerine Discourse ID ile giriş yapma seçeneği sunar ve app.yml, e-posta kurulum doğrulamasını atlayan bir anahtar içerir. İlk incelemenin ötesindeki her kullanım için SMTP yapılandırılmalıdır; çünkü hesap aktivasyonu ve parola sıfırlama işlemleri e-posta yoluyla gerçekleşir. Çoğu VPS sağlayıcısı 25 numaralı port üzerinden giden trafiği engellediği için 587 veya 465 numaralı portlar üzerinden kimlik doğrulamalı bir aktarıcı (relay) kullanın.

Discourse yeniden oluşturma (rebuild) işlemim neden yarıda kesildi?

Bunun yaygın nedeni bellek yetersizliğidir. Derleme sırasındaki varlık derleme (asset compilation) işlemi, çalışan siteden daha fazla bellek gerektirir; bu nedenle forumu sorunsuz çalıştıran bir sunucu, yeniden oluşturma sırasında başarısız olabilir. Eğer dmesg, Out of memory: Killed process içerisinde bir ruby sürecini işaret ediyorsa, swap alanı ekleyin (sihirbazın kendi swap dosyası 2 GB'tır) ve ./launcher rebuild app komutunu tekrar çalıştırın. YAML hatasında duran bir derleme ise app.yml dosyasındaki bir girinti hatasına işaret eder.

Discourse kendi Nginx veya Caddy sunucumun arkasında mı çalışmalı?

Yalnızca VPS üzerinde başka siteler de barındırılıyorsa. Sunucuda tek başına çalışıyorsa, container'ın 80 ve 443 numaralı portları tutmasına ve kendi sertifikasını düzenlemesine izin verin; bu daha az hareketli parça anlamına gelir. Makineyi paylaşmak için templates/web.socketed.template.yml ekleyin, expose satırlarını yorum satırı yapın ve /var/discourse/shared/standalone/nginx.http.sock adresindeki unix socket'e proxy yapın. X-Forwarded-Proto başlığını iletin, aksi takdirde Discourse bir HTTPS sayfası üzerinde http:// bağlantıları üretir.

Self-hosted bir Discourse yedeğini nasıl alırım?

Yönetim panelindeki Yedekler (Backups) sayfasını kullanın veya ./launcher enter app komutundan sonra discourse backup komutunu çalıştırın. Arşivler ana makinede /var/discourse/shared/standalone/backups/default/ dizinine kaydedilir. Yüklemeleri içeren ayarın açık olduğundan emin olun, /var/discourse/containers/app.yml dosyasını arşivle birlikte kopyalayın ve her ikisini de başka bir makineye taşıyın; çünkü siteyle aynı diskte tutulan bir yedek, varlık sebebi olan disk arızası durumunda kurtarılamaz.