VPS پر Matrix Synapse homeserver چلانے کا طریقہ

Matrix Synapse homeserver کو فعال رکھنے کے لیے کیا درکار ہے

Matrix Synapse انسٹال کرنا آسان ہے، لیکن اسے نظرانداز کرنا بھی آسان ہے۔ انسٹالیشن کے لیے ایک apt repository، ایک config file، ایک reverse proxy block اور ایک DNS record درکار ہوتا ہے۔ homeserver کو ایک سال تک صحت مند رکھنا مختلف نوعیت کا کام ہے: حقیقی database، ایسا media store جس کی غیر ضروری فائلیں باقاعدگی سے صاف کی جائیں، ایسی registration جسے اجنبی افراد استعمال نہ کر سکیں، اور ایسا backup جو server کے دونوں اہم حصوں کو محفوظ کرے۔

یہ guide Ubuntu 24.04 LTS کو ہدف بناتی ہے اور Synapse کو matrix.org apt repository سے انسٹال کرتی ہے۔ یہی package source Synapse project Debian اور Ubuntu کے لیے برقرار رکھتا ہے۔ Package versions ہر چند ہفتوں بعد تبدیل ہوتے ہیں، اس لیے یہاں کوئی version number نہیں دیا گیا۔ ذیل میں موجود ہر path اور option موجودہ Synapse documentation سے لیا گیا ہے۔

Sizing: 1 vCPU اور 2 GB RAM سے حقیقتاً کیا حاصل ہوتا ہے

August 2026 تک شائع شدہ sizing صفحات عموماً Synapse homeserver کے لیے 1 vCPU اور 2 GB RAM تجویز کرتے ہیں۔ یہ ایک صورت میں درست ہے: private server، چند users، چھوٹے rooms، اور کوئی مصروف public room نہ ہو۔ دوسری صورت کے بارے میں Synapse documentation واضح ہے۔ اس میں کہا گیا ہے: "اگر آپ #matrix:matrix.org جیسے بڑے public rooms میں شامل ہونا چاہتے ہیں تو کم از کم 1GB free RAM درکار ہے۔" یہ free RAM Python، Postgres اور kernel کی ضروریات کے علاوہ ہے۔

ایک room آپ کی sizing بدل سکتا ہے، کیونکہ joining اسی طرح کام کرتی ہے۔ جب کوئی local user کسی room میں شامل ہوتا ہے تو آپ کا homeserver اس room کا مکمل participant بن جاتا ہے۔ اسے room میں موجود ہر دوسرے server سے آنے والا ہر event موصول ہوتا ہے، یہ ہر event کے signature کی تصدیق کرتا ہے، اور room کی state مقامی طور پر محفوظ کرتا ہے۔ ایک بڑے public room میں ہزاروں members سیکڑوں servers پر پھیلے ہوتے ہیں، اس لیے آپ کا server یہ کام مسلسل کرتا رہتا ہے، چاہے user دوبارہ کبھی room نہ کھولے۔ بعد میں room چھوڑنے سے پہلے سے محفوظ کی گئی history حذف نہیں ہوتی۔

Synapse کی زیادہ تر RAM caches کے لیے استعمال ہوتی ہے۔ caches section میں ایک global_factor موجود ہے جو تمام caches کو بیک وقت scale کرتا ہے، اور SYNAPSE_CACHE_FACTOR environment variable بھی یہی قدر set کرتا ہے۔ اسے بڑھانے سے database queries کم کرنے کے لیے RAM زیادہ استعمال ہوتی ہے۔ اسے کم کرنے سے RAM بچتی ہے، لیکن CPU اور Postgres کا وقت زیادہ خرچ ہوتا ہے۔ Postgres کو اپنی memory بھی درکار ہوتی ہے، اس لیے 2 GB server پر دونوں ایک ہی memory کے لیے مقابلہ کرتے ہیں۔

چھوٹے plan کے لیے دو عملی اصول ہیں۔ swap شامل کریں: swap Synapse کو تیز نہیں کرے گی، لیکن بڑے join کے دوران kernel کو process ختم کرنے سے روک سکتی ہے۔ پھر پہلے ہفتے ہی سے disk monitor کریں، کیونکہ بغیر حد کے بڑھنے والی دو چیزیں media store اور room state tables ہیں، اور دونوں disk پر موجود ہوتی ہیں۔

Postgres کیوں، اور SQLite کب قابلِ عمل اختیار نہیں رہتا

Debian package ابتدا میں SQLite پر شروع ہوتا ہے۔ پہلی boot کے لیے یہ مناسب ہے، لیکن ایسے server کے لیے درست نہیں جسے دوسرے لوگ استعمال کریں۔ SQLite ایک وقت میں صرف ایک writer کی اجازت دیتا ہے۔ Federation traffic اور client requests بیک وقت write کرتے ہیں، اس لیے ایک معمولی request سست request کے پیچھے انتظار کرتی ہے۔ صارفین کو اس کا اثر یہ محسوس ہوتا ہے کہ app بے ترتیب طور پر چند seconds کے لیے hang ہو جاتی ہے۔

دوسری وجہ ساخت سے متعلق ہے۔ ایک سے زیادہ CPU cores استعمال کرنے کے لیے Synapse کے worker processes معاون اور منظور شدہ طریقہ ہیں، اور workers کے لیے Postgres درکار ہے۔ SQLite پر برقرار رہنے سے performance کے ساتھ upgrade path بھی ختم ہو جاتا ہے۔

بعد میں migration معاون ہے، لیکن اس کے لیے downtime درکار ہوتا ہے۔ اس لیے users آنے سے پہلے یہ کام کر لیں۔ Synapse synapse_port_db فراہم کرتا ہے، جو SQLite database کو تیار شدہ Postgres database میں copy کرتا ہے:

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

اگر آپ database کو Synapse کے ساتھ والے container میں چلانا چاہتے ہیں تو اس کے فوائد اور نقصانات database کو Docker میں یا host پر چلانا میں بیان کیے گئے ہیں۔

Ubuntu 24.04 پر Synapse انسٹال کریں

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 پر lsb_release -cs، noble دکھاتا ہے، اور matrix.org repository ایک noble suite فراہم کرتی ہے۔ Ubuntu کے اپنے archive کا matrix-synapse package استعمال نہ کریں۔ Synapse project بھی ایسا نہ کرنے کی ہدایت دیتا ہے، کیونکہ ان builds میں اس کی releases کے مقابلے میں تاخیر ہوتی ہے اور ان میں معلوم security bugs موجود ہوتے ہیں۔

Installer server name پوچھتا ہے اور جواب /etc/matrix-synapse/conf.d/server_name.yaml میں لکھتا ہے۔ اس کا جواب احتیاط سے دیں۔ server_name ہر user ID (@alice:example.com) میں colon کے بعد والا حصہ ہے، اور آپ کا server جو بھی room بناتا ہے، اس میں یہی حصہ شامل ہوتا ہے۔ بعد میں اسے تبدیل کرنے سے کوئی چیز منتقل نہیں ہوتی؛ اس کے نتیجے میں مختلف homeserver بنتا ہے۔ اپنا bare domain، example.com، استعمال کریں، چاہے Synapse خود matrix.example.com پر چلے۔ Delegation دونوں کو مربوط کرتی ہے، اور یہی اگلا section ہے۔

Package Synapse کو matrix-synapse user کے طور پر چلاتا ہے، اس کا data /var/lib/matrix-synapse کے تحت رکھتا ہے، اور /etc/matrix-synapse/homeserver.yaml کے بعد /etc/matrix-synapse/conf.d/ میں موجود ہر file پڑھتا ہے۔ اپنی settings conf.d میں چھوٹی files میں رکھیں۔ Package upgrades انہیں تبدیل نہیں کرتیں۔

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

درست startup میں listeners فعال ہوتے ہیں اور پھر service خاموشی سے چلتی رہتی ہے۔ systemd unit کسی بھی exit کے چند seconds بعد service کو restart کرتی ہے، اس لیے اگر Synapse کسی config کو reject کرے تو unit کے start ہونے اور loop میں بند ہونے کی صورت نظر آتی ہے۔ Journal کی آخری lines اس key کا نام بتاتی ہیں جسے اس نے reject کیا ہے۔

Postgres کی طرف Synapse کی سمت مقرر کریں

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

locale محض ظاہری معاملہ نہیں ہے۔ Synapse اس database کے ساتھ start ہونے سے انکار کرتا ہے جو مختلف COLLATE اور CTYPE values کے ساتھ بنایا گیا ہو، جب تک آپ database config میں allow_unsafe_locale set نہ کریں۔ اس کے بعد documented repair کا طریقہ dump لے کر اسے درست طور پر بنائے گئے database میں reload کرنا ہے۔ اسے پہلی بار ہی درست بنائیں۔

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

اپنی تمام config files میں بالکل ایک database: key رکھیں۔ homeserver.yaml کے اندر موجود SQLite block کو تبدیل کریں، conf.d کے تحت دوسری copy شامل نہ کریں، تاکہ یہ ابہام نہ رہے کہ کون سی configuration فعال ہے۔ Restart کریں، پھر تصدیق کریں کہ Synapse واقعی Postgres استعمال کر رہا ہے:

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

ایک number کا مطلب ہے کہ Synapse نے اسی database میں اپنا schema بنایا ہے۔ missing relation سے متعلق error کا مطلب ہے کہ یہ اب بھی SQLite file میں لکھ رہا ہے، اس لیے آپ کی edit کی ہوئی config وہ config نہیں ہے جسے پڑھا جا رہا ہے۔

ریورس پراکسی، TLS اور federation کے لیے درکار .well-known فائلیں

Synapse plain HTTP پر port 8008 استعمال کرتا ہے اور localhost سے bind ہوتا ہے۔ TLS اور public port اس کے سامنے موجود reverse proxy کی ذمہ داری ہیں۔

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 کو بتاتا ہے کہ proxy کی جانب سے set کیے گئے X-Forwarded-For header پر اعتماد کیا جائے۔ اس کے بغیر ہر client ایسا دکھائی دیتا ہے جیسے وہ 127.0.0.1 سے آیا ہو۔ اس لیے rate limiting کو ایک ہی انتہائی مصروف local user نظر آتا ہے اور سب clients کو ایک ساتھ throttle کر دیا جاتا ہے۔

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 documentation اس block کے بارے میں ایک ایسی تنبیہ دیتی ہے جسے نظرانداز کرنے سے لوگوں کے کئی دن ضائع ہو جاتے ہیں۔ port کے بعد کوئی path شامل نہ کریں، حتیٰ کہ ایک بھی / نہیں، proxy_pass میں بھی نہیں۔ اس کے بعد nginx URI کو canonicalise کرتا ہے۔ اس سے sending server کے دستخط شدہ bytes تبدیل ہو جاتے ہیں۔ نتیجتاً federation requests کی signature verification ناکام ہو جاتی ہے، جبکہ عام client requests کام کرتی رہتی ہیں۔

client_max_body_size کی قدر Synapse کے max_upload_size کے برابر یا اس سے زیادہ ہونی چاہیے۔ اگر nginx میں کم قدر مقرر ہو تو اس حد سے بڑی uploads کو Synapse تک پہنچنے سے پہلے nginx 413 Request Entity Too Large کے ساتھ reject کر دیتا ہے۔ اس لیے failure کی وضاحت کرنے والی Synapse log line موجود نہیں ہوتی۔

Certificate کے لیے Ubuntu 24.04 پر Certbot اور Let's Encrypt کی ہدایات پر عمل کریں۔ اگر proxy کا انتخاب ابھی نہیں کیا گیا تو reverse proxy کا موازنہ بتاتا ہے کہ TLS کا کام کون سا proxy آپ کے لیے انجام دے گا۔

Delegation کی وجہ سے server_name کو example.com پر برقرار رکھا جا سکتا ہے، جبکہ Synapse matrix.example.com پر چلتا ہے۔ bare domain سے دو فائلیں serve کریں:

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

server فائل دوسرے homeservers کو بتاتی ہے کہ federation traffic کہاں بھیجا جائے۔ اسی طرح federation default port 8448 کے بجائے 443 پر چلتی ہے۔ client فائل Matrix clients کو بتاتی ہے کہ @alice:example.com کے پیچھے کون سا URL ہے۔ client فائل میں Access-Control-Allow-Origin header اہم ہے، کیونکہ browser-based clients اسے cross-origin fetch کرتے ہیں۔ اس header کے بغیر browser response کو block کر دیتا ہے اور client بتاتا ہے کہ اسے آپ کا homeserver نہیں مل سکا۔

دونوں فائلیں example.com سے valid TLS کے ذریعے serve ہونی چاہییں۔ پہلے ان کی جانچ کریں، پھر دیکھیں کہ بیرونی دنیا کو کیا response ملتا ہے:

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

پہلی command وہ JSON واپس کرتی ہے جو آپ نے لکھا ہے۔ دوسری command ایک JSON object واپس کرتی ہے جس میں server implementation اور اس کا version درج ہوتا ہے۔ اس سے ثابت ہوتا ہے کہ proxy federation path پر Synapse تک پہنچ رہا ہے۔ اس کے بعد domain کو Matrix federation tester پر https://federationtester.matrix.org چلا کر جانچیں۔ یہ وہی route follow کرتا ہے جو کوئی حقیقی remote server استعمال کرتا ہے۔

فدریشن کریں یا نہ کریں: فیصلہ سوچ سمجھ کر کریں

فدریشن Matrix کا بنیادی مقصد ہے، اور یہی اس کی زیادہ تر لاگت کا سبب بھی ہے۔ فدریشن کرنے والا homeserver ایسے servers سے connections قبول کرتا ہے جن کے بارے میں آپ نے کبھی نہیں سنا، ان کے events وصول کرتا ہے، ان کا media cache کرتا ہے، اور ہر اس room کی state محفوظ کرتا ہے جس سے آپ کے users تعامل کرتے ہیں۔ یہ threat model سے متعلق فیصلہ ہے، default configuration نہیں۔

جب آپ کے users کو دوسرے homeservers پر موجود لوگوں تک رسائی درکار ہو، یا portable identity وہ وجہ ہو جس کی بنا پر آپ نے Matrix منتخب کیا ہو، تو فدریشن فعال کریں۔ جب server صرف ایک team کے لیے ہو اور اس کے تمام accounts آپ کی ملکیت ہوں، تو فدریشن فعال نہ کریں۔ بند server کم data محفوظ کرتا ہے، کم data وصول کرتا ہے، اور abuse کے لیے بہت کم پرکشش ہوتا ہے۔

فدریشن کو مکمل طور پر بند کرنے کے بجائے محدود کرنے کے لیے Synapse allow list استعمال کرتا ہے:

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

دستاویزات federation listener پر firewall لگانے کی بھی تجویز دیتی ہیں، تاکہ ناپسندیدہ traffic Python کے اندر پہنچنے کے بجائے network سطح پر رک جائے۔ فدریشن مکمل طور پر بند کرنے کے لیے listener کی resources list سے federation ہٹا دیں، /.well-known/matrix/server publish نہ کریں، اور port 8448 بند رکھیں۔

اگر Matrix چلانے کی وجہ private team chat تھی اور فدریشن کبھی اس کا حصہ نہیں تھی، تو Synapse منتخب کرنے سے پہلے اس کی running cost کا دیگر self-hosted Slack متبادلات سے موازنہ کریں۔ Docker Compose پر Rocket.Chat کم صلاحیت والی machine پر team chat فراہم کرتا ہے، کیونکہ اسے کبھی کسی دوسری organisation کی room state محفوظ نہیں کرنی پڑتی۔

میڈیا repository خاموشی سے disk بھر دیتا ہے

آپ کے اپنے users کی upload کردہ files مستقل طور پر disk پر رہتی ہیں۔ دوسرے homeservers کے users کی پوسٹ کردہ files جیسے ہی آپ کا کوئی client انہیں دکھاتا ہے، آپ کی disk پر fetch اور cache ہو جاتی ہیں۔ Synapse images کے thumbnails بھی بناتا ہے، اس لیے ایک photo کئی files میں تبدیل ہو جاتی ہے۔ بطور default ان میں سے کوئی بھی چیز expire نہیں ہوتی۔

Store تلاش کریں اور اس کا حجم معلوم کریں:

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

اپنی config میں ظاہر ہونے والے path کا حجم معلوم کریں۔ Debian package، Synapse کا data /var/lib/matrix-synapse کے تحت رکھتا ہے، اس لیے store عموماً وہیں ہوتا ہے۔ اس کے بعد conf.d میں retention policy مقرر کریں:

media_retention:
  local_media_lifetime: 90d
  remote_media_lifetime: 14d

ان دونوں lines کو غور سے پڑھیں، کیونکہ یہ ایک ہی قسم کی settings نہیں ہیں۔ remote_media_lifetime ایک cache کو expire کرتا ہے، اور جو data یہ delete کرتا ہے اسے اس server سے دوبارہ fetch کیا جا سکتا ہے جو اس file کا مالک ہے۔ local_media_lifetime آپ کے اپنے users کی uploads کو مقررہ عمر پوری ہونے کے بعد مستقل طور پر delete کرتا ہے۔ جو team chat میں documents شیئر کرتی ہے اور اگلے سال انہیں دوبارہ تلاش کرنے کی توقع رکھتی ہے، وہ یہ files کھو دے گی۔ بہت سے servers صرف remote value مقرر کرتے ہیں۔

ایک بار کی cleanup کے لیے admin API، milliseconds میں Unix timestamp قبول کرتی ہے:

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 اس timestamp سے پہلے آخری بار access کیے گئے cached remote media کو delete کرتا ہے۔ POST /_synapse/admin/v1/media/delete?before_ts=<ms> اسی rule کے مطابق local media کو delete کرتا ہے۔ پہلے remote purge چلائیں اور دوبارہ حجم معلوم کریں، کیونکہ federating server پر remote cache عموماً زیادہ بڑا حصہ ہوتا ہے۔

دو settings اسی disk پر اثر ڈالتی ہیں۔ max_upload_size ایک single upload کی حد مقرر کرتا ہے اور اسے nginx میں client_max_body_size کے مطابق رکھنا ضروری ہے۔ url_preview_enabled: true آپ کے server کو remote pages fetch کرنے دیتا ہے تاکہ clients link previews دکھا سکیں۔ اس سے bandwidth خرچ ہوتی ہے اور ایسے content کے thumbnails disk پر محفوظ ہوتے ہیں جسے آپ کے کسی user نے upload نہیں کیا۔

کسی کے آپ کا homeserver تلاش کرنے سے پہلے registration بند کریں

Scanners چند دنوں میں کھلے homeserver تلاش کر لیتے ہیں۔ جیسے ہی اکاؤنٹس بنانا سب کے لیے ممکن ہو، آپ کا server ہر اس room میں spam کا ذریعہ بن جاتا ہے جس کے ساتھ وہ federate کرتا ہے، اور دوسری جانب کے administrators آپ کے پورے domain کو block کر دیتے ہیں۔ اس reputation کو پہنچنے والا نقصان صفائی مکمل ہونے کے بعد بھی برقرار رہتا ہے، کیونکہ block lists دستی طور پر maintain کی جاتی ہیں۔

Synapse بطور default بند حالت میں آتا ہے۔ enable_registration کی default قدر false ہے اور registration_requires_token کی default قدر false ہے۔ اگر registration enabled ہو اور کوئی verification step موجود نہ ہو تو Synapse شروع ہونے سے بھی انکار کرتا ہے، جب تک آپ اضافی طور پر enable_registration_without_verification: true set نہ کریں۔ یہ انکار جان بوجھ کر ہے، اس لیے startup error ختم کرنے کے لیے اسے enabled نہ کریں۔

اپنے مطلوبہ اکاؤنٹس دستی طور پر بنائیں:

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

یہ user name، password، اور اس بات کے بارے میں پوچھتا ہے کہ آیا اکاؤنٹ server admin ہے۔ یہ آپ کے -c کے ذریعے دی گئی config سے registration_shared_secret پڑھتا ہے، اس لیے اگر یہ بتائے کہ shared secret نہیں مل رہا تو -c کو اس file کی طرف point کریں جس میں یہ موجود ہے۔

جب اکاؤنٹس دستی طور پر بنانا قابلِ توسیع نہ رہے تو registration tokens درمیانی حل ہیں۔ Token ایک string ہے جو نیا user signup کے دوران پیش کرتا ہے، اور ہر token کے ساتھ اس کے استعمال کی زیادہ سے زیادہ تعداد مقرر کی جا سکتی ہے:

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 کو body سے خارج رکھیں، تو Synapse خود ایک token generate کر کے واپس کر دے گا۔ GET /_synapse/admin/v1/registration_tokens فعال tokens کی فہرست دکھاتا ہے۔ دونوں calls کے لیے server admin اکاؤنٹ کا access token درکار ہے۔ یہ access token اسی admin user سے login کر کے حاصل کریں جسے آپ نے اوپر بنایا تھا۔

جو organisation پہلے ہی اکاؤنٹس کہیں اور manage کرتی ہو، وہ local passwords مکمل طور پر چھوڑ سکتی ہے، کیونکہ Synapse login کو کسی OIDC (OpenID Connect) provider کے سپرد کر سکتا ہے، مثلاً self-hosted SSO provider کے طور پر Authentik۔ اس کے بعد نئے شامل ہونے والے اور organisation چھوڑنے والے users ایک ہی جگہ manage ہوتے ہیں۔

ایسا backup جو واقعی server دوبارہ تیار کر سکے

Synapse backup کے تین حصے ہوتے ہیں، اور ان میں سے کوئی ایک حصہ موجود نہ ہو تو backup ایسے server کو restore کرتا ہے جسے کوئی استعمال نہیں کر سکتا۔

• Postgres database، جس میں ہر event، account اور room محفوظ ہوتا ہے۔
• media store directory، جس میں ہر uploaded file محفوظ ہوتی ہے۔
• /etc/matrix-synapse، جس میں آپ کی config اور server کی signing key محفوظ ہوتی ہے۔

signing key وہ حصہ ہے جسے لوگ اکثر بھول جاتے ہیں۔ یہ وہ private key ہے جس سے آپ کا homeserver events پر دستخط کرتا ہے، اور remote servers matching public key کے ذریعے events کی تصدیق کرتے ہیں۔ اپنی signing key کا مقام دیکھنے کے لیے grep signing_key_path /etc/matrix-synapse/homeserver.yaml چلائیں۔ اگر یہ key ضائع ہو جائے تو آپ ایسا server restore کریں گے جو یہ ثابت نہیں کر سکتا کہ وہ وہی server ہے جسے آپ کے rooms پہلے سے جانتے ہیں۔

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

پہلے database dump کریں، پھر media store copy کریں۔ Media files ایک بار لکھی جاتی ہیں اور ID کے ذریعے refer کی جاتی ہیں، اس لیے dump کے بعد لی گئی media copy میں صرف اضافی files شامل ہو سکتی ہیں، missing files نہیں۔ اس کے برعکس ترتیب میں restored database کسی ایسی file کی طرف اشارہ کر سکتا ہے جسے آپ کے backup نے محفوظ ہی نہیں کیا۔

تینوں حصے VPS سے باہر محفوظ کریں۔ off-site snapshots کے ساتھ restic اس مقصد کے لیے موزوں ہے، کیونکہ media store بڑا حصہ ہے اور runs کے درمیان اس میں بہت کم تبدیلی آتی ہے؛ deduplication کی وجہ سے ہر snapshot چھوٹا رہتا ہے۔

اس کے بعد restore کی مشق کریں، کیونکہ ایسا backup جسے آپ نے کبھی restore نہ کیا ہو، صرف ایک مفروضہ ہے۔ دوسرا VPS بنائیں، وہی package install کریں، config restore کریں، اسی encoding اور locale کے ساتھ database بنائیں، dump کو اس میں pg_restore کریں، media store واپس copy کریں، اور login کریں۔ اس عمل میں لگنے والا وقت لکھ لیں۔ یہی آپ کا حقیقی recovery time ہے۔

جب state tables بڑھ جائیں: compaction

Synapse room state کو state groups کے طور پر محفوظ کرتا ہے، اور federating server پر state_groups_state اکثر database میں سب سے بڑا object بن جاتا ہے۔ کوئی تبدیلی کرنے سے پہلے اس کی پیمائش کریں:

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'));"

اگر یہی table database کا زیادہ تر حصہ ہو تو project اس کے لیے ایک compressor فراہم کرتا ہے، rust-synapse-compress-state، جو state group hierarchy کو کم rows میں دوبارہ لکھتا ہے، جبکہ کسی بھی room کے state کا مفہوم تبدیل نہیں ہوتا۔ یہ Rust سے بنایا گیا ہے:

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 اس بات کا تعین کرتا ہے کہ یہ ایک وقت میں کتنے state groups پر کام کرے گا، اور -n اس بات کا کہ یہ run ان chunks میں سے کتنے process کرے گا۔ خودکار compressor اپنی پیش رفت محفوظ کرتا ہے، اس لیے اگلا run وہیں سے جاری رہتا ہے۔ اسی وجہ سے اسے schedule کرنا محفوظ ہے۔ اس کی documentation کے مطابق تبدیلیاں append-only tables کے خلاف transactions میں لاگو ہوتی ہیں، لہٰذا یہ Synapse کے چلتے ہوئے بھی run ہو سکتا ہے۔ اس کے باوجود پہلی بار run کرنے سے پہلے database backup ضرور لیں۔

یہاں Postgres کی ایک تفصیل اکثر لوگوں کو حیران کرتی ہے۔ Rows حذف کرنے سے space file system کو واپس نہیں ملتی؛ Postgres اسے دوبارہ استعمال کے لیے محفوظ رکھتا ہے۔ اس لیے بڑی compaction کے بعد df میں شاید کوئی کمی نہ آئے۔ VACUUM FULL یہ space واپس file system کو فراہم کرتا ہے، لیکن اس کے لیے table پر exclusive lock اور table کے size کے تقریباً برابر free disk درکار ہوتی ہے۔ اس لیے اسے maintenance کے دوران schedule کریں، اچانک نہ چلائیں۔

وہ جانچیں جو بتاتی ہیں کہ سرور صحت مند ہے

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

صحت مند ہونے کا مطلب ہے کہ unit فعال ہو اور بار بار restart نہ ہو، delegation file آپ کی m.server value واپس کرے، federation version endpoint JSON واپس کرے، اور دونوں size numbers کا پچھلے ماہ کے numbers سے موازنہ کیا جا سکے۔ size checks وہ جانچ ہیں جنہیں لوگ اکثر چھوڑ دیتے ہیں۔ disk بھر جانا وہ خرابی ہے جو Synapse server کو بغیر کسی warning کے بند کر دیتی ہے: مکمل volume، Postgres کو لکھنے سے روک دیتا ہے، اور اس کے بعد Synapse ہر اس request پر fail ہو جاتا ہے جو database تک رسائی حاصل کرتی ہے۔

FAQ

Matrix Synapse سرور کو کتنی RAM درکار ہوتی ہے؟

نجی homeserver کے لیے، جس میں چند صارفین، چھوٹے rooms اور کوئی بڑے public rooms نہ ہوں، 2 GB قابلِ استعمال ہے۔ August 2026 تک شائع شدہ sizing صفحات میں بھی عموماً یہی تجویز کیا گیا ہے۔ Synapse documentation کے مطابق، اگر آپ کے صارفین #matrix:matrix.org جیسے بڑے public rooms میں شامل ہوں تو باقی ضروریات کے علاوہ کم از کم 1 GB free RAM درکار ہے، کیونکہ اس صورت میں آپ کا server اس room کی state ذخیرہ کرتا ہے اور اس کا traffic مسلسل process کرتا ہے۔ 2 GB plan پر swap شامل کریں تاکہ ایک بڑے join کی وجہ سے kernel process کو ختم نہ کر دے۔

کیا مجھے SQLite کے بجائے PostgreSQL استعمال کرنا ہوگا؟

چند صارفین سے زیادہ ہونے پر، ہاں۔ SQLite میں ایک وقت میں صرف ایک writer کام کر سکتا ہے، اس لیے load کے دوران federation traffic اور client requests ایک دوسرے کو block کرتے ہیں اور requests کئی seconds تک معطل رہتی ہیں۔ Synapse کے worker processes، جو ایک سے زیادہ CPU cores استعمال کرنے کا supported طریقہ ہیں، Postgres کے تقاضے کے ساتھ کام کرتے ہیں۔ بعد میں migration synapse_port_db کے ذریعے ہو سکتی ہے اور downtime درکار ہوتا ہے، اس لیے صارفین آنے سے پہلے database کو --encoding=UTF8 --locale=C --template=template0 کے ساتھ بنائیں۔

میرے Synapse کے disk usage میں مسلسل اضافہ کیوں ہو رہا ہے؟

ایک directory اور ایک table اس کی بنیادی وجوہات ہیں۔ media store ان rooms میں upload کی گئی ہر file محفوظ رکھتا ہے جن میں آپ کا server شامل ہے۔ اس میں remote users کے media کی cached copies اور generated thumbnails بھی شامل ہیں، اور جب تک آپ media_retention مقرر نہ کریں، کچھ بھی expire نہیں ہوتا۔ federating server پر state_groups_state table room state کے ساتھ بڑھتی ہے، جبکہ rust-synapse-compress-state اسے کم کرتی ہے۔ فیصلہ کرنے سے پہلے دونوں کی پیمائش کریں: اپنے media_store_path پر du -sh کے ذریعے، اور SELECT pg_size_pretty(pg_total_relation_size('state_groups_state')); کے ذریعے۔

میں اجنبی لوگوں کو اپنے homeserver پر registration سے کیسے روکوں؟

enable_registration کو اس کی default قدر false پر رہنے دیں اور accounts register_new_matrix_user کے ذریعے بنائیں۔ جب یہ طریقہ قابلِ توسیع نہ رہے تو enable_registration: true کو registration_requires_token: true کے ساتھ set کریں، اور POST /_synapse/admin/v1/registration_tokens/new کے ذریعے بنائے گئے tokens جاری کریں۔ Synapse کے startup refusal کو خاموش کرنے کے لیے صرف enable_registration_without_verification: true set نہ کریں، کیونکہ open homeserver spam source بن جاتا ہے اور دیگر administrators آپ کے پورے domain کو block کر سکتے ہیں۔

کیا میرے homeserver کو federate کرنا چاہیے؟

Federation exposure سے متعلق فیصلہ ہے، default setting نہیں۔ اگر آپ کے صارفین کو دوسرے homeservers پر موجود لوگوں تک رسائی درکار ہو تو federate کریں۔ اگر server صرف ایک team کے لیے ہے تو federation بند رکھیں، کیونکہ non-federating server کم data محفوظ کرتا ہے، کم traffic وصول کرتا ہے اور abuse کو نمایاں طور پر کم متوجہ کرتا ہے۔ درمیانی حل کے طور پر، federation_domain_whitelist federation کو نامزد partner domains تک محدود کرتا ہے۔ Synapse documentation یہ بھی تجویز کرتی ہے کہ federation listener پر firewall rule لگائیں، بجائے اس کے کہ صرف application-layer check پر انحصار کریں۔