Building a Private 'Cloudflare Access' Alternative with OpenZiti and VPS: The Ultimate Zero Trust Architecture
Introduction: The Shift Beyond Traditional Perimeter Security
For years, the standard approach to securing corporate networks and private homelabs relied heavily on Virtual Private Networks (VPNs). However, as cyber threats grow more sophisticated, traditional perimeter-based security models are proving inadequate. Once an attacker gains access to a legacy VPN subnet, they often enjoy unrestricted lateral movement across the entire network. This vulnerability has driven the widespread adoption of Zero Trust Network Access (ZTNA), encapsulated by the philosophy: "Never Trust, Always Verify."
Among commercial ZTNA solutions, Cloudflare Access has emerged as an industry favorite. While powerful and convenient, relying entirely on Cloudflare introduces vendor lock-in, data privacy concerns regarding third-party traffic decryption, and potential cost scaling issues. Fortunately, an open-source paradigm shift allows organizations to regain complete sovereignty over their data. By combining OpenZiti—a powerful, next-generation programmable zero-trust networking platform—with a standard Virtual Private Server (VPS), you can deploy a completely private, self-hosted alternative to Cloudflare Access. This guide breaks down the architecture, advantages, and implementation strategies required to achieve absolute zero trust.
---Understanding Cloudflare Access vs. The OpenZiti Paradigm
Cloudflare Access functions by placing an identity-aware proxy between your users and your applications. When a user requests access, Cloudflare verifies their identity via an Identity Provider (IdP) and routes authenticated traffic through their edge network to your origin server, often using outbound tunnels (Cloudflare Tunnel).
While efficient, this architecture has fundamental trade-offs compared to a self-hosted OpenZiti deployment on a private VPS:
- Data Privacy: Cloudflare acts as a man-in-the-middle to inspect traffic and enforce policies. With OpenZiti, traffic is end-to-end encrypted (E2EE). Even your controller or VPS routing components cannot decrypt the application payload; decryption only occurs at the designated endpoint.
- Network Overlay Control: Cloudflare operates primarily at layers 4 and 7. OpenZiti provides true dark-network connectivity across layers 3, 4, and 7, allowing you to embed zero-trust security directly into your application code via SDKs, or deploy it at the OS level.
- Vendor Lock-in: Migrating away from Cloudflare means reconfiguring tunnels, access policies, and DNS. OpenZiti uses open-source components, ensuring your security architecture remains entirely portable across any cloud or on-premises environment.
The Core Architectural Design
To replicate and exceed the capabilities of Cloudflare Access, our private architecture utilizes three core building blocks: a centralized Controller, Edge Routers, and Endpoints.
1. The Control Plane (OpenZiti Controller)
The OpenZiti Controller acts as the brain of your zero-trust network. Deployed on a publicly accessible VPS, it manages authentication, issues certificates via an internal PKI (Public Key Infrastructure), coordinates policies, and orchestrates network paths. Crucially, the controller does not handle application data traffic directly, keeping its resource utilization lightweight and secure.
2. The Data Plane (OpenZiti Edge Routers)
Edge Routers are responsible for moving application data across the overlay network. In this architecture, we deploy a public Edge Router on the same VPS as the controller. This router acts as a secure, high-performance transit point. On the private network side (your home network, local lab, or private cloud), we deploy a private Edge Router. This private router establishes an outbound-only connection to the public VPS router. Because it requires no inbound open ports on your local firewall, your infrastructure remains completely hidden from public internet port scanners.
3. The Endpoints (Ziti Edge Clients)
Users access private applications through lightweight endpoint software (available for Windows, macOS, Linux, iOS, and Android) or via browser-based zero-trust enrollment. When a user attempts to access a protected service, the endpoint authenticates against the controller, establishes an encrypted tunnel to the nearest public Edge Router, and securely bridges the connection straight to the private destination.
Key Architectural Blueprint: Client Endpoint → (Authenticated & E2EE) → Public VPS Router → (Outbound-only Tunnel) → Private Edge Router → Target Application.---
Step-by-Step Implementation Strategy
Building this infrastructure requires systematic deployment across your public VPS and your private infrastructure. Here is the operational roadmap to achieve a production-ready setup.
Phase 1: Setting Up the Public VPS Environment
First, provision a standard Linux VPS (Ubuntu 22.04 LTS or 24.04 LTS recommended) with a dedicated public IP address. Ensure your firewall is strictly configured. You will need to open specific ports for the OpenZiti Controller API (typically port 8441) and the Edge Router data plane (typically port 443 or 8442). Leverage a public DNS record (e.g., ziti.yourdomain.com) pointing to your VPS IP to simplify certificate management and endpoint enrollment.
Phase 2: Deploying the OpenZiti Controller
The most efficient method to initialize the network control plane is utilizing OpenZiti’s verified Docker Compose configurations or running the network bootstrap script. This process automatically generates the internal root CA, creates administrative cryptographic identities, and boots the controller UI. Once completed, verify the controller status by logging into the Ziti CLI or web console:
ziti edge login [https://ziti.yourdomain.com:8441](https://ziti.yourdomain.com:8441) -u admin -p YourSecurePasswordPhase 3: Provisioning and Enrolling Edge Routers
Next, define your routers within the controller. Create a public router hosted directly on the VPS to handle internet traffic routing, and a private router for your local network backend. The controller will output a registration token (a .jwt file) for each router. On your private local server, install the OpenZiti router binary or launch it via Docker, providing the JWT file during initial boot. The private router will dial out to the VPS, creating a persistent, bidirectional multiplexed data tunnel without requiring any port forwarding on your local router.
Phase 4: Defining Services, Identities, and Edge Policies
With the network fabric established, you must explicitly declare your services and access permissions. In a Zero Trust architecture, nothing connects by default. You must configure three distinct policies:
- Services: Define the internal application you want to expose (e.g., a private web app at
192.168.1.50:8080) and give it an overlay network hostname (e.g.,webapp.ziti). - Identities: Generate cryptographic identities for your remote users or devices. Each identity receives a unique enrollment token.
- Service Policies: Create Dial and Bind policies. A "Bind" policy permits the private local router to host the service, while a "Dial" policy grants specific user identities permission to connect to and access that service.
Advanced Security Enhancements: Beyond Commercial Overlays
By migrating to a self-hosted OpenZiti solution, you unlock advanced security postures that go well numbers beyond standard commercial reverse proxies:
Continuous Posture Assessment
OpenZiti allows administrators to enforce strict device posture checks before granting access to a service. You can configure policies requiring that an endpoint must have an active firewall enabled, run a specific operating system version, or possess a specific corporate cryptographic file/registry key. If an endpoint fails any posture check, its access to the overlay fabric is instantaneously revoked.
Application-Embedded Zero Trust (SDKs)
The ultimate state of Zero Trust is moving security from the network layer directly into the application layer. OpenZiti offers extensive developer SDKs (C, Go, Java, Python, Node.js, etc.). By embedding OpenZiti directly into your custom-built applications, your software does not open listening network ports on the host operating system at all. It only listens on the virtual Ziti fabric, rendering the application completely invisible to network-level attacks, exploits, and zero-day portfolio scans.
---Conclusion: Sovereign, Zero-Trust Access Control
Replacing Cloudflare Access with a private combination of OpenZiti and a VPS represents a major milestone in taking ownership of your infrastructure's security posture. By eliminating open inbound ports, implementing mandatory end-to-end encryption, and enforcing granular, identity-driven access policies, you establish an ironclad defensive barrier around your private applications. While it requires a higher degree of technical configuration than commercial point-and-click overlays, the rewards—absolute data sovereignty, zero vendor lock-in, and elite network customization—are well worth the investment. It is time to take back control of your perimeter and deploy a true, self-hosted Zero Trust architecture.