When building a self-hosted cloud appliance like RemoteRails, securing access is the first and most critical architectural decision. The instinct of many in the homelab and self-hosting communities is to reach for modern, popular mesh VPNs like Tailscale or NetBird. They are incredibly polished, “zero-config” tools that magically connect devices across complex NATs and firewalls.
But for a truly sovereign appliance—one where you own your data, your control plane, and your identities—a peer-to-peer mesh network is actually the wrong tool for the job.
Here is why RemoteRails chose Defguard as its Zero Trust Network Access (ZTNA) and OpenID Connect (OIDC) layer, instead of industry favorites like Tailscale or NetBird.
The Identity Dilemma: Consuming vs. Providing
This is the most critical distinction. Mesh VPNs are fantastic networking tools, but they fundamentally consume identity; they do not provide it.
Tailscale and NetBird rely on external Identity Providers (IdPs). To log in, you are typically kicked out to Google Workspace, Microsoft Entra, GitHub, or Okta. If your goal is digital sovereignty—escaping the data silos of Big Tech—relying on Google to authenticate your access to your private Nextcloud or Matrix server defeats the entire purpose.
You can self-host the identity layer for tools like NetBird, but doing so requires running a heavyweight, enterprise IdP like Keycloak or Zitadel. Bundling a resource-heavy standalone IdP (like Keycloak with its hefty JVM footprint) into a sleek cloud appliance dramatically inflates RAM requirements.
The Defguard Advantage: Defguard is a rare 2-in-1 solution. It is a high-performance WireGuard VPN gateway, but its open-source (AGPL) core also includes a fully-fledged OpenID Connect (OIDC) Identity Provider built natively into it.
While Defguard does offer the ability to act as an OIDC consumer (syncing from Google Workspace or Microsoft Entra) or sync users from an existing LDAP/Active Directory, utilizing these features forces you back into the exact Big Tech dependencies that a sovereign stack is designed to escape.
For RemoteRails, relying exclusively on Defguard’s built-in IdP is a deliberate architectural choice. It guarantees secure network access and the Single Sign-On (SSO) backbone required for Vaultwarden, Nextcloud, and Tuwunel in a single, lightweight binary. You own your identities, end-to-end, without relying on external directories or third-party cloud infrastructure.
Control Plane Sovereignty
A core tenet of RemoteRails is that your data is yours.
Tailscale relies on a proprietary SaaS coordination server. While the actual encrypted traffic is peer-to-peer, your device metadata, network layout, and access policies live on Tailscale’s servers. If their service goes down, or if they ban your account, your network breaks. (While the open-source Headscale exists, it lacks polish and still suffers from the identity dependency mentioned above).
NetBird can be self-hosted, but doing so securely requires exposing its management UI and API to the internet, or putting it behind yet another proxy layer, increasing complexity.
The Defguard Architecture: Defguard ensures that the entire control plane remains strictly on your own hardware, but it goes a step further with its containerized microservice architecture. Defguard purposefully separates its highly sensitive Core (the Identity Provider, database, and management UI) from its Gateway (WireGuard) and Enrollment endpoints.
In the RemoteRails appliance, only the WireGuard Gateway port and the self-service Enrollment endpoint are internet-facing. The Defguard Core is completely isolated from the public internet. This means external attackers cannot even attempt to brute-force the management login screen or probe the Identity Provider. This architectural separation significantly reduces the attack surface compared to monolithic VPN servers where the management interface is exposed alongside the gateway.
Network Topology: Hub-and-Spoke vs. Full Mesh
When evaluating network architecture, you have to ask: What are we actually trying to connect?
Tailscale and NetBird are designed to create Peer-to-Peer (P2P) Mesh networks. They are built so your phone can talk directly to your laptop, your home NAS can talk to your cloud server, and everything routes around firewalls seamlessly.
However, RemoteRails is a centralized cloud appliance. It is a Hub, and the users (your phone, your laptop) are Spokes.
A common counterargument is: “But what about Tuwunel (Matrix)? Users are chatting with each other, isn’t that East-West traffic that benefits from a P2P mesh?”
The answer is no. Matrix relies on a client-server architecture. When Alice messages Bob, Alice’s phone does not connect directly to Bob’s phone. Alice connects to the RemoteRails VPS (the Hub) to send the encrypted message, and Bob connects to the VPS to retrieve it. The only bandwidth-heavy, real-time media traffic is WebRTC video/voice streams via LiveKit—and as noted later, RemoteRails intelligently routes LiveKit outside the VPN anyway to maximize media performance!
The Nextcloud Bandwidth Advantage: This Hub-and-Spoke topology is also particularly beneficial for data-heavy applications like Nextcloud. In a P2P mesh network, if direct NAT traversal fails between peers, traffic often falls back to cloud relay servers (like Tailscale’s DERP nodes), which can severely throttle your bandwidth. Because RemoteRails is a centralized appliance with a static, public IP, NAT traversal is a non-issue. Your phone and laptop establish a direct, un-relayed WireGuard tunnel straight to the gigabit pipeline of the cloud server. Since Nextcloud’s data flow is inherently Hub-and-Spoke (upload to server, download from server), Defguard’s centralized ZTNA gateway guarantees maximum throughput for large file syncs without the overhead of P2P network negotiation or relay bottlenecks.
Therefore, forcing a full mesh topology onto a centralized appliance provides zero performance benefit for your applications. Instead, it unnecessarily complicates routing and actively increases the attack surface. If a laptop on a true P2P mesh network is compromised by malware, that malware automatically establishes direct, peer-to-peer network connections to every other user’s phone or laptop, making lateral isolation incredibly difficult to enforce.
Defguard operates on a traditional ZTNA Gateway model. It perfectly maps to the architecture of RemoteRails: clients securely ingress to a central Traefik choke point. While Defguard does not isolate VPN clients from each other on the VPN subnet by default, the Gateway model means all traffic is routed through a single, manageable bottleneck. By simply applying a firewall rule to the appliance (or utilizing Defguard’s Enterprise ACLs), an administrator can instantly drop east-west traffic and guarantee lateral isolation—a feat that is structurally far more complex in a decentralized mesh.
True Edge Security with Network-Layer MFA
Standard WireGuard is incredibly fast and secure, but it lacks native support for Multi-Factor Authentication (MFA). Once a device has the keys, it’s on the network.
Defguard solves this by enforcing MFA directly into the VPN connection lifecycle. A user cannot establish the WireGuard handshake without passing OIDC and MFA checks (like TOTP or WebAuthn hardware keys).
Because RemoteRails heavily utilizes Traefik middlewares to restrict internal services to users on the Defguard VPN network, unauthenticated packets are dropped at the absolute edge of the VPS. An attacker can’t even port-scan or reach the login screens of your applications without first cryptographically proving their identity to the Defguard gateway.
A Practical Example: Mobile 2FA in Action
Imagine an administrator enables “Enforce MFA” on the RemoteRails Defguard gateway. Here is what the end-user experience looks like on a mobile device:
- The Connection Attempt: The user opens the Defguard mobile app on their iPhone or Android device and taps “Connect.”
- The Interception: Instead of instantly tunneling traffic (like standard WireGuard), the Defguard client intercepts the connection and prompts the user to authenticate.
- The Biometric Verification: The app invokes the device’s native WebAuthn/FIDO2 capabilities. On an iPhone, the user simply glances at their screen for Face ID. On a MacBook or supported Android device, they tap their fingerprint on the Touch ID / Fingerprint sensor.
- The Fallback: If biometric authentication is unavailable or fails, the user can seamlessly fall back to entering a standard TOTP code generated by an authenticator app (like Aegis or Authy).
- The Handshake: Only after the biometric or TOTP challenge is successfully verified against the RemoteRails IdP does the client receive the WireGuard keys and establish the tunnel.
This transforms a device from simply “having the VPN profile” into requiring active, biometric proof of user presence before a single byte of application data is transmitted.
Raw Performance: The Kernel-Level WireGuard Advantage
An appliance like RemoteRails isn’t just serving simple text pages; it’s handling heavy data loads. Nextcloud requires high-bandwidth file syncing for large documents and photos, and Tuwunel (Matrix) manages the real-time state of your communications. (Note: RemoteRails wisely routes LiveKit and TURN to bypass the VPN for actual WebRTC media streams to prevent double-encryption latency and MTU issues, but all Matrix signaling, chat history, and Nextcloud file transfers remain strictly inside the tunnel).
If the VPN layer introduces too much overhead, the entire appliance feels sluggish.
Defguard is built natively around the WireGuard protocol. Unlike older VPN technologies (like OpenVPN or IPsec) which often operate in “user-space” and suffer from heavy context-switching overhead, WireGuard can run directly inside the Linux kernel – on the server-side.
Furthermore, because Defguard orchestrates the native WireGuard interface (rather than relying on heavy user-space overlays for data transport), RemoteRails users achieve near line-rate gigabit speeds for their file syncing. The cryptography (ChaCha20-Poly1305) is incredibly efficient even on mobile devices, ensuring that your phone’s battery isn’t drained while staying connected to your sovereign cloud 24/7. It provides the stateless, instant-roaming capabilities required for mobile clients switching between WiFi and cellular data without losing connection to the chat server.
IT Operations: Provisioning, Auditing, and The Kill Switch
Beyond network topology, technical buyers evaluate tools based on operational overhead. Defguard significantly streamlines IT workflows compared to decentralized mesh solutions:
- Self-Service Provisioning: IT doesn’t have to manually generate and securely distribute WireGuard
.conffiles. An admin simply creates the user, and the user receives an email. They log into the web UI, scan a QR code with the Defguard mobile app, and their secure profile is injected instantly. Zero helpdesk tickets required. - True RBAC via OIDC Groups: Defguard passes group claims directly to the applications it authenticates. For example, when a user logs into Nextcloud via Defguard SSO, Nextcloud automatically maps and provisions their group membership. This allows administrators to natively restrict sensitive file shares or Nextcloud applications based on centralized OIDC groups. (Note: While group-based permissions work beautifully out of the box with the native
user_oidcapp, setting default storage quotas based on these groups requires installing the separate “Default group quota” app). - The “One-Click” Kill Switch: If a device is compromised or an employee leaves, offboarding across disparate systems is a multi-step nightmare. Because RemoteRails unifies the VPN and the Identity Provider, an admin can disable a user in Defguard with a single click. This instantly invalidates their WireGuard keys (dropping them from the network) and simultaneously revokes their SSO access to Nextcloud, Vaultwarden, and Matrix.
The Sovereign Stack Realized
Mesh networks like Tailscale and NetBird are brilliant engineering solutions for connecting distributed teams and sprawling infrastructure. But a sovereign cloud appliance is a different beast entirely.
By utilizing Defguard, RemoteRails avoids the overhead of a bloated IdP, maintains absolute control over the management plane, and implements a network topology that actually matches its centralized architecture. It proves that true self-hosting doesn’t just mean running the apps yourself—it means owning the identity that grants access to them.