FlutterFlow SSL renewal behind Cloudflare: preserving FCM web push

Help General
1

Hi everyone, has anyone solved custom-domain SSL renewal for a FlutterFlow-hosted Flutter web app behind Cloudflare while preserving Firebase web push?

FlutterFlow shows “Domain Connected”, but renewing the certificate fails with “Expected DNS records not found”. The apex A record and www CNAME are configured to FlutterFlow’s targets, with Cloudflare proxy enabled.

The complication is that a Cloudflare Worker serves /firebase-messaging-sw.js on the custom domain. Disabling the proxy would bypass that route. I need to preserve the existing notification setup, including web, Android and iOS.

Read-only checks on 23 September 2026:

  • Public DNS returns Cloudflare IPs; the FlutterFlow custom-domain target resolves to the origin IP.
  • The homepage returns HTTP 200 both through Cloudflare and directly from the origin.
  • /firebase-messaging-sw.js returns HTTP 200 with a JavaScript content type through Cloudflare, but HTTP 404 directly from the origin.
  • The www worker URL returns 200 through Cloudflare; directly from the origin it redirects to the apex worker URL.
  • TLS verification succeeds on both paths. The origin certificate expires on 16 October 2026; Cloudflare’s edge certificate expires later.

Direct-origin checks preserved the original hostname and TLS SNI using curl’s --resolve option. No DNS, deployment or application settings were changed.

My working hypothesis is that FlutterFlow’s renewal validation expects the origin DNS values but sees Cloudflare’s public IPs. This is not confirmed without FlutterFlow’s validation logs.

I have contacted FlutterFlow support and filed GitHub issue #7538. I’m hoping for practical experience from the community:

  1. Is there a supported way to renew the origin certificate while keeping Cloudflare proxy enabled, such as separate DNS/TXT validation?
  2. Alternatively, can FlutterFlow hosting serve the FCM service-worker file at the same origin so the Cloudflare Worker is no longer necessary?
  3. Has anyone used a reliable arrangement that avoids interrupting existing web push registrations?

Thanks for any pointers or examples.