ద్వారా Matt Connor 2026-08-14 · అప్‌డేట్ చేయబడింది 2026-08-16

VPSలో Matrix Synapse హోమ్‌సర్వర్ నిర్వహణ గైడ్

Q: నా homeserver లో strangers registration చేయకుండా ఎలా ఆపాలి?

enable_registration ను దాని default అయిన false వద్ద ఉంచండి. register_new_matrix_user తో accounts సృష్టించండి. ఈ విధానం పెద్ద పరిమాణంలో నిర్వహించడం కష్టమైతే, registration_requires_token: true తో పాటు enable_registration: 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 చేయవచ్చు.

VPSలో Matrix Synapse హోమ్‌సర్వర్‌ను ఏడాది పాటు నడపడానికి 1 vCPU, 2 GB RAM సరిపోతాయా? PostgreSQL, media retention, registration భద్రత, backups గురించి తెలుసుకోండి.

Matrix Synapse homeserver ను నిరంతరం నిర్వహించడానికి అవసరమైనవి

Matrix Synapse ను ఇన్‌స్టాల్ చేయడం సులభం. దాన్ని నిర్లక్ష్యం చేయడం కూడా సులభమే. ఇన్‌స్టాలేషన్‌కు ఒక apt repository, ఒక config file, ఒక reverse proxy block మరియు ఒక DNS record సరిపోతాయి. అయితే homeserver ను ఒక సంవత్సరం పాటు ఆరోగ్యంగా నిర్వహించడానికి వేరే స్థాయి పని అవసరం: నిజమైన database, క్రమం తప్పకుండా శుభ్రం చేసే media store, అపరిచితులు ఉపయోగించలేని registration వ్యవస్థ, అలాగే server యొక్క రెండు భాగాలనూ కలిగి ఉండే backup.

ఈ guide Ubuntu 24.04 LTS ను లక్ష్యంగా చేసుకుని, matrix.org apt repository నుంచి Synapse ను ఇన్‌స్టాల్ చేస్తుంది. Debian మరియు Ubuntu కోసం Synapse project నిర్వహించే package source ఇదే. Package versions ప్రతి కొన్ని వారాలకు మారుతాయి కాబట్టి, ఇక్కడ version number ఇవ్వలేదు. క్రింద ఉన్న ప్రతి path మరియు option ప్రస్తుత Synapse documentation నుంచి తీసుకున్నవే.

Sizing: 1 vCPU మరియు 2 GB RAM వాస్తవంగా ఏ స్థాయి పనితీరును ఇస్తాయి

2026 ఆగస్టు నాటికి ప్రచురితమైన sizing పేజీలు సాధారణంగా Synapse homeserver కోసం 1 vCPU మరియు 2 GB RAM ను సూచిస్తున్నాయి. ఇది ఒక సందర్భంలో సరైన అంచనా: private server, కొద్దిమంది users, చిన్న rooms, మరియు రద్దీ లేని public rooms ఉన్నప్పుడు. మరో సందర్భం గురించి Synapse documentation స్పష్టంగా చెబుతుంది. #matrix:matrix.org వంటి పెద్ద public rooms లో చేరాలంటే "At least 1GB of free RAM" అవసరమని అది పేర్కొంటుంది. ఈ free RAM అనేది Python, Postgres మరియు kernel కు అవసరమైన మెమరీకి అదనం.

Rooms లో చేరే విధానం కారణంగా ఒకే room మీ sizing అవసరాలను మార్చగలదు. ఒక local user room లో చేరినప్పుడు, మీ homeserver ఆ room లో పూర్తి participant అవుతుంది. ఆ room లోని ప్రతి ఇతర server నుంచి వచ్చే ప్రతి event ను ఇది స్వీకరిస్తుంది, ప్రతి event పై signature ను ధృవీకరిస్తుంది, అలాగే room state ను స్థానికంగా నిల్వ చేస్తుంది. పెద్ద public room లో వందలాది servers పై వేలాది members విస్తరించి ఉంటారు. అందువల్ల మీ user ఆ room ను మళ్లీ ఎప్పుడూ తెరవకపోయినా, మీ server ఈ పనిని నిరంతరం చేస్తుంది. తరువాత room నుంచి నిష్క్రమించినా, ఇప్పటికే నిల్వ చేసిన history తొలగించబడదు.

Synapse RAMలో ఎక్కువ భాగాన్ని caches కోసం ఉపయోగిస్తుంది. caches విభాగంలో ఉన్న global_factor అన్ని caches ను ఒకేసారి scale చేస్తుంది. SYNAPSE_CACHE_FACTOR environment variable కూడా అదే విలువను సెట్ చేస్తుంది. ఈ విలువను పెంచితే database queries తగ్గించడానికి RAM ఎక్కువగా వినియోగించబడుతుంది. దీన్ని తగ్గిస్తే RAM ఆదా అవుతుంది, కానీ CPU మరియు Postgres సమయం ఎక్కువగా వినియోగించబడుతుంది. Postgres కు కూడా స్వంత memory అవసరం. కాబట్టి 2 GB server లో ఈ రెండూ అదే మెమరీ కోసం పోటీ పడతాయి.

చిన్న plan కోసం రెండు ఆచరణాత్మక నియమాలు ఉన్నాయి. Swap జోడించండి. Swap Synapse ను వేగంగా చేయదు. అయితే పెద్ద room join సమయంలో kernel process ను terminate చేయకుండా ఇది సహాయపడుతుంది. మొదటి వారం నుంచే 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 మార్గం కూడా కోల్పోతారు.

తరువాత migrate చేయడం supported, కానీ దీనికి 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 పై నడపడం లో trade-offs వివరించబడ్డాయి.

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ను ఉపయోగించవద్దు. ఆ builds, దాని releases కంటే వెనుకబడి ఉండటంతో పాటు తెలిసిన security bugs కలిగి ఉంటాయి కాబట్టి Synapse project దాన్ని ఉపయోగించవద్దని సూచిస్తుంది.

Installer server nameను అడిగి, మీ సమాధానాన్ని /etc/matrix-synapse/conf.d/server_name.yaml లో వ్రాస్తుంది. దీనికి జాగ్రత్తగా సమాధానం ఇవ్వండి. server_name అనేది ప్రతి user IDలోని colon తర్వాతి భాగం (@alice:example.com). మీ server సృష్టించే ప్రతి roomలో కూడా ఇది చేర్చబడుతుంది. దీన్ని తరువాత మార్చడం వల్ల ఏదీ తరలించబడదు. బదులుగా వేరే homeserver ఏర్పడుతుంది. Synapse స్వయంగా matrix.example.comలో నడిచినా, మీ bare domain, 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

సరిగ్గా ప్రారంభమైనప్పుడు listeners అందుబాటులోకి వచ్చి, తరువాత service నిశ్శబ్దంగా కొనసాగుతుంది. ఏదైనా exit జరిగిన కొన్ని seconds తర్వాత systemd unit serviceను restart చేస్తుంది. అందువల్ల Synapse తిరస్కరించే config, మళ్లీ మళ్లీ ప్రారంభమై ఆగిపోయే unitగా కనిపిస్తుంది. Journalలోని చివరి lines అది తిరస్కరించిన key పేరును చూపిస్తాయి.

Synapse ను Postgres కు అనుసంధానించండి

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 కేవలం అలంకార విషయం కాదు. వేర్వేరు COLLATE మరియు CTYPE విలువలతో సృష్టించిన database పై Synapse ప్రారంభం కావడానికి నిరాకరిస్తుంది. Database config లో allow_unsafe_locale ను సెట్ చేయకపోతే ఇది జరుగుతుంది. ఆ తర్వాత 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;"

సంఖ్య కనిపిస్తే Synapse ఈ database లో తన schema ను సృష్టించిందని అర్థం. relation కనిపించలేదనే error వస్తే, అది ఇప్పటికీ SQLite file లోనే రాస్తోందని అర్థం. కాబట్టి మీరు సవరించిన config file ను Synapse చదవడం లేదు.

Reverse proxy, TLS మరియు federation కు అవసరమైన .well-known ఫైళ్లు

Synapse localhost కు bind అయి, port 8008 పై plain HTTP ను వింటుంది. 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 ద్వారా proxy సెట్ చేసే X-Forwarded-For header ను Synapse నమ్మేలా చెబుతుంది. ఇది లేకపోతే ప్రతి client 127.0.0.1 నుంచి వచ్చినట్టుగా కనిపిస్తుంది. అందువల్ల rate limiting కు ఒకే local user అత్యంత ఎక్కువ traffic పంపుతున్నట్టు కనిపించి, అందరినీ కలిపి 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;
}

ఈ block గురించి Synapse documentation లోని ఒక హెచ్చరికను విస్మరించడం వల్ల చాలామందికి రోజులు వృథా అవుతాయి. Port తర్వాత proxy_pass లో path ను, ఒక్క / అయినా, జోడించకండి. అప్పుడు 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 చేస్తుంది. అందువల్ల వైఫల్యాన్ని వివరించే Synapse log line ఉండదు.

Certificate కోసం Ubuntu 24.04లో Certbot మరియు Let's Encrypt ను అనుసరించండి. Proxy విషయంలో ఇంకా నిర్ణయం తీసుకోకపోతే, TLS పనిని ఏది నిర్వహిస్తుందో reverse proxy పోలిక వివరిస్తుంది.

Delegation వల్ల server_name ను example.com గానే ఉంచి, Synapse ను matrix.example.com పై నడపవచ్చు. Bare domain నుంచి రెండు ఫైళ్లను అందించండి:

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

Federation traffic ను ఎక్కడికి పంపాలో server file ఇతర homeserverలకు చెబుతుంది. దీనివల్ల federation default port 8448 బదులుగా 443 పై నడుస్తుంది. @alice:example.com కు సంబంధించిన URL ఏదో client file Matrix clients కు చెబుతుంది. Client file లో Access-Control-Allow-Origin header ముఖ్యమైనది. Browser-based clients దీన్ని cross-origin గా fetch చేస్తాయి. ఈ header లేకపోతే browser response ను block చేస్తుంది. అప్పుడు client మీ homeserver ను కనుగొనలేకపోయిందని నివేదిస్తుంది.

రెండు ఫైళ్లను example.com నుంచే valid TLS ద్వారా అందించాలి. వాటిని తనిఖీ చేసిన తర్వాత, బయటి ప్రపంచానికి కనిపించే ఫలితాన్ని కూడా తనిఖీ చేయండి:

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

మొదటి command మీరు రాసిన JSON ను అందిస్తుంది. రెండవది server implementation మరియు దాని version పేర్లతో కూడిన JSON object ను అందిస్తుంది. ఇది federation path ద్వారా proxy Synapse ను చేరుతోందని నిర్ధారిస్తుంది. తరువాత domain ను https://federationtester.matrix.org వద్ద Matrix federation tester తో పరీక్షించండి. ఇది నిజమైన remote server అనుసరించే అదే మార్గాన్ని అనుసరిస్తుంది.

Federation ను అనుమతించాలా, వద్దా: ఉద్దేశపూర్వకంగా నిర్ణయించండి

Federation Matrix యొక్క ప్రధాన లక్షణం. అదే సమయంలో ఇది ఎక్కువ ఖర్చుకు కారణం కూడా. Federation చేసే homeserver కు మీకు ఎప్పుడూ తెలియని servers నుంచి connections వస్తాయి. వాటి events ను స్వీకరించాలి. వాటి media ను cache చేయాలి. మీ users ఉపయోగించే ప్రతి room కు state ను నిల్వ చేయాలి. ఇది default కాదు. ఇది threat model కు సంబంధించిన నిర్ణయం.

మీ users ఇతర homeservers లో ఉన్న వ్యక్తులను సంప్రదించాల్సి ఉంటే, లేదా portable identity కోసం Matrix ఎంచుకున్నట్లయితే federation ను అనుమతించండి. Server ఒకే team కోసం మాత్రమే ఉండి, అందులోని ప్రతి account మీ ఆధీనంలో ఉంటే federation ను అనుమతించవద్దు. Closed server తక్కువ data ను నిల్వ చేస్తుంది, తక్కువ data ను స్వీకరిస్తుంది, abuse కోసం చాలా తక్కువ ఆకర్షణీయంగా ఉంటుంది.

Federation ను పూర్తిగా disable చేయకుండా పరిమితం చేయాలంటే, Synapse allow list ను ఉపయోగిస్తుంది:

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

Federation listener ను firewall ద్వారా కూడా పరిమితం చేయాలని documentation సూచిస్తుంది. దీనివల్ల unwanted traffic Python లోకి చేరకముందే network స్థాయిలో ఆగిపోతుంది. Federation ను పూర్తిగా నిలిపివేయాలంటే listener resources list నుంచి federation ను తొలగించండి. /.well-known/matrix/server ను publish చేయవద్దు. Port 8448 ను మూసివుంచండి.

Matrix నడపడానికి కారణం private team chat మాత్రమే అయితే, federation ఎప్పుడూ అవసరం లేకపోతే, Synapse ను ఎంచుకునే ముందు running cost ను ఇతర self-hosted Slack ప్రత్యామ్నాయాలతో పోల్చండి. Docker Compose పై Rocket.Chat చిన్న machine పై team chat ను నిర్వహిస్తుంది. ఎందుకంటే అది మరొక organisation యొక్క room state ను ఎప్పుడూ నిల్వ చేయాల్సిన అవసరం ఉండదు.

మీడియా repository తెలియకుండానే disk ను నింపుతుంది

మీ స్వంత users upload చేసిన files మీ disk పై శాశ్వతంగా ఉంటాయి. ఇతర homeserver లలోని users post చేసిన files ను మీ clients లో ఎవరో ఒకరు display చేసిన వెంటనే మీ disk పై fetch చేసి cache చేస్తుంది. Synapse images కోసం thumbnails కూడా generate చేస్తుంది. అందువల్ల ఒక photo అనేక files గా మారుతుంది. వీటిలో ఏదీ default గా expire కాదు.

Store ను గుర్తించి, దాని పరిమాణాన్ని కొలవండి:

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

మీ స్వంత config print చేసే 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 చేస్తుంది. అది delete చేసే ఏదైనా file ను file ను స్వంతం చేసుకున్న server నుంచి మళ్లీ fetch చేయవచ్చు. local_media_lifetime మీ స్వంత users upload చేసిన local files ఆ వయస్సుకు చేరుకున్న తర్వాత శాశ్వతంగా delete చేస్తుంది. Chat లో documents share చేసి, వాటిని వచ్చే సంవత్సరం కూడా కనుగొనగలమని ఆశించే team వాటిని కోల్పోతుంది. చాలా 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"

ఆ timestamp కు ముందు చివరిసారి access చేసిన cached remote media ను POST /_synapse/admin/v1/purge_media_cache తొలగిస్తుంది. అదే నియమంతో local media ను POST /_synapse/admin/v1/media/delete?before_ts=<ms> delete చేస్తుంది. ముందుగా remote purge ను అమలు చేసి, మళ్లీ కొలవండి. Federation చేసే server లో remote cache సాధారణంగా disk లోని పెద్ద భాగంగా ఉంటుంది.

రెండు settings ఒకే disk వినియోగాన్ని ప్రభావితం చేస్తాయి. max_upload_size ఒక upload పరిమాణానికి గరిష్ఠ పరిమితిని విధిస్తుంది. ఇది nginx లోని client_max_body_size తో సరిపోలాలి. Clients link previews చూపించడానికి మీ server remote pages ను fetch చేసేలా url_preview_enabled: true చేస్తుంది. దీనివల్ల bandwidth వినియోగమవుతుంది. మీకు ఎవరూ upload చేయని content కు సంబంధించిన thumbnails కూడా నిల్వ అవుతాయి.

ఎవరైనా మీ homeserver ను గుర్తించేలోపు registration ను మూసివేయండి

Scanners కొన్ని రోజుల్లో open homeserver ను గుర్తిస్తాయి. ఎవరికైనా ఖాతాలను ఉచితంగా సృష్టించే అవకాశం ఉంటే, మీ server federate అయ్యే ప్రతి room లో spam source గా మారుతుంది. అవతలి వైపు ఉన్న administrators మీ మొత్తం domain ను block చేస్తారు. ఈ reputation నష్టం cleanup పూర్తయిన తర్వాత కూడా కొనసాగుతుంది, ఎందుకంటే block lists ను manually నిర్వహిస్తారు.

Synapse డిఫాల్ట్‌గా registration ను మూసి ఉంచుతుంది. enable_registration డిఫాల్ట్‌గా false కు, registration_requires_token డిఫాల్ట్‌గా false కు అమర్చబడి ఉంటాయి. Verification step లేకుండా registration enabled చేసి ఉంటే, అదనంగా enable_registration_without_verification: true సెట్ చేయకపోతే Synapse ప్రారంభం కావడానికి నిరాకరిస్తుంది. ఈ నిరాకరణ ఉద్దేశపూర్వకమే. 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 కనుగొనలేకపోతున్నానని సందేశం వస్తే, ఆ secret ఉన్న file ను సూచించేలా -c ను సెట్ చేయండి.

ఖాతాలను మాన్యువల్‌గా సృష్టించడం ఇక సరిపోని స్థాయికి చేరితే, మధ్యంతర పరిష్కారంగా registration tokens ఉపయోగించండి. Signup సమయంలో కొత్త user సమర్పించాల్సిన string token. ప్రతి 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

Body లో token ను చేర్చకపోతే, Synapse స్వయంగా ఒక token ను సృష్టించి తిరిగి ఇస్తుంది. ప్రస్తుతం చెల్లుబాటులో ఉన్న tokens ను GET /_synapse/admin/v1/registration_tokens జాబితా చేస్తుంది. ఈ రెండు calls కు server admin ఖాతా యొక్క access token అవసరం. పై విధంగా మీరు సృష్టించిన admin user గా login అవడం ద్వారా దాన్ని పొందవచ్చు.

ఇప్పటికే accounts ను మరొకచోట నిర్వహించే organisation local passwords ను పూర్తిగా వదిలివేయవచ్చు. Synapse OIDC (OpenID Connect) provider కు login ను అప్పగించగలదు. ఉదాహరణకు, self-hosted SSO provider గా Authentik ను ఉపయోగించవచ్చు. అప్పుడు కొత్తగా చేరేవారి మరియు సంస్థను విడిచివెళ్లేవారి నిర్వహణను ఒకే చోట చేయవచ్చు.

వాస్తవంగా సర్వర్‌ను పునర్నిర్మించగల backup

Synapse backup కు మూడు భాగాలు ఉంటాయి. వీటిలో ఏ ఒక్కటి లేకపోయినా, ఎవరూ ఉపయోగించలేని server మాత్రమే restore అవుతుంది.

ప్రతి event, account, room ను కలిగి ఉండే Postgres database.
upload చేసిన ప్రతి file ను కలిగి ఉండే media store directory.
/etc/matrix-synapse, ఇందులో మీ config మరియు server signing key ఉంటాయి.

ప్రజలు తరచుగా మరచిపోయే భాగం signing key. మీ homeserver events కు సంతకం చేయడానికి ఉపయోగించే private key ఇదే. Remote servers events ను దానికి సరిపోలే public key తో ధృవీకరిస్తాయి. మీ signing key ఎక్కడ ఉందో చూడటానికి grep signing_key_path /etc/matrix-synapse/homeserver.yaml అమలు చేయండి. దీన్ని కోల్పోతే, మీ rooms ఇప్పటికే గుర్తించే అదే server అని నిరూపించలేని server ను మాత్రమే మీరు restore చేయగలరు.

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 ద్వారా సూచించబడతాయి. అందువల్ల dump తర్వాత తీసుకున్న media copy లో అదనపు files మాత్రమే ఉండవచ్చు; missing files ఉండవు. వ్యతిరేక క్రమంలో చేస్తే, restore చేసిన database మీ backup లో capture కాని file ను సూచించే అవకాశం ఉంది.

ఈ మూడు భాగాలను VPS వెలుపలికి పంపండి. off-site snapshots తో restic ఈ విధానానికి బాగా సరిపోతుంది. Media store పెద్ద భాగం అయినప్పటికీ runs మధ్య చాలా తక్కువగా మారుతుంది. అందువల్ల deduplication ప్రతి snapshot పరిమాణాన్ని చిన్నగా ఉంచుతుంది.

తరువాత restore ప్రక్రియను సాధన చేయండి. మీరు ఎప్పుడూ restore చేయని backup కేవలం ఒక ఊహ మాత్రమే. రెండవ VPS ను సిద్ధం చేసి, అదే package ను install చేయండి. Config ను restore చేయండి. అదే encoding మరియు locale తో database ను సృష్టించండి. pg_restore dump ను అందులోకి import చేయండి. Media store ను తిరిగి copy చేయండి. తరువాత login అవ్వండి. దీనికి పట్టిన సమయాన్ని నమోదు చేయండి. ఆ సంఖ్యే మీ వాస్తవ recovery time.

స్థితి పట్టికలు పెరిగినప్పుడు: compaction

Synapse room state ను state groups గా నిల్వ చేస్తుంది. Federation చేసే 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'));"

ఆ ఒక్క పట్టికే మీ database లో ఎక్కువ భాగం ఆక్రమిస్తే, దాని కోసం project ఒక compressor ను అందిస్తుంది: rust-synapse-compress-state. ఇది ఏ room state అర్థాన్నీ మార్చకుండా, state group hierarchy ను తక్కువ rows గా తిరిగి రాస్తుంది. ఇది 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 చేయాలో సూచిస్తుంది. Auto compressor తాను ఎంతవరకు పూర్తిచేసిందో నమోదు చేస్తుంది. అందువల్ల తదుపరి run అక్కడి నుంచే కొనసాగుతుంది. ఇదే కారణంగా దీన్ని schedule చేయడం సురక్షితం. Documentation ప్రకారం, మార్పులు append-only tables పై transactions లో apply అవుతాయి. కాబట్టి Synapse నడుస్తున్నప్పుడే ఇది run చేయవచ్చు. అయినప్పటికీ, మొదటి run కు ముందు database backup తీసుకోండి.

ఇక్కడ Postgres లోని ఒక విషయం చాలామందికి ఆశ్చర్యం కలిగిస్తుంది. Rows ను delete చేసినప్పుడు space Postgres లో reuse కోసం తిరిగి అందుబాటులోకి వస్తుంది. అది file system కు తిరిగి వెళ్లదు. అందువల్ల పెద్ద compaction తర్వాత df అసలు మారకపోవచ్చు. VACUUM FULL ఆ space ను file system కు తిరిగి అందిస్తుంది. అయితే ఇది table పై exclusive lock తీసుకుంటుంది. అదనంగా table పరిమాణానికి దాదాపు సమానమైన ఖాళీ disk space అవసరం. కాబట్టి దీన్ని అనుకోకుండా run చేయకుండా 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 active గా ఉండి పునఃప్రారంభం కాకపోవడం, delegation file మీ m.server విలువను తిరిగి ఇవ్వడం, federation version endpoint JSON ను తిరిగి ఇవ్వడం, అలాగే ఈ రెండు size సంఖ్యలను గత నెలవాటితో పోల్చగలగడం. సాధారణంగా దాటవేసే తనిఖీ size తనిఖీ. ఎటువంటి హెచ్చరిక లేకుండానే Synapse server ను నిలిపివేసే వైఫల్యం disk లో ఏర్పడుతుంది: volume నిండిపోతే Postgres రాయడం ఆపేస్తుంది. దాంతో database ను తాకే ప్రతి request లో Synapse విఫలమవుతుంది.

FAQ

Matrix Synapse సర్వర్‌కు ఎంత RAM అవసరం?

కొద్దిమంది వినియోగదారులు, చిన్న rooms, పెద్ద public rooms లేని private homeserver కు 2 GB సరిపోతుంది. August 2026 నాటికి ప్రచురితమైన చాలా sizing పేజీలు ఇదే సూచిస్తున్నాయి. మీ వినియోగదారులు #matrix:matrix.org వంటి పెద్ద public rooms లో చేరితే, మిగిలిన అవసరాలపై అదనంగా కనీసం 1 GB free RAM ఉండాలని Synapse documentation చెబుతోంది. అప్పుడు మీ సర్వర్ ఆ room state ను నిల్వ చేసి, దాని traffic ను నిరంతరం process చేస్తుంది. 2 GB plan పై swap ను జోడించండి. అలా చేస్తే ఒక పెద్ద join కారణంగా kernel process ను kill చేయదు.

SQLite బదులుగా PostgreSQL తప్పనిసరిగా ఉపయోగించాలా?

కొద్దిమందికి మించిన వినియోగదారులు ఉంటే, అవును. SQLite ఒకేసారి ఒక writer ను మాత్రమే అనుమతిస్తుంది. అందువల్ల load పెరిగినప్పుడు federation traffic మరియు client requests పరస్పరం block అవుతాయి. Requests ఒక్కోసారి కొన్ని seconds పాటు hang అవుతాయి. ఒకటి కంటే ఎక్కువ CPU cores ఉపయోగించడానికి supported మార్గమైన Synapse worker processes కు Postgres అవసరం. తరువాత migration చేయడం synapse_port_db తో సాధ్యమే, కానీ downtime అవసరం. అందువల్ల వినియోగదారులు చేరకముందే --encoding=UTF8 --locale=C --template=template0 తో database ను సృష్టించండి.

నా Synapse disk usage ఎందుకు నిరంతరం పెరుగుతోంది?

ఒక directory మరియు ఒక table కారణంగా ఇది జరుగుతుంది. మీ సర్వర్ ఉన్న rooms కు upload చేసిన ప్రతి file ను media store నిల్వ చేస్తుంది. ఇందులో remote users media యొక్క cached copies మరియు generated thumbnails కూడా ఉంటాయి. మీరు media_retention ను configure చేసే వరకు ఏదీ expire కాదు. Federating server లో room state పెరిగే కొద్దీ state_groups_state table కూడా పెరుగుతుంది. rust-synapse-compress-state దాని పరిమాణాన్ని తగ్గిస్తుంది. ఏదిపై పని చేయాలో నిర్ణయించే ముందు రెండింటినీ కొలవండి: మీ media_store_path పై du -sh తో ఒకదాన్ని, SELECT pg_size_pretty(pg_total_relation_size('state_groups_state')); తో మరొకదాన్ని పరిశీలించండి.

నా homeserver లో strangers registration చేయకుండా ఎలా ఆపాలి?

enable_registration ను దాని default అయిన false వద్ద ఉంచండి. register_new_matrix_user తో accounts సృష్టించండి. ఈ విధానం పెద్ద పరిమాణంలో నిర్వహించడం కష్టమైతే, registration_requires_token: true తో పాటు enable_registration: 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 గా ప్రారంభించాల్సిన విషయం కాదు. మీ వినియోగదారులు ఇతర homeservers లోని వ్యక్తులను చేరుకోవాల్సి ఉంటే federation ను ప్రారంభించండి. సర్వర్ ఒక team కోసం మాత్రమే పనిచేస్తే federation ను ఆపివేయండి. Non-federating server తక్కువ data ను నిల్వ చేస్తుంది, తక్కువ traffic ను స్వీకరిస్తుంది, abuse కూడా చాలా తక్కువగా ఎదుర్కొంటుంది. మధ్యస్థ ఎంపికగా, federation_domain_whitelist federation ను పేరుతో పేర్కొన్న partner domains కు పరిమితం చేస్తుంది. అయితే application-layer check పై మాత్రమే ఆధారపడకుండా federation listener ను firewall తో కూడా పరిమితం చేయాలని Synapse documentation సూచిస్తుంది.

#matrix#synapse#self-hosting #postgresql#federation