You're right about the choke point. The agents are great for user devices, but they can't enforce policy on server-to-server traffic or legacy industrial systems that don't run an agent.
Your bullet points, especially about processing and logging entirely within the perimeter before any cloud sync, is what kills most hybrid models. The local node usually just buffers logs; the actual inspection and DLP processing still happens in the cloud. That's a data sovereignty fail for air-gapped requirements.
Did your security team ever consider a cost trade-off? Like accepting a lesser, dedicated on-prem box for that 5% of traffic while using Cloudflare One for everything else? The TCO might still win if you isolate the scope of the requirement.
That's a really good point about agents and server traffic. It's easy to focus on user devices during a POC and forget about the industrial control systems or mainframe connections that simply can't have an agent installed.
Your question about a cost trade-off is where we're stuck. Our security team's stance is that once a vendor's product touches air-gapped traffic, even for 5% of it, that vendor's entire platform must comply with the full physical hardware requirement. They won't approve a bifurcated model with the same vendor, calling it a "management plane contamination risk." So the suggestion to use a lesser on-prem box from a *different* vendor for that segment might be the only path, but it introduces a whole new operational layer.
Has anyone found a way to formally segment a vendor's own product like that, with separate legal agreements and support pipelines, to get past a blanket security policy?
So when they say "cloud console is the product," does that mean the pricing model is built around the cloud service? We saw a cheaper TCO for the cloud side, but the quote for the "local processing node" seemed to add a huge premium. It's like paying twice for half the features.
You're exactly right. That premium is the cost of the vendor trying to force-fit a cloud-native architecture into a physical box. The product's development and sales model is for the cloud service. The "node" is a costly afterthought that gets you a stripped-down, policy-enforcing proxy, not the full cloud stack. It's not built for volume. You're paying a high margin for a niche, low-demand hardware SKU.
I've seen pricing where the local node cost per gigabit is 5-10x the cloud service cost. It's not a mistake; it's a strategic choice to steer you back to the pure cloud model.
Numbers don't lie
Ah, the classic "we love the cloud but need a box" dilemma. I've run into this exact thing in data integration, where a tool's cloud model is perfect until you have a legacy mainframe or a secured lab network that can't have an outbound connection.
That third bullet, *full feature parity on that local box*, is where it always falls apart. Even vendors that offer a local node treat it as a dumb pipe, not the full intelligence engine. The real DLP processing or inspection engine lives in their cloud, so your sensitive data is still leaving the perimeter, just maybe in a different format. It defeats the whole air-gapped requirement.
Your security team's stance makes total sense. Have you looked at treating that air-gapped segment as a totally separate problem? Run a purpose-built, true on-prem tool for just those flows and keep Cloudflare One for everything else. The operational overhead of two tools is real, but it's often cheaper than forcing a cloud vendor into a box-shaped hole.
ship it