The operational overhead of a self-hosted proxy isn't just the initial setup, it's the drift over time. Your team needs to maintain the Terraform or Deployment Manager configs, rotate any internal service account keys, and keep the underlying image patched. That's a non-trivial runbook that now exists because the vendor's control plane lacks a private endpoint.
I agree the VPC-bound model is the correct one. The shift we're seeing is that these newer platforms treat their own management UI as a customer-facing SaaS product, not as infrastructure. It's a fundamental design choice that externalizes the security responsibility.
The decoupling you describe is the real win here. It moves the auth boundary from a vendor-specific control panel to an edge layer you actually own. This becomes critical when your team's tooling changes, or when you need to enforce something Supabase's native roles can't handle, like time-of-day restrictions or geo-blocking.
But I've seen teams trip on the operational reality. That orange-clouded proxy step? It's not a set-and-forget. If your Supabase project needs to talk to other services, or you're using its realtime features, you're now debugging through a reverse proxy you didn't have before. Suddenly you're a part-time Cloudflare network admin on top of everything else.
The centralization is a double-edged sword. Yes, you get one policy engine. You also get a single point of failure. When Access has an outage, your whole dev team is locked out of their database admin UI, not just their email.
Speed up your build
That's a fair warning about the operational load. But isn't the single point of failure argument a bit overstated? If Cloudflare Access goes down, it's not like we could reach the Supabase Studio directly anyway, since we'd be blocking that original URL. Everyone's just locked out a different way.
Maybe the bigger risk is misconfiguring the proxy rules and breaking something like realtime. Have you run into issues with WebSockets or long-polling connections through Access? I'm trying to gauge how brittle this setup really is.
The decoupling you describe is the real win here. It moves the auth boundary from a vendor-specific control panel to an edge layer you actually own. This becomes critical when your team's tooling changes, or when you need to enforce something Supabase's native roles can't handle, like time-of-day restrictions or geo-blocking.
But I've seen teams trip on the operational reality. That orange-clouded proxy step? It's not a set-and-forget. If your Supabase project needs to talk to other services, or you're using its realtime features, you're now debugging through a reverse proxy you didn't have before. Suddenly you're a part-time Cloudflare network admin on top of everything else.
The centralization is a double-edged sword. Yes, you get one policy engine. You also get a single point of failure that you're now responsible for tuning.
Oh wow, that's a really easy mistake to make. It's exactly the kind of "obvious in hindsight" thing I'd miss on my first try. When you set up a friendly internal URL, your brain just focuses on that new path and forgets the old public one is still sitting there.
So if I understand right, the block rule for the original URL would go into Cloudflare Access *before* the allow rule for your internal hostname? So it's like a blanket "deny" for the public address, and then a specific "allow" for your custom one?
Thanks for the warning. It probably saved me a future awkward talk.
Just my two cents.