Ewii vs. Cloudflare Tunnel

Cloudflare Tunnel (cloudflared) is the option most engineers reach for when they need outbound-only connectivity. It is well-built, widely deployed, and it works. For a single-tenant developer-tool use case, it is often the right answer.

For an AI or SaaS operator selling into regulated industries, the model breaks down in two specific places: the data path runs through Cloudflare’s network, and the control plane and key custody are Cloudflare’s. Both come up in every serious security review. Both require an answer that “trust Cloudflare” cannot satisfy.

Topology

Dimension	Ewii	Cloudflare Tunnel
Relay operator	You	Cloudflare
Datacenter jurisdiction	You choose (Canadian KMS by default for Ewii CA)	Cloudflare’s global edge
Key custody	You hold the issuer; Hub holds the trust bundle	Cloudflare’s PKI
Tenant isolation primitive	SPIFFE workload identity per Client	Cloudflare account boundary
Operator control plane	Hub binary in your infra	Cloudflare dashboard
Audit trail destination	Your SIEM, your log retention policy	Cloudflare logs
Egress IP from Hub	Yours	Cloudflare’s

The data path question

Cloudflare Tunnel terminates TLS at Cloudflare’s edge. The traffic is then re-encrypted from Cloudflare to the customer-side cloudflared daemon. This is documented and intentional — it is how Cloudflare delivers WAF, bot management, and the rest of the platform.

For most use cases this is fine. For a clinical-AI vendor reaching a hospital’s EHR over a Tunnel, it is not fine. The hospital’s privacy officer has to be told that PHI traverses a third party’s network in a form Cloudflare can decrypt. That conversation goes one of two ways: a long compensating-control discussion that delays procurement, or a hard “no, find another vendor.”

Ewii’s data path runs Hub → relay → Client over end-to-end ChaCha20-Poly1305 encryption with X25519 ephemeral key exchange. The relay holds ciphertext only. You can show your customer’s privacy officer the cryptographic primitive matrix and the source of the relay binary. They can audit the path without trusting a third party with their data.

Key custody and tenant boundaries

In Cloudflare Tunnel, tenant isolation is the Cloudflare account boundary. If you sell to ten customers, each customer either lives in your Cloudflare account (shared tenancy at the operator level) or has their own Cloudflare account that you have to coordinate with (operationally painful and shifts the customer’s security posture onto Cloudflare).

In Ewii, each Client gets a SPIFFE / X.509 SVID issued by your trust domain. The Hub validates the SVID at handshake against a per-tenant trust bundle. There is no shared account. The customer’s security team can verify that their tenant is cryptographically isolated from your other customers; the proof is in the certificate validation logic, not in a vendor’s promise about logical isolation.

Operational fit

Cloudflare Tunnel is configured through the Cloudflare dashboard or wrangler. Tunnel state — routes, access policies, audit log destinations — lives in Cloudflare’s control plane. If your customer’s compliance regime requires that operational state about their tenancy live inside their network or yours (common in Canadian Protected B and PCI-DSS environments), this is a problem that needs a memo.

Ewii’s Hub runs in your infrastructure. Configuration is declarative — you can keep it in your existing GitOps pipeline. There is no third-party dashboard holding tenant state. Your audit log goes to your SIEM. Your retention policy applies. You can answer the procurement question “where does our connectivity metadata live” with one sentence.

When Cloudflare Tunnel is the right answer

If you are a small team building a B2C product and you need outbound-only connectivity from a developer’s laptop to a homelab, use cloudflared. It is faster to set up, it is free for that scale, and the issues this page raises are not relevant.

If you are selling to a hospital, a federal agency, a payment processor, or a bank — talk to us about an Architecture Review.