VPS Üzerinde Matrix Synapse Kurulumu ve Yönetimi

Bir Matrix Synapse sunucusunu ayakta tutmak için gerekenler

Matrix Synapse kurulumu kolaydır ancak ihmal edilmeye de müsaittir. Kurulum süreci bir apt deposu, bir yapılandırma dosyası, bir reverse proxy bloğu ve bir DNS kaydından ibarettir. Homeserver'ı bir yıl boyunca sağlıklı tutmak ise farklı bir çalışma gerektirir: gerçek bir veritabanı, düzenli olarak temizlenen bir medya deposu, yabancıların kullanımına kapalı bir kayıt sistemi ve sunucunun her iki yarısını da kapsayan bir yedekleme stratejisi.

Bu kılavuz Ubuntu 24.04 LTS sürümünü temel alır ve Synapse'i, Synapse projesinin Debian ve Ubuntu için sürdürdüğü resmi kaynak olan matrix.org apt deposundan kurar. Paket sürümleri birkaç haftada bir güncellendiği için burada herhangi bir sürüm numarası belirtilmemiştir. Aşağıdaki tüm yollar ve seçenekler güncel Synapse dokümantasyonundan alınmıştır.

Boyutlandırma: 1 vCPU ve 2 GB RAM size gerçekte ne sağlar?

Ağustos 2026 itibarıyla yayınlanan boyutlandırma sayfaları, bir Synapse homeserver kurulumu için genellikle 1 vCPU ve 2 GB RAM önermektedir. Bu öneri tek bir senaryo için geçerlidir: az sayıda kullanıcısı olan, küçük odalara sahip ve yoğun genel odalara dahil olmayan özel bir sunucu. Synapse belgeleri diğer durum hakkında oldukça açıktır. Belgeler, "#matrix:matrix.org gibi büyük genel odalara katılmak istiyorsanız en az 1 GB boş RAM" gereksinimini belirtir. Bu boş RAM, Python, Postgres ve çekirdek (kernel) kullanımının üzerine eklenmelidir.

Katılma işleminin çalışma mantığı nedeniyle tek bir oda bile boyutlandırma gereksinimlerinizi değiştirebilir. Yerel bir kullanıcı bir odaya katıldığında, homeserver'ınız o odanın tam katılımcısı haline gelir. Sunucunuz, odadaki diğer tüm sunuculardan gelen her etkinliği alır, her birinin imzasını doğrular ve odanın durumunu yerel olarak saklar. Büyük bir genel oda, yüzlerce sunucuya yayılmış binlerce üyeye sahip olduğundan, kullanıcınız odayı bir daha açmasa bile sunucunuz bu işlemleri sürekli olarak gerçekleştirir. Odadan daha sonra ayrılmak, halihazırda depoladığınız geçmişi silmez.

Synapse'in RAM kullanımının büyük kısmı önbelleklere (cache) gider. caches bölümü, tüm önbellekleri aynı anda ölçeklendiren bir global_factor içerir ve SYNAPSE_CACHE_FACTOR ortam değişkeni de aynı işlevi görür. Bu değeri yükseltmek, veritabanı sorgularından kaçınmak için RAM harcar. Düşürmek ise RAM tasarrufu sağlamak adına CPU ve Postgres süresini harcar. Postgres'in de kendi bellek ihtiyacı vardır; bu nedenle 2 GB RAM'li bir sunucuda her iki süreç de aynı megabaytlar için rekabet eder.

Küçük bir plan için iki pratik kural vardır. Swap alanı ekleyin: swap, Synapse'i hızlandırmaz ancak büyük bir odaya katılım sırasında çekirdeğin süreci sonlandırmasını (OOM kill) engeller. Ardından, ilk haftadan itibaren disk kullanımını izleyin; çünkü sınırsız şekilde büyüyen iki temel unsur medya deposu ve oda durum tablolarıdır; her ikisi de disk üzerinde yer kaplar.

Neden Postgres ve SQLite neden artık bir seçenek değil

Debian paketi varsayılan olarak SQLite ile başlar. Bu, ilk kurulum için uygundur ancak başkalarının kullandığı bir sunucu için yanlıştır. SQLite, aynı anda yalnızca bir yazma işlemine izin verir. Federasyon trafiği ve istemci istekleri aynı anda yazma işlemi gerçekleştirdiğinde, basit bir istek yavaş bir isteğin bitmesini bekler; kullanıcılarınızın bildirdiği belirti, uygulamanın rastgele zamanlarda birkaç saniyeliğine donmasıdır.

İkinci neden yapısal bir durumdur. Synapse'in worker süreçleri, birden fazla CPU çekirdeğini kullanmanın desteklenen yoludur ve worker süreçleri Postgres gerektirir. SQLite üzerinde kalmak, performansın yanı sıra yükseltme yolunu da kapatır.

Daha sonra geçiş yapmak desteklenmektedir ancak bu işlem kesinti süresi gerektirir, bu nedenle kullanıcılarınız olmadan önce geçişi yapın. Synapse, bir SQLite veritabanını hazır bir Postgres veritabanına kopyalayan synapse_port_db aracını içerir:

synapse_port_db --sqlite-database homeserver.db --postgres-config homeserver-postgres.yaml

Veritabanını Synapse'in yanında bir container içinde çalıştırmayı tercih ederseniz, bu durumun avantaj ve dezavantajları veritabanınızı Docker içinde veya ana makinede çalıştırma bölümünde açıklanmıştır.

Ubuntu 24.04 üzerinde Synapse kurulumu

sudo apt install -y lsb-release wget apt-transport-https
sudo wget -O /usr/share/keyrings/matrix-org-archive-keyring.gpg https://packages.matrix.org/debian/matrix-org-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/matrix-org-archive-keyring.gpg] https://packages.matrix.org/debian/ $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/matrix-org.list
sudo apt update
sudo apt install matrix-synapse-py3

Ubuntu 24.04 üzerinde lsb_release -cs komutu noble çıktısını verir ve matrix.org deposu bir noble paketi sunar. Ubuntu'nun kendi arşivindeki matrix-synapse paketini kullanmayın. Synapse projesi, bu paketlerin sürümlerinin geride kalması ve bilinen güvenlik açıklarını barındırması nedeniyle kullanılmamasını tavsiye eder.

Kurulum aracı bir sunucu adı ister ve cevabı /etc/matrix-synapse/conf.d/server_name.yaml dosyasına yazar. Bu soruya dikkatle cevap verin. server_name, her kullanıcı kimliğinin (@alice:example.com) iki nokta üst üste işaretinden sonra gelen kısımdır ve sunucunuzun oluşturduğu her odaya gömülür. Bunu daha sonra değiştirmek hiçbir şeyi taşımaz; bunun yerine farklı bir homeserver oluşturur. Synapse'in kendisi matrix.example.com üzerinde çalışacak olsa bile, alan adınızın yalın halini, yani example.com değerini kullanın. Delegasyon bu ikisini birbirine bağlar ve bu konu bir sonraki bölümün içeriğidir.

Paket, Synapse'i matrix-synapse kullanıcısı olarak çalıştırır, verilerini /var/lib/matrix-synapse dizininde tutar ve önce /etc/matrix-synapse/homeserver.yaml dosyasını, ardından /etc/matrix-synapse/conf.d/ dizinindeki tüm dosyaları okur. Kendi ayarlarınızı conf.d dizinindeki küçük dosyalara ekleyin. Paket yükseltmeleri bu dosyalara dokunmaz.

sudo systemctl restart matrix-synapse
systemctl status matrix-synapse
sudo journalctl -u matrix-synapse -n 100 --no-pager

Sağlıklı bir başlangıç, dinleyicileri ayağa kaldırır ve ardından sessizliğe geçer. systemd birimi, herhangi bir çıkıştan birkaç saniye sonra servisi yeniden başlatır; bu nedenle Synapse'in reddettiği bir yapılandırma, sürekli başlayan ve ölen bir birim olarak görünür. Günlük kayıtlarının son satırları, reddedilen anahtarın adını belirtir.

Synapse'i Postgres'e Yönlendirme

sudo apt install -y postgresql
sudo -u postgres createuser --pwprompt synapse_user
sudo -u postgres createdb --encoding=UTF8 --locale=C --template=template0 --owner=synapse_user synapse

Yerel ayarlar (locale) yalnızca görsel bir detay değildir. Synapse, farklı COLLATE ve CTYPE değerleriyle oluşturulmuş bir veritabanı üzerinde, veritabanı yapılandırmasında allow_unsafe_locale ayarlanmadığı sürece çalışmayı reddeder. Bu durumun belgelenen tek düzeltme yöntemi, veritabanını dump alıp doğru yapılandırılmış yeni bir veritabanına geri yüklemektir. Bu yüzden veritabanını ilk seferde doğru oluşturun.

database:
  name: psycopg2
  txn_limit: 10000
  args:
    user: synapse_user
    password: secretpassword
    dbname: synapse
    host: localhost
    port: 5432
    cp_min: 5
    cp_max: 10

Tüm yapılandırma dosyalarınızda tam olarak bir adet database: anahtarı bulundurun. conf.d altında ikinci bir kopya eklemek yerine homeserver.yaml içindeki SQLite bloğunu değiştirin; böylece hangi yapılandırmanın aktif olduğu konusunda bir belirsizlik kalmaz. Yeniden başlatın ve ardından Synapse'in gerçekten Postgres üzerinde çalıştığını doğrulayın:

sudo -u postgres psql synapse -c "SELECT count(*) FROM users;"

Bir sayı dönmesi, Synapse'in şema yapısını bu veritabanında oluşturduğu anlamına gelir. Eksik bir ilişki (relation) hakkında hata alıyorsanız, sistem hala SQLite dosyasına yazıyor demektir; bu da düzenlediğiniz yapılandırma dosyasının okunmadığını gösterir.

Reverse proxy, TLS ve .well-known dosyaları federasyon gereksinimleri

Synapse, 8008 numaralı portta localhost üzerinde HTTP dinler. TLS ve genel ağa açık port, önündeki reverse proxy'ye aittir.

listeners:
- port: 8008
  tls: false
  type: http
  x_forwarded: true
  bind_addresses:
  - '::1'
  - '127.0.0.1'
  resources:
  - names:
    - client
    - federation
    compress: false

x_forwarded: true, Synapse'e proxy tarafından ayarlanan X-Forwarded-For başlığına güvenmesini söyler. Bu ayar yapılmazsa tüm istemciler 127.0.0.1 adresinden geliyormuş gibi görünür; bu durumda hız sınırlayıcı (rate limiting) tüm trafiği tek bir yerel kullanıcıdan geliyormuş gibi algılar ve herkesi aynı anda kısıtlar.

location ~ ^(/_matrix|/_synapse/client) {
    proxy_pass http://localhost:8008;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header Host $host:$server_port;
    client_max_body_size 50M;
    proxy_http_version 1.1;
}

Synapse belgeleri, bu blokla ilgili günlerce süren hatalara yol açan bir uyarı içerir. proxy_pass içindeki port bilgisinden sonra, tek bir / karakteri dahi olsa, herhangi bir yol (path) eklemeyin. nginx bu durumda URI'yi kanonikleştirir; bu işlem gönderen sunucunun imzaladığı baytları değiştirir. Sonuç olarak federasyon istekleri imza doğrulamasından geçemezken, normal istemci istekleri çalışmaya devam eder.

client_max_body_size değeri, Synapse'in max_upload_size değerinden en az aynı büyüklükte olmalıdır. Eğer nginx daha küçük bir değer tutarsa, bu değerin üzerindeki yüklemeler Synapse'e ulaşmadan önce nginx tarafından 413 Request Entity Too Large hatasıyla reddedilir. Bu nedenle, hatanın nedenini açıklayan bir Synapse günlük kaydı oluşmaz.

Sertifika işlemleri için Ubuntu 24.04 üzerinde Certbot ve Let's Encrypt rehberini takip edin. Proxy seçimi konusunda kararsızsanız, reverse proxy karşılaştırması hangi aracın TLS işlemlerini sizin yerinize yapacağını açıklar.

Delegasyon, server_name adresinin example.com olarak kalmasını sağlarken Synapse'in matrix.example.com üzerinde çalışmasına olanak tanır. Çıplak alan adından (bare domain) şu iki dosyayı sunun:

location /.well-known/matrix/server {
    default_type application/json;
    return 200 '{"m.server": "matrix.example.com:443"}';
}

location /.well-known/matrix/client {
    default_type application/json;
    add_header Access-Control-Allow-Origin '*';
    return 200 '{"m.homeserver": {"base_url": "https://matrix.example.com"}}';
}

Sunucu dosyası, diğer ev sunucularına (homeserver) federasyon trafiğini nereye göndereceklerini bildirir; federasyonun varsayılan 8448 portu yerine 443 üzerinden çalışması bu sayede gerçekleşir. İstemci dosyası ise Matrix istemcilerine @alice:example.com adresinin arkasındaki URL'yi bildirir. İstemci dosyasında Access-Control-Allow-Origin başlığı kritiktir; tarayıcı tabanlı istemciler bu dosyayı cross-origin olarak çeker. Bu başlık olmazsa tarayıcı yanıtı engeller ve istemci, ev sunucunuzu bulamadığına dair hata verir.

Her iki dosya da example.com üzerinden geçerli bir TLS ile sunulmalıdır. Dosyaları kontrol edin, ardından dış dünyanın ne gördüğünü doğrulayın:

curl -s https://example.com/.well-known/matrix/server
curl -s https://matrix.example.com/_matrix/federation/v1/version

İlk komut yazdığınız JSON içeriğini döndürür. İkincisi, sunucu uygulamasını ve sürümünü belirten bir JSON nesnesi döndürür; bu, proxy'nin federasyon yolu üzerinden Synapse'e ulaştığını kanıtlar. Son olarak, alan adınızı https://federationtester.matrix.org adresindeki Matrix federasyon test aracından geçirin; bu araç, gerçek bir uzak sunucunun izlediği rotayı takip eder.

Federasyon kurmak veya kurmamak: bilinçli bir karar verin

Federasyon, Matrix'in temel amacıdır ancak aynı zamanda maliyetin de büyük kısmını oluşturur. Federasyon kuran bir homeserver, daha önce hiç duymadığınız sunuculardan gelen bağlantıları kabul eder, etkinliklerini alır, medyalarını önbelleğe alır ve kullanıcılarınızın etkileşime girdiği her oda için durum bilgisini saklar. Bu, varsayılan bir özellik değil, bir tehdit modeli kararıdır.

Kullanıcılarınızın diğer homeserver'lardaki kişilere ulaşması gerektiğinde veya taşınabilir bir kimlik Matrix'i seçme nedeniniz olduğunda federasyon kurun. Sunucu tek bir ekip için var olduğunda ve üzerindeki tüm hesaplar size ait olduğunda federasyon kurmayın. Kapalı bir sunucu daha az veri saklar, daha az veri alır ve kötüye kullanım için çok daha az ilgi çekicidir.

Federasyonu devre dışı bırakmak yerine kısıtlamak için Synapse bir izin listesi (allow list) kullanır:

federation_domain_whitelist:
- lon.example.com
- nyc.example.com

Belgeler, federasyon dinleyicisini güvenlik duvarı ile korumayı da önerir; böylece istenmeyen trafik Python içinde değil, ağ katmanında durdurulur. Federasyonu tamamen kapatmak için federation ifadesini dinleyici resources listesinden kaldırın, /.well-known/matrix/server yayınlamayın ve 8448 numaralı portu kapalı tutun.

Matrix'i çalıştırma nedeniniz özel ekip sohbeti ise ve federasyon hiçbir zaman bunun bir parçası olmadıysa, Synapse'e karar vermeden önce işletim maliyetini diğer self-hosted Slack alternatifleri ile karşılaştırın. Docker Compose üzerinde Rocket.Chat, başka bir organizasyonun oda durumunu saklamak zorunda olmadığı için daha küçük bir makinede ekip sohbeti hizmeti verebilir.

Medya deposu diski sessizce dolduran unsurdur

Kullanıcılarınızın yüklediği dosyalar kalıcı olarak diskinizde kalır. Diğer ev sunucularındaki (homeserver) kullanıcılar tarafından gönderilen dosyalar, istemcilerinizden biri bunları görüntülediği anda getirilir ve diskinize önbelleğe alınır. Ayrıca Synapse, görseller için küçük resimler (thumbnail) oluşturur; bu nedenle tek bir fotoğraf birden fazla dosyaya dönüşür. Varsayılan olarak hiçbir şeyin süresi dolmaz.

Depoyu bulun ve boyutunu ölçün:

grep media_store_path /etc/matrix-synapse/homeserver.yaml
sudo du -sh /var/lib/matrix-synapse/media_store

Kendi yapılandırmanızın çıktı verdiği yolu ölçün. Debian paketi, Synapse verilerini /var/lib/matrix-synapse altında tutar, bu nedenle depo genellikle orada bulunur. Ardından conf.d içinde bir saklama politikası belirleyin:

media_retention:
  local_media_lifetime: 90d
  remote_media_lifetime: 14d

Bu iki satırı dikkatlice okuyun, çünkü bunlar aynı türde ayarlar değildir. remote_media_lifetime bir önbelleğin süresini dolmaya zorlar ve sildiği her şey, dosyanın sahibi olan sunucudan tekrar getirilebilir. local_media_lifetime ise kendi kullanıcılarınızın yüklemelerini, belirtilen yaşa ulaştıklarında kalıcı olarak siler. Sohbet içinde belge paylaşan ve bunları gelecek yıl bulmayı bekleyen bir ekip, bu belgeleri kaybedecektir. Birçok sunucu yalnızca uzak (remote) değerini ayarlar.

Tek seferlik bir temizlik için yönetici API'si, milisaniye cinsinden bir Unix zaman damgası kabul eder:

BEFORE_TS=$(date -d '30 days ago' +%s%3N)
curl -X POST -H "Authorization: Bearer $ADMIN_TOKEN" \
  "https://matrix.example.com/_synapse/admin/v1/purge_media_cache?before_ts=$BEFORE_TS"

POST /_synapse/admin/v1/purge_media_cache, son erişim tarihi bu zaman damgasından önce olan uzak medya önbelleğini siler. POST /_synapse/admin/v1/media/delete?before_ts=<ms> ise aynı kurala göre yerel medyayı siler. Önce uzak medya temizliğini çalıştırın ve tekrar ölçüm yapın; çünkü federasyon kullanan bir sunucuda uzak önbellek genellikle daha büyük olan kısımdır.

İki ayar aynı diski besler. max_upload_size tek bir yüklemeyi sınırlar ve nginx içindeki client_max_body_size ile uyumlu kalmalıdır. url_preview_enabled: true, istemcilerin bağlantı önizlemelerini gösterebilmesi için sunucunuzun uzak sayfaları getirmesini sağlar; bu işlem bant genişliği harcar ve size yüklenmemiş içeriklerin küçük resimlerini depolar.

Homeserver'ınızı başkaları bulmadan önce kayıtları kapatın

Tarayıcılar, açık bir homeserver'ı günler içinde bulur. Hesap oluşturma herkese açık olduğunda, sunucunuz federasyon kurduğu her odada bir spam kaynağı haline gelir ve karşı taraftaki yöneticiler tüm alan adınızı engeller. Engelleme listeleri manuel olarak yönetildiği için, bu itibar kaybı temizlik sürecinden daha uzun sürer.

Synapse kapalı olarak gelir. enable_registration varsayılan olarak false değerindedir ve registration_requires_token varsayılan olarak false değerindedir. Ayrıca Synapse, enable_registration_without_verification: true ayarını yapmadığınız sürece, kayıt özelliği açıkken ve herhangi bir doğrulama adımı yokken çalışmayı reddeder. Bu reddetme kasıtlıdır; bu yüzden başlatma hatasını gidermek için bu özelliği açmayın.

İstediğiniz hesapları manuel olarak oluşturun:

sudo register_new_matrix_user -c /etc/matrix-synapse/homeserver.yaml http://localhost:8008

Bu komut kullanıcı adını, parolayı ve hesabın sunucu yöneticisi olup olmayacağını sorar. -c ile ilettiğiniz yapılandırmadan registration_shared_secret değerini okur; bu nedenle paylaşılan bir gizli anahtar (shared secret) bulamadığını bildirirse, -c parametresini bu anahtarı içeren dosyaya yönlendirin.

Hesapları manuel olarak oluşturmak ölçeklenemez hale geldiğinde, kayıt jetonları (registration tokens) ara bir çözüm sunar. Jeton, yeni bir kullanıcının kayıt sırasında sunması gereken bir dizidir ve her jetonun kaç kez kullanılabileceğine dair bir sınır belirlenebilir:

enable_registration: true
registration_requires_token: true

curl -X POST -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"uses_allowed": 1}' \
  https://matrix.example.com/_synapse/admin/v1/registration_tokens/new

token kısmını gövdeden çıkarırsanız, Synapse bir jeton oluşturur ve döndürür. GET /_synapse/admin/v1/registration_tokens, aktif olan jetonları listeler. Her iki çağrı da, yukarıda oluşturduğunuz yönetici kullanıcısı ile giriş yaparak elde edeceğiniz bir sunucu yöneticisi erişim jetonu gerektirir.

Hesapları başka bir yerde yöneten bir organizasyon, yerel parolaları tamamen devre dışı bırakabilir; çünkü Synapse giriş işlemlerini bir OIDC (OpenID Connect) sağlayıcısına devredebilir. Örneğin, Self-hosted SSO sağlayıcısı olarak Authentik kullanılabilir. Böylece sisteme katılanlar ve ayrılanlar tek bir merkezden yönetilir.

Sunucuyu gerçekten yeniden inşa edebilen bir yedekleme

Bir Synapse yedeklemesi üç parçadan oluşur; bunlardan herhangi birinin eksik olduğu bir yedekleme, kimsenin kullanamayacağı bir sunucuyu geri yükler.

• Her etkinliği, hesabı ve odayı barındıran Postgres veritabanı.
• Yüklenen her dosyayı barındıran media store dizini.
• Yapılandırmanızı ve sunucunun imzalama anahtarını tutan /etc/matrix-synapse.

İmzalama anahtarı, insanların unuttuğu kısımdır. Bu, homeserver'ınızın etkinlikleri imzaladığı özel anahtardır ve uzak sunucular, etkinlikleri eşleşen genel anahtara göre doğrular. Sizinkinin nerede olduğunu görmek için grep signing_key_path /etc/matrix-synapse/homeserver.yaml komutunu çalıştırın. Bu anahtarı kaybederseniz, odalarınızın zaten tanıdığı sunucuyla aynı olduğunu kanıtlayamayan bir sunucuyu geri yüklemiş olursunuz.

sudo -u postgres pg_dump --format=custom --file=/var/backups/synapse-$(date +%F).dump synapse
sudo tar czf /var/backups/synapse-etc-$(date +%F).tgz -C /etc matrix-synapse

Önce veritabanını dump edin, ardından media store dizinini kopyalayın. Medya dosyaları bir kez yazılır ve ID ile referans verilir; bu nedenle dump işleminden sonra alınan bir medya kopyası yalnızca fazladan dosyalar içerebilir, asla eksik dosya içermez. Diğer sıralama, geri yüklenen veritabanının yedeklemenizin asla yakalamadığı bir dosyayı işaret etmesine neden olabilir.

Üç parçayı da VPS dışına gönderin. off-site snapshot'lar ile restic, bu yapıya iyi uyum sağlar; çünkü media store büyük olan yarıdır ve çalıştırmalar arasında neredeyse hiç değişmez, bu nedenle tekilleştirme (deduplication) her snapshot'ı küçük tutar.

Ardından geri yükleme provası yapın, çünkü daha önce hiç geri yüklemediğiniz bir yedekleme sadece bir varsayımdır. İkinci bir VPS kurun, aynı paketi yükleyin, yapılandırmayı geri yükleyin, veritabanını aynı kodlama ve yerel ayar (locale) ile oluşturun, dump dosyasını pg_restore ile içine aktarın, media store dizinini geri kopyalayın ve giriş yapın. Ne kadar sürdüğünü not edin. Bu sayı, gerçek kurtarma sürenizdir.

Durum tabloları büyüdüğünde: sıkıştırma

Synapse, oda durumunu durum grupları olarak saklar ve federasyon yapan bir sunucuda state_groups_state genellikle veritabanındaki en büyük nesne haline gelir. Herhangi bir değişiklik yapmadan önce ölçüm yapın:

sudo -u postgres psql synapse -c "SELECT pg_size_pretty(pg_database_size('synapse'));"
sudo -u postgres psql synapse -c "SELECT pg_size_pretty(pg_total_relation_size('state_groups_state'));"

Eğer bu tablo veritabanınızın büyük bir kısmını oluşturuyorsa, proje bunun için rust-synapse-compress-state adında bir sıkıştırıcı yayınlamıştır. Bu araç, herhangi bir odanın durumunun anlamını değiştirmeden durum grubu hiyerarşisini daha az satıra dönüştürür. Rust ile yazılmıştır:

sudo apt install -y build-essential libssl-dev pkg-config git
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
git clone https://github.com/matrix-org/rust-synapse-compress-state.git
cd rust-synapse-compress-state/synapse_auto_compressor
cargo build --release

./target/release/synapse_auto_compressor -p postgresql://synapse_user:secretpassword@localhost/synapse -c 500 -n 100

-c, aracın aynı anda üzerinde çalıştığı durum grubu sayısını, -n ise bu çalıştırma sırasında işlenecek parça sayısını ifade eder. Otomatik sıkıştırıcı ne kadar ilerlediğini kaydeder, böylece bir sonraki çalıştırma kaldığı yerden devam eder; bu da aracın zamanlanmasını güvenli kılar. Belgelerinde, değişikliklerin yalnızca ekleme yapılabilen (append-only) tablolara karşı işlemler (transactions) halinde uygulandığı belirtilir, bu nedenle Synapse çalışırken de kullanılabilir. Yine de ilk çalıştırmadan önce mutlaka bir veritabanı yedeği alın.

Postgres ile ilgili bir detay burada insanları şaşırtır. Satırları silmek, alanı dosya sistemine değil, Postgres'in yeniden kullanması için veritabanına geri kazandırır; bu nedenle büyük bir sıkıştırma işleminden sonra df dosya boyutu hiç değişmeyebilir. VACUUM FULL bu alanı geri kazandırır; ancak bu işlem tablo üzerinde özel (exclusive) bir kilit tutar ve tablonun boyutu kadar boş disk alanı gerektirir. Bu yüzden bu işlemi anlık bir ihtiyaç olarak değil, bir bakım çalışması olarak planlayın.

Sunucunun sağlıklı olduğunu gösteren kontroller

systemctl status matrix-synapse
curl -s https://example.com/.well-known/matrix/server
curl -s https://matrix.example.com/_matrix/federation/v1/version
sudo -u postgres psql synapse -c "SELECT pg_size_pretty(pg_database_size('synapse'));"
sudo du -sh /var/lib/matrix-synapse/media_store

Sağlıklı durumu, birimin aktif olduğunu ve yeniden başlatılmadığını, delegasyon dosyasının m.server değerinizi döndürdüğünü, federasyon sürüm uç noktasının JSON çıktısı verdiğini ve iki boyut değerinin geçen ayın verileriyle karşılaştırılabilir olduğunu ifade eder. Boyut kontrolleri, kullanıcıların genellikle atladığı kısımdır; disk doluluğu ise Synapse sunucusunu hiçbir uyarı vermeden devre dışı bırakan bir hata türüdür: dolu bir disk bölümü Postgres yazma işlemlerini durdurur ve Synapse, veritabanına erişen her isteği reddetmeye başlar.

FAQ

Matrix Synapse sunucusu ne kadar RAM gerektirir?

Az sayıda kullanıcısı, küçük odaları olan ve büyük genel odalara dahil olmayan özel bir homeserver için 2 GB RAM yeterlidir; Ağustos 2026 itibarıyla yayınlanan çoğu boyutlandırma kılavuzu da bunu önermektedir. Eğer kullanıcılarınız #matrix:matrix.org gibi büyük genel odalara katılacaksa, Synapse dokümantasyonu diğer ihtiyaçların üzerine en az 1 GB boş RAM ayrılmasını tavsiye eder; çünkü sunucunuz bu durumda odanın durum bilgisini saklar ve trafiğini sürekli işler. 2 GB RAM içeren bir planda swap alanı ekleyin; böylece tek bir büyük odaya katılım, sürecin kernel tarafından sonlandırılmasına (OOM kill) yol açmaz.

SQLite yerine PostgreSQL kullanmak zorunda mıyım?

Birkaç kullanıcıdan fazlası için evet. SQLite aynı anda yalnızca bir yazma işlemine izin verir; bu nedenle federasyon trafiği ve istemci istekleri yük altında birbirini engeller ve istekler saniyelerce yanıt bekler. Birden fazla CPU çekirdeği kullanmanın desteklenen yolu olan Synapse worker süreçleri, Postgres gerektirir. Daha sonra geçiş yapmak synapse_port_db ile mümkündür ancak kesinti süresi gerektirir; bu nedenle veritabanını kullanıcılarınız henüz yokken --encoding=UTF8 --locale=C --template=template0 ile oluşturun.

Synapse disk kullanımım neden sürekli artıyor?

Bunun sebebi bir dizin ve bir tablodur. Media store, sunucunuzun dahil olduğu odalara yüklenen her dosyayı (uzak kullanıcıların medyalarının önbellek kopyaları ve oluşturulan küçük resimler dahil) saklar ve siz media_retention ayarını yapana kadar hiçbir şeyin süresi dolmaz. state_groups_state tablosu, federasyon yapan bir sunucuda oda durumuyla birlikte büyür ve rust-synapse-compress-state bu boyutu küçültür. Hangisi üzerinde çalışacağınıza karar vermeden önce, media_store_path üzerinde du -sh ile ve SELECT pg_size_pretty(pg_total_relation_size('state_groups_state')); ile her ikisini de ölçün.

Yabancıların homeserver'ıma kayıt olmasını nasıl engellerim?

enable_registration ayarını varsayılan değeri olan false olarak bırakın ve hesapları register_new_matrix_user ile oluşturun. Bu yöntem ölçeklenemez hale geldiğinde, enable_registration: true ayarını registration_requires_token: true ile birlikte yapılandırın ve POST /_synapse/admin/v1/registration_tokens/new aracılığıyla oluşturulan token'ları dağıtın. Synapse'in başlangıçtaki uyarılarını susturmak için enable_registration_without_verification: true ayarını asla etkinleştirmeyin; çünkü açık bir homeserver spam kaynağı haline gelir ve diğer yöneticiler alan adınızın tamamını engelleyerek yanıt verir.

Homeserver'ım federasyon yapmalı mı?

Federasyon bir varsayılan değil, bir maruziyet kararıdır. Kullanıcılarınızın diğer homeserver'lardaki kişilere ulaşması gerekiyorsa federasyonu etkinleştirin. Eğer sunucu tek bir ekibe hizmet veriyorsa federasyonu kapalı tutun; çünkü federasyon yapmayan bir sunucu daha az veri saklar, daha az trafik alır ve çok daha az kötüye kullanıma maruz kalır. İki durum arasında bir tercih yapmak isterseniz, federation_domain_whitelist federasyonu yalnızca belirtilen iş ortağı alan adlarıyla sınırlar. Synapse dokümantasyonu, yalnızca uygulama katmanındaki kontrollere güvenmek yerine federasyon dinleyicisini bir güvenlik duvarı ile kısıtlamanızı da önerir.