A self-hosted communication platform can bring together messaging, voice and video calls, screen sharing and streaming. Access controls, useful diagnostics and reliable recovery belong in the design as well. The following concept shows how these responsibilities can fit together.
In this article
Give each component a clear role
Element and Cinny provide Matrix interfaces. Nginx can serve the web applications. Synapse manages accounts, rooms and messages; PostgreSQL stores persistent data. HAProxy controls the public HTTP entry point and routes requests to the intended services.
Redis can support shared caches and communication between Synapse processes when needed. A single Synapse process is often sufficient for a small installation. Additional components should solve a specific operational need.
Plan calls and streaming separately
MatrixRTC adds LiveKit and an authorization service such as lk-jwt. The service connects a Matrix identity with access to the appropriate LiveKit room and issues access tokens. Depending on the version, it integrates through Synapse or a separate authorization endpoint.
HTTPS and WebSockets carry signaling. Audio and video use additional WebRTC connections. LiveKit includes its own TURN service. coturn can support other compatible WebRTC or legacy calling paths; it is not a required hop in front of LiveKit.
Encrypt private content
In end-to-end encrypted Matrix rooms, a server administrator cannot decrypt messages without the relevant room keys. Accounts, room membership and technical metadata are separate concerns. For calls, end-to-end encryption must be checked for the specific clients and media features in use.
TLS, disk encryption, device verification and secure key recovery complement this design. They protect different parts of the system and do not replace one another.
Hardening and abuse protection
At the public entry point, use known hostnames, controlled client-IP headers and application-appropriate request limits and timeouts. Restrict admin interfaces and APIs to authorized access. Databases and caches do not need public Internet access. For TLS to backends, validate both the trust chain and server identity.
Fail2ban with custom filters can detect repeated authentication failures or clearly defined abuse patterns in logs and trigger temporary bans. Test filters against real, sanitized log samples and legitimate traffic. Behind a proxy, obtain the real client IP from a trusted source and enforce bans where they can actually block that client; otherwise the proxy itself may be blocked.
Administration, logs and recovery
Synapse Admin supports Matrix administration. Graylog can collect relevant operational events through a log collector. This provides a shared view of access failures, login problems and media setup issues.
Keep tokens, credentials and unnecessary personal data out of logs. Limit access and retention. Updates, backups and tested restores are part of operating the platform.
Validate it in everyday use
Element, Cinny and calling features can provide a path towards an alternative to Discord. Whether that fits depends on the features people need and the community’s experience.
Before release, test concrete workflows. Do messages arrive? Do calls work across different networks? Can keys be recovered after changing devices, and can data be restored from backup? These checks make the concept testable in practice.
Further reading: Matrix E2EE · Synapse / Redis · LiveKit / TURN · lk-jwt · Cinny · Fail2ban