Table of Contents
🖥️ THE BOARD — Wednesday, September 30, 2026 → Hostinger How-To #19 (Matrix/Element): the family group chat is a rented room — the platform can change rules, price, or drop support with a week’s notice · the artifact: a Matrix homeserver on a Hostinger VPS — Synapse + PostgreSQL + Element Web, your own encrypted chat on your own domain, IDs like @aling-nena:familydomain.ph · KVM 2 (2 vCPU/8GB/100GB NVMe, $8.99/mo intro) is the right server · ~45 minutes, Docker, E2EE by default in private rooms · kw: Matrix server
Key Takeaway
- 🏠 The use case: the family+committee server. Matrix is chat’s open protocol — you run the homeserver, users get @name:yourdomain IDs, and private rooms are end-to-end encrypted (Olm/Megolm) so the server itself only sees ciphertext; the family group chat moves from a rented app to your own address, with federation to the wider network when you want it.
- 💰 KVM 2 is the size: 2 vCPU/8GB RAM/100GB NVMe at $8.99/mo intro (renews $14.99) carries Synapse + Postgres + Element for up to ~20 family/small-team users; KVM 1 (4GB) survives only a tiny single-user instance, and RAM is the resource that decides — not disk.
- 🧩 Six steps, ~45 minutes: point DNS (matrix.domain + element.domain) → generate homeserver.yaml with the Synapse Docker image → docker-compose (Synapse + Postgres-16 + Element-Web) → Caddy/Nginx TLS with the 8448-or-well-known federation choice → register your first admin via CLI → close registration (the safe default).
- 📵 Federation: on, but invite-only. Keep enable_registration false and moderate by invitation — the closed posture handles 95% of home operators; the .well-known delegation files give your users the short-form IDs while you host on a subdomain.
- ✅ Payoff: the family chat that can’t be upsold, throttled, or deleted — plus the bridge menu (Telegram/Slack/Discord via mautrix) so lolo’s Messenger still pipes in during the migration month, and the 2026 backup cadence that makes the server survivable.
Your family’s group chat is a rented room — and a Matrix server is the deed that ends the rent. The platform owns the doors, the rules can change with a policy e-mail, the free tier’s price is your data, and the migration tax is enormous because nobody owns the room key. A Matrix server flips this ownership: a Matrix server runs Synapse (the reference homeserver, maintained by Element) on a $8.99-class Hostinger KVM 2 VPS, your users connect through Element (web + the phone apps), private rooms encrypt end-to-end so the server only ever sees ciphertext, and — the part that matters at Filipino scale — federation means your cousin’s room on another homeserver can join your family room without anyone renting anything. This how-to builds the whole stack in six steps on Hostinger’s KVM 2: DNS, the Synapse config generation, the three-service docker-compose (Synapse + PostgreSQL + Element Web), TLS with automatic certificates, the first admin account, and the closed-registration posture that keeps moderating trivial. It’s the piece in the cluster with the clearest family angle — the VPS that runs the n8n automation, the Nextcloud files, the Immich photo vault, or the Vaultwarden vault can host the family’s Matrix server chat too, one server carrying the household’s entire private stack. The commands are the artifact — block by block, with the ₱-relevant sizing arithmetic and the two failure modes that eat first-timers (the SQLite default and the 8448 delegation trap) called out where they bite.
WorldNgayon Analysis: The home-server renaissance isn’t about hating the cloud — it’s that ₱500/month now buys a household a private chat+files+photos+passwords stack that used to cost four subscriptions; Matrix is the piece of the stack that keeps the family’s words as private as its photos.
Bottom Line: Six Docker steps on a KVM 2 put the family chat on your own domain, encrypted by default — the rented room gets an exit, and lolo keeps his Messenger bridge until he’s ready.
Why a Matrix Server Beats Every Free Chat App for the Family Stack
The comparison that decides the build isn’t features — it’s ownership, and it plays out in four questions. Who holds the keys? WhatsApp/Signal/FB-Messenger hold the account, the room, and the member list; a Matrix server holds all three on your VPS — you can export every room, back up the Postgres database in one file, and re-point the domain if the server ever changes hands. Who reads the words? Private rooms on Matrix are E2EE by default in modern clients: keys are per-device, server sees ciphertext, and verification is cross-signed — the same cryptographic posture Signal uses, but on infrastructure you control. What happens to the price? Free chat apps monetize attention and data; your VPS costs $8.99/mo for the whole stack (chat + everything else the cluster runs) with a renewal caveat the pricing note covers honestly. What happens at migration? This is the free apps’ lock-in moat: no export, no room ownership, no identity portability — whereas Matrix IDs (@user:domain) are designed to move, bridges keep old platforms reachable during the transition (the mautrix-telegram bridge runs lolo’s Telegram into the family room during migration month), and nobody has to download a new app for your domain — they log in anywhere through Element. The honest counter-case: a homeserver is a small ops job (updates, backups, the quarterly media-retention prune) — the checklist in the ops section makes it a 10-minutes-a-month job, but it IS a job; the family that won’t run any ops should stay in the rented app and just upgrade its hygiene (the Vaultwarden password layer runs inside any chat app). For the family that already runs ANY of this cluster’s builds, the marginal cost of adding the chat is one docker-compose file.
Bottom Line: Free apps rent you the room and monetize the furniture; a Matrix server hands your family the deed — the ops job is real but it’s a tens-of-minutes-per-month job, and every other piece in this cluster already runs on the same VPS.
The Hostinger Sizing Decision — Why KVM 2 and Not KVM 1
A Matrix server is RAM-hungry by design: Synapse keeps room state in memory, joins on large federated rooms pull the room graph into RAM, and the official guidance for a single-user federating instance is already 2GB-3GB steady before your family’s own rooms. The plan math with the three stacks that matter (chat + Postgres + Element, and — the real reason for the KVM 2 — everything else the family stack hosts): KVM 1 ($6.49/mo intro, 1 vCPU, 4GB RAM, 50GB NVMe): works ONLY as a single-user Conduit/Dendrite experiment — Synapse + Postgres + media on 4GB fits a single user and two rooms, but the moment the family’s five phones join, the OOM killer starts making room for itself. KVM 2 ($8.99/mo intro, 2 vCPU, 8GB RAM, 100GB NVMe, renews $14.99): the drill’s default — Synapse’s steady state plus a 20-user family with media headroom, and enough spare RAM to keep Immich or the n8n workflows alive on the same server; 100GB NVMe buys months of media headroom with the retention config tuned. KVM 4 ($12.99/mo, 4 vCPU, 16GB RAM, 200GB NVMe): the committee/sari-sari-coop tier — a 50-user community server with bridges active, Mjolnir moderation bot running, and the full family stack (Nextcloud + Immich + Vaultwarden + Matrix) on one box with headroom. The media reality check that sizes the disk: federated public rooms pull media to your disk (a busy public homeserver adds ~1GB/week), so the family server’s defense is the room-directory discipline — private, invite-only rooms don’t hoard other servers’ media, and Synapse’s media_retention config prunes old federation media quarterly. The ₱ translation: KVM 2 intro is ~₱510/month for the whole family stack — the price of one coffee-shop afternoon for the deed to the family’s words.
Bottom Line: KVM 2 is the matrix-server floor for a real family (the Matrix server needs 2-3GB steady + your other stacks); KVM 1 is the experiment tier, KVM 4 the community tier — buy RAM, not disk.
Step 1-2: Order the Matrix Server VPS, Point the DNS, Generate the Config
Step 0 — order KVM 2 on Hostinger’s VPS page, pick the region nearest the family (Singapore for PH, Tokyo if the family is Japan-heavy), OS template: Debian 12 or Ubuntu 24.04, and enable the weekly backups (they’re included) plus plan a snapshot before each major change. Step 1 — DNS (five minutes, before SSH): two A-records on your domain — matrix.yourdomain.ph (the Matrix server hostname) and element.yourdomain.ph (the web client) — both pointing at the VPS IP; the base domain (where you might already host the Nextcloud or a family page) WILL also carry two tiny well-known files later for delegation. Step 2 — generate the config (the 60-second command from the official Synapse installation docs that writes homeserver.yaml):
mkdir -p ~/synapse/data && docker run -it --rm \
-v ~/synapse/data:/data \
-e SYNAPSE_SERVER_NAME=yourdomain.ph \
-e SYNAPSE_REPORT_STATS=no \
matrixdotorg/synapse:latest generate
Three config decisions live in the generated homeserver.yaml — make them before first start: server_name is your domain (this becomes every user’s @name:yourdomain.ph identity and CANNOT be changed later — the server name is the family’s chat address, choose it like you chose the surname); public_baseurl = https://matrix.yourdomain.ph; and enable_registration: false (the closed default you relax only deliberately). The SQLite-to-Postgres switch happens in Step 3’s compose file — Synapse’s default SQLite is for test installs only (the developers say it explicitly: production unsupported, corruption risk under load) — this is failure mode #1 first-timers eat.
database:
name: psycopg2
args:
user: synapse
password: YOUR_DB_PASS
dbname: synapse
host: postgres
port: 5432
cp_min: 5
cp_max: 10
Bottom Line: The server name is forever — pick the family domain like a surname, deny registration on day one, and never let SQLite near a prod install.
Step 3-4: The docker-compose Stack That Runs Your Matrix Server
Step 3 — the three-service compose file (Synapse + Postgres 16 + Element Web) — this is the artifact’s heart, drop it into your Matrix server directory at ~/synapse/docker-compose.yml with the passwords you set:
services:
synapse:
image: matrixdotorg/synapse:latest
container_name: synapse
volumes:
- ./data:/data
environment:
SYNAPSE_CONFIG_DIR: /data
SYNAPSE_CONFIG_PATH: /data/homeserver.yaml
depends_on:
postgres:
condition: service_healthy
networks: [matrix-net]
restart: unless-stopped
postgres:
image: postgres:16-alpine
environment:
POSTGRES_DB: synapse
POSTGRES_USER: synapse
POSTGRES_PASSWORD: YOUR_DB_PASS
POSTGRES_INITDB_ARGS: "--encoding=UTF-8 --lc-collate=C --lc-ctype=C"
healthcheck:
test: ["CMD-SHELL", "pg_isready -U synapse"]
interval: 5s
timeout: 5s
retries: 10
networks: [matrix-net]
restart: unless-stopped
element:
image: vectorim/element-web:latest
volumes:
- ./element-config.json:/app/config.json:ro
ports: ["127.0.0.1:8001:80"]
networks: [matrix-net]
restart: unless-stopped
networks:
matrix-net:
The element-config.json that binds the web client to YOUR server (not matrix.org — the trap where the family accidentally logs into the public homeserver):
{
"default_server_config": {
"m.homeserver": { "base_url": "https://matrix.yourdomain.ph" }
},
"brand": "Family HQ",
"default_theme": "dark"
}
Step 4 — the TLS front door (the part that makes federation’s certificate dance trivial): Caddy is the drill’s recommendation — two site blocks, automatic Let’s Encrypt, zero cert files to manage:
matrix.yourdomain.ph {
reverse_proxy /_matrix/* 127.0.0.1:8008
reverse_proxy /_synapse/client/* 127.0.0.1:8008
}
element.yourdomain.ph {
reverse_proxy 127.0.0.1:8001
}
Note the pattern: only 80/443 face the internet (no direct 0.0.0.0 bindings on the containers — the compose file binds Element to loopback, Synapse stays inside the internal network); federation rides port 8448 OR the well-known delegation over 443 — the delegation path is the modern default and avoids the extra open port (failure mode #2 the first-timer burns an evening on: “connection refused on 8448” is almost always a well-known file that isn’t being served — verify AFTER the Caddy block below with the Federation Tester).
Bottom Line: Three services, one internal network, Caddy for certs — the stack is two config files and one compose file, all in ~/synapse, all restarted by one command.
Step 5-6: Federation Well-Known, First Admin, and the Closed Door
Step 5 — the delegation files (two small JSON files served from your base domain — if the domain’s site already runs on Hostinger web hosting, this is two files in public_html; if the domain is on the same VPS, two more Caddy blocks):
mkdir -p ~/well-known/matrix
echo '{"m.server": "matrix.yourdomain.ph:443"}' > ~/well-known/matrix/server
echo '{"m.homeserver": {"base_url": "https://matrix.yourdomain.ph"}}' > ~/well-known/matrix/client
These make @aleng:yourdomain.ph resolve to the subdomain-hosted server — the family types short IDs, the server lives on a subdomain (the pattern Synapse’s own installation docs recommend for production). Verify federation before inviting anyone: the Matrix Federation Tester shows every check green when delegation, TLS, and ports are right — the 45-minute Matrix server build ends here in the tester’s all-green.
Step 6 — the first admin and the closed door:
docker exec -it synapse register_new_matrix_user \
-u admin -a -c /data/homeserver.yaml http://localhost:8008
You now log in at https://element.yourdomain.ph, create the family room, tick the E2EE box, and invite each member from Element’s app. Registration stays closed — every family account is created by the admin CLI, which is what keeps the moderation surface at zero (no spambots, no federation abuse — the closed posture is the 95%-of-operators answer). The bridge optional step that eases the migration month (mautrix-telegram runs the lolo bridge; mautrix-signal and mautrix-facebook exist for the rest): bridges are the one component with a per-user session maintenance rhythm, so start with exactly ONE bridge — the platform the elders actually refuse to leave — and add more only when the family’s Element habit is sticking.
Bottom Line: Two JSON files for delegation, one CLI command for the admin, one invited room with E2EE ticked — the family’s deed ceremony takes about a minute, the tester’s green checks on the Matrix server are the ribbon.
The 10-Minutes-a-Month Ops Sheet — Updates, Backups, and the Real Failure Modes
The Matrix server is a household appliance with a warranty, and the maintenance contract for the Matrix server is this: monthly (5 minutes) — docker compose pull && docker compose up -d for security updates, check the weekly Hostinger backup completed (it’s included; verify the newest artifact exists, don’t assume), glance at docker stats for RAM creep; quarterly (5 minutes) — prune federation media via Synapse’s media_retention, review the room directory, snapshot before any upgrade (KVM plans include manual snapshots — take one, then pull the upgrade — rollback is a click when an image update misbehaves); yearly (the 15-minute audit) — rotate the Postgres password if it’s ever left a person’s hands, re-verify backups by restoring one into a scratch directory (a backup never restored is a hope, not a backup), and check the cert automation’s renewals in Caddy’s logs. The two REAL failure modes this build generates, mapped to their fixes: RAM creep (Synapse’s caches grow — the global_factor 0.5 tune in homeserver.yaml caps it; KVM 2’s 8GB has headroom but watch docker stats monthly) and the forgotten well-known file (if federation breaks after a base-domain site migration, it’s almost always the delegation block lost in the move — the Federation Tester diagnoses in one run). The security posture the server inherits from the cluster: the Vaultwarden-adjacent habits (unique passwords, admin 2FA), the firewall that face only 80/443, and the same “the vault holds the keys, not the sticky note” discipline — the server’s admin account is now the family’s crown jewel credential, and it goes in YOUR password vault the day you create it.
Bottom Line: Monthly pull-and-verify, quarterly prune-and-snapshot, yearly restore-test — ten minutes a month keeps the deed real; the backup you never restore is a rumor.
The Bridge Menu and the Migration Month — Moving the Family Without a Mutiny
Adoption is the real project; the server build was the easy part. The migration month that works (sequence, not ultimatum): week 1 — you + one willing relative run the room on Element, keep the old chat for the rest (the bridge pipes Telegram in so messages land in one place you both can see); week 2 — invite the household one by one, Element installed on their phones, the well-known delegation doing its work (they log in with just their family-domain ID, no server URL gymnastics thanks to the client well-known file); week 3 — the first E2EE verification ceremony is a family event (each member verifies their own devices — the security UX that makes the encryption real); week 4 — the old platform’s room becomes the archive (export it if you can; if you can’t — that’s the whole point of this piece), and the Matrix room is home. What the family gains, concretely at Filipino scale: the voice-call room without the subscription upsell, the photos that live in Immich and the words that live at the family domain, the OFW-relative who can join from the Riyadh jobsite over any network without the platform’s regional quirks, and the house rule that actually holds — “our messages, our keys, our server” — priced at ₱510/month for the deed. When the build’s done and the tester runs green, the family cluster is complete: Matrix server (chat — this piece) + files (Nextcloud) + photos (Immich) + passwords (Vaultwarden) + automation (n8n) — five rooms of the same house your subscription money used to rent room-by-room.
Bottom Line: Bridge the elders in, verify devices as an event, archive the rented room with a receipt of what leaving it was worth — the five-stack household runs on one VPS and one habit.
Frequently Asked Questions
What is a Matrix server and why would a family need one?
Matrix is chat’s open, federated protocol: you run the homeserver (Synapse) on your own VPS, your family gets IDs you own (@name:yourdomain), private rooms are end-to-end encrypted so the server sees only ciphertext, and rooms can even bridge with other platforms during migration. It’s the alternative to a rented room: no account bans, no policy changes, no monetized data — priced at ~$8.99/mo intro for the KVM 2 that runs the whole family stack.
How much does it cost to run a Matrix server on Hostinger?
KVM 2 ($8.99/mo intro, renews $14.99) is the right floor for a family server with headroom for other self-hosted apps on the same box; KVM 1 (4GB RAM) survives only a single-user experiment, and KVM 4 ($12.99/mo) covers 50-user community servers with active bridges. Total stack cost = the VPS alone; Synapse, PostgreSQL, Element, and Caddy are open source.
Do my family members need to install anything special?
Element only — the free app on iOS/Android or the browser client you host at element.yourdomain.ph. They log in with their @name:yourdomain.ph ID (the well-known files resolve the server automatically) and verify their devices once to complete the E2EE handshake — the rest feels like any chat app, which is exactly the point.
Is Matrix really end-to-end encrypted by default?
Private rooms and direct messages are E2EE in modern Element clients by default (per-device keys, cross-signing, verification badged in the UI); public and federated-public rooms are unencrypted by design because anyone may join. The family server’s rule: private rooms for the family’s actual business — and the server never holds a readable copy either way.
Can I bridge Telegram or WhatsApp into my Matrix room?
Telegram, Signal, Facebook, Slack and Discord have maintained mautrix-family bridges — Matrix’s answer to “the family won’t all leave one app.” Start with exactly ONE bridge for the person most attached to the old app, expect light session maintenance, and treat WhatsApp bridging as the experimental end (its API is the least friendly) — the migration month sequence in this piece assumes one bridge, one month, one household habit at a time.
Financial Disclaimer: This article is for general information and education, not investment or financial advice. Hosting prices and plan specs change frequently; verify current terms with providers before purchase. WorldNgayon.com is not a financial adviser and holds affiliate relationships with hosting providers mentioned in this article.
Prefer voices over keyboards? The Home Assistant Voice server build chains Whisper and Piper on the same KVM family — the voice layer this chat server plugs into.
