Self-hosting your communication infrastructure shouldn’t mean accepting a subpar user experience. When organizations move away from Big Tech infrastructure—specifically by stripping Google’s Firebase Cloud Messaging (FCM) out of their Android fleets—the common wisdom is that they must sacrifice battery life and reliability in the name of privacy.
We recently set out to prove that assumption wrong. We built a sovereign, highly-secure Matrix communications stack leveraging Tuwunel, LiveKit, and Defguard VPN. The objective was absolute: zero metadata leakage, core services strictly shielded behind a VPN, and performance that rivals billion-dollar commercial products.
Here is a deep dive into the cross-platform engineering and edge-case tuning required to make it happen.
The SSRF Dilemma: Pushing Notifications into a VPN
To achieve total privacy, we deployed ntfy as a UnifiedPush provider. By keeping ntfy shielded behind our Defguard VPN, we ensured that push payloads never traversed the public internet.
However, this introduced a severe architectural conflict with our Matrix homeserver (Tuwunel). Modern Matrix homeservers include strict Server-Side Request Forgery (SSRF) protections. By design, if a homeserver attempts to resolve a Push Gateway domain and realizes it points to a private IP address (like our 10.240.x.x VPN subnet), it instantly aborts the HTTP request. This mechanism prevents attackers from registering malicious push URLs to scan internal networks.
Architectural Approach: Many administrators lazily solve this by exposing their push gateway to the public internet, defeating the purpose of a private VPN stack.
For maximum theoretical security, the strict approach is to extract the homeserver’s default ip_range_denylist and manually punch a hole exclusively for the specific VPN subnet (e.g., 10.x.x.x), leaving localhost and other bridge networks blocked.
However, because RemoteRails deploys this stack across diverse enterprise environments where VPN subnets can be highly dynamic or unpredictable, we took a more universal architectural approach. Because our entire environment is rigorously locked down behind Traefik middlewares and the Defguard VPN Gateway, we had the luxury of delegating network security entirely to the infrastructure layer. We completely disabled the internal application-level SSRF filter (ip_range_denylist = []).
By relying on our hardened network boundaries rather than fragile application-level IP filters, the homeserver securely pushes payloads directly into the VPN tunnel regardless of the underlying subnet. Because ntfy maintains a persistent WebSocket connection to the mobile device, our call notifications actually ring faster than traditional Firebase pushes, which often suffer from queue delays on Google’s end.
iOS WebRTC Optimization: Curing the Thermal Throttle
A private communication stack isn’t just about text; it requires high-fidelity voice and video. We use LiveKit for WebRTC routing, but during testing, we noticed a glaring issue: while Android and Desktop clients ran cool, our iOS devices (like the iPhone SE 3) were experiencing severe thermal throttling, battery drain, and choppy video.
The Root Cause: WebRTC servers often default to the widely supported VP8 or VP9 video codecs. While modern Android and PC processors feature dedicated hardware decoders for VP8, Apple’s A-series silicon does not. When LiveKit negotiated VP8, the iPhone was forced to encode and decode the entire video stream in software using its CPU.
Architectural Approach: We modified our LiveKit server configuration to explicitly prioritize the video/h264 codec at the top of the negotiation list, keeping VP8 as a fallback for obscure Linux clients:
room:
enabled_codecs:
- mime: audio/opus
- mime: audio/red
- mime: video/h264
- mime: video/vp8
Because iPhones have highly optimized, dedicated silicon for H.264, the video processing was instantly offloaded to the hardware. The CPU usage plummeted, the thermal alerts vanished, and the video smoothed out to a buttery 60 frames per second.
Engineering a Custom VPN Client to Conquer Android Doze Mode
The next complex hurdle in our fully-isolated stack was the VPN client itself. To receive our internal ntfy pushes, the mobile device must maintain a persistent connection to the Defguard VPN tunnel at all times.
Interestingly, the official Defguard iOS client handled this flawlessly out of the box. Apple’s NetworkExtension framework manages VPN interfaces at the OS level, effortlessly pausing and resuming the WireGuard tunnel across device sleep states without relying on fragile userspace health-checks.
Android, however, was a different story. During load testing on Pixel and GrapheneOS devices, we discovered a critical flaw in the official open-source Defguard Android client: notifications would randomly drop ~3 minutes after the phone screen turned off.
By analyzing the client’s Kotlin source code, we traced the issue to an internal health-checking heuristic. When Android entered “Doze Mode” (its aggressive battery optimization state), it naturally paused background network traffic. Instead of waiting for the OS to wake the network, the Android Defguard client’s health-checker assumed the VPN gateway was permanently unreachable and deliberately executed a closeTunnel() command, instantly severing the phone’s ability to receive incoming pushes.
Architectural Approach: Relying on the upstream developer to merge a fix for such a niche edge-case wasn’t an option for a production deployment. Instead, we pulled the open-source repository, forked the Defguard Android client, and patched the DISCONNECTION_THRESHOLD inside WireguardPlugin.kt to gracefully handle Android’s deep-sleep states.
We then compiled our own custom APK, signed it, and deployed it to the fleet. The result is a rock-solid Android VPN tunnel that behaves just as reliably as its iOS counterpart, ensuring timely push notification delivery indefinitely.
Bridging Firefox, Kyber Cryptography, and Mobile MTUs
While the core server architecture was locked down, we encountered a fascinating client-side networking edge case regarding Element Web. When users accessed Element Web via Firefox over 4G/5G mobile data connections (such as mobile broadband or tethering), they experienced severe, intermittent connectivity drops.
The Root Cause: This issue stems from the intersection of modern TLS negotiation and cellular packet fragmentation. Firefox recently enabled Post-Quantum Cryptography (specifically the Kyber key exchange) and HTTP/2 by default. Kyber cryptographic keys are massive compared to traditional elliptic curves. When negotiating a TLS handshake over a mobile network with strict Maximum Transmission Unit (MTU) limits, the massive Kyber packets fragment. The combination of this fragmentation and Firefox’s HTTP/2 implementation causes the connection to the Matrix homeserver to repeatedly hang or silently drop.
Architectural Approach: For users experiencing this on mobile data, the immediate recommendation is to dive into Firefox’s about:config and disable Kyber key exchanges and HTTP/2, or simply switch to the native Element Desktop app or a Chromium-based browser (which handles the MTU fragmentation more gracefully).
The Future (Sliding Sync): Fortunately, this is a temporary pain point. The broader solution lies in Sliding Sync (MSC3575). Element X already utilizes Sliding Sync to massively reduce the initial sync payload and connection overhead. Once Sliding Sync is fully adopted in Element Web, the drastically reduced payload and streamlined API calls will allow even Firefox to smoothly negotiate HTTP/2 connections over varied, highly-fragmented cellular networks.
The RemoteRails Difference
Deploying a Docker container is easy. Engineering an appliance that gracefully handles Server-Side Request Forgery logic, WebRTC hardware encoding negotiations, Android battery heuristics, and post-quantum TLS MTU fragmentation requires a deep understanding of the entire networking stack.
Our configurations weren’t born in a lab—they are the result of rigorous, cross-platform testing of text chat, 1:1 voice calls, and multi-party video conferences across iOS, Android, macOS, Windows, and Linux environments.
At RemoteRails, we don’t just build sovereign infrastructure; we tune it until it outperforms the commercial alternatives. If your organization requires communication infrastructure that is entirely under your control without sacrificing the user experience, we can help.