Self-hosting checklist (Mastodon, Nextcloud, Matrix)

"I'll just spin up a VPS and run Mastodon" is how a lot of self- hosting projects start. The good ones add: "and I have a plan for backups, mail, TLS, monitoring, and rotation of long-running processes." This article is the checklist of things to think through before installing the popular self-hostable applications, with brief notes on the three that LYLIX customers ask about most: Mastodon, Nextcloud, and Matrix.

The universal checklist

Before you install anything, you need answers to:

Question	Why it matters
Do you have a domain name?	Required for TLS, federation, and most self-hostable apps. Buy one before deploying.
Have you set DNS pointing at the VPS?	A record (and AAAA if IPv6); takes minutes but Let's Encrypt needs it before you can issue certs.
How will mail be sent?	Most apps send password resets, notifications. Self- hosting SMTP is hard (deliverability); usually you'll relay through SendGrid, Mailgun, or similar.
How will you back up data?	Off-host. Snapshots aren't enough. See off-host backups.
Who's responsible if it goes down at 2am?	You. Self-hosting means self-support. If that's unacceptable, use a hosted service.
How will you know it's down?	External monitoring (UptimeRobot, Pingdom, etc.). Watching it yourself doesn't scale.
How will you handle upgrades?	Most self-hostable apps push releases every few weeks. Plan for the cadence; commit to applying them.

If you've got "I'll figure it out" on more than two of those, think hard before installing. Self-hosting is rewarding when it works and exhausting when it doesn't.

Mastodon

What it is: federated social network server. You run an "instance"; users on it federate with users on other instances.

Minimum specs: 2 vCPU, 4 GB RAM, 30 GB disk for a few users. Goes up steeply with user count and federation volume.

Stack: Ruby on Rails (the web app), PostgreSQL, Redis, Sidekiq (background jobs), nginx (reverse proxy), optionally Elasticsearch for full-text search.

Easy install path: Docker Compose with the official docker-compose.yml. Hard install: from source. The Docker route works fine on a 4-8 GB VPS for a small instance.

Things that bite:

• Storage grows fast. Federated media (other servers' images and videos) cache on your disk. Plan for ~50 GB even on a small instance. Use S3-compatible object storage (Backblaze B2 + Mastodon's S3 support) to keep the VPS disk smaller.
• Mail required. Sign-up confirmations, password resets. Use Mailgun / SendGrid / Postmark — not a self-hosted SMTP.
• Sidekiq tuning matters. Default thread counts are conservative; large federation queues will lag. Adjust MAX_THREADS per worker if your VPS has spare CPU.
• Federation policy. Decide early if you'll block known-bad servers (use a defederation blocklist) and how you'll handle abuse reports.
• Backups are critical. Mastodon's database is the social graph; losing it means losing your community. pg_dumpall daily, off-host.

Nextcloud

What it is: file sync & share (Dropbox replacement), plus calendar, contacts, and a growing app ecosystem.

Minimum specs: 1 vCPU, 2 GB RAM, disk proportional to what you'll store. Nextcloud comfortably runs on a 4 GB VPS for a household; corporate use needs more.

Stack: PHP-FPM, PostgreSQL or MariaDB, Redis (for caching), nginx, optionally Collabora Online for document editing.

Easy install path: NextcloudPi script, official Docker image, or AIO (All-in-One) Docker setup. AIO is the easiest end-to-end.

Things that bite:

• PHP version drift. Nextcloud is opinionated about which PHP versions it supports; bump too aggressively and the app errors out.
• Background jobs need a cron entry (not the default AJAX scheduler — that's flaky). Set up /etc/cron.d/nextcloud with cron-based scheduling.
• External storage (S3, SFTP, etc.) is powerful but adds latency. Test with realistic file sizes.
• Updates are mandatory. Skipping security updates on a Nextcloud instance accessible to the internet is a known pattern for compromise.
• Backups include database AND data directory. The database tracks file metadata; the data dir has the actual blobs. Both, together.

Matrix (Synapse or Dendrite)

What it is: federated real-time chat. Most people run the Synapse reference implementation; Dendrite is the lighter Go-based alternative.

Minimum specs: 1-2 vCPU, 2-4 GB RAM, disk proportional to room history. Heavy federation increases RAM significantly; a single room shared with Matrix.org can balloon your database to multiple GB.

Stack: Python (Synapse) or Go (Dendrite), PostgreSQL, nginx reverse proxy, Element (web client, run separately or use a hosted instance).

Easy install path: matrix-docker-ansible-deploy (opinionated Ansible playbook that handles Synapse, PostgreSQL, nginx, Element, mail relay, etc.) is by far the easiest way. Recommended over hand-installing for first-timers.

Things that bite:

• Federation eats resources. Joining a few big public rooms can balloon disk usage and memory. Decide early whether you'll be federated or closed.
• Database can grow huge. Synapse stores every event from every federated room. Set up state_compress and periodic database compaction.
• End-to-end encryption is the default in DMs — backups need to handle key recovery for users.
• The reference web client (Element) is a separate thing. You can self-host it on the same VPS or point users at app.element.io.
• SIP/voice bridging is possible but advanced. If you want Matrix and your PBX talking to each other, budget more time.

Mail server prerequisites — read this before any of the above

All three applications need to send mail (notifications, password resets, invitations). Self-hosting SMTP from a VPS in 2026 is hard:

• Reverse DNS must be set (PTR matching forward A record).
• SPF, DKIM, DMARC all configured.
• You'll likely still get spam-filtered by major recipients until you build IP reputation over months.

For self-hosted apps, the standard recommendation is:

• Use a relay service. Mailgun (free tier ~5k/month), SendGrid (free tier ~100/day), Postmark, Amazon SES, etc. Configure the app to send through the relay rather than running its own SMTP.
• Relay services have IP reputation built up; your mail delivers reliably from day one.
• Costs are minimal at hobby scale.

If you really want to self-host SMTP too, read the mail-server prerequisites article carefully and budget extra time for deliverability work.

Sizing budget for the three apps

App	Hobby (few users)	Small (~50 users)
Mastodon	2 vCPU / 4 GB / 30 GB + S3 for media	4 vCPU / 8 GB / 100 GB + S3
Nextcloud	1 vCPU / 2 GB / disk = your storage need	2 vCPU / 4 GB / disk = your storage need
Synapse	1 vCPU / 2 GB / 20 GB (closed/limited fed)	2 vCPU / 4 GB / 50 GB+ if federating

These are starting points; real usage varies a lot. Watch resource graphs (see that article) and adjust.

The "should I really self-host?" question

Self-hosting is rewarding for the right reasons (control, privacy, the satisfaction of running your own thing). It's a poor decision if:

• You're using it for business and can't afford downtime, but you can't commit time to operate it.
• You'd be the only user. Hosted services usually offer better UX for one person at a small monthly cost.
• You don't enjoy the operational side. The first compromised-by-spammers Matrix server is when you find out whether you actually like sysadmin work.

It's a great decision if you want the learning, the control, or you have specific privacy / customization needs that hosted services can't meet.

LYLIX is built for self-hosters; you've come to the right place. Just go in with eyes open.