The short answer
Yes. Every CloudSite site has its own deploy-provider setting and can publish to Cloudflare Pages or Google Firebase Hosting. The same site files, chat-based editing and growth modules work on both — there is no separate Firebase copy to maintain.
Set the default under Settings → Defaults. Existing sites can switch from the status card on the site detail page, and batch jobs or MCP site creation can specify the provider explicitly.
How the two deploy targets differ
- Cloudflare Pages: direct static upload with a <slug>.pages.dev address; connecting a domain creates the CNAME and issues HTTPS automatically.
- Firebase Hosting: deploys through the official Hosting REST API and a live release, with a <siteId>.web.app address.
- Firebase site IDs are globally unique. If a slug is taken, CloudSite adds a stable hash suffix and stores the real ID on the site record.
- Firebase has a hard limit of 36 Hosting sites per project; Cloudflare domain limits depend on the plan.
What the Firebase deploy does
CloudSite follows the official Firebase REST workflow. There is no Firebase CLI, Git repository or build pipeline involved:
- Check whether the site exists in the project and create it if needed.
- Create a new version and compute a gzip + SHA-256 hash for each file.
- Call populateFiles and upload only the hashes the server is missing.
- Mark the version FINALIZED and create a release on the live channel.
- The site is served at https://<siteId>.web.app, also reachable through firebaseapp.com.
- Cloudflare-specific _headers, _redirects, _routes.json and _worker.js files are skipped.
How the 36-site limit is counted
36 is Firebase's official limit on Hosting sites per project, not a CloudSite plan limit. Every web.app site consumes one slot whether or not a custom domain is attached.
When the project is full, CloudSite reports it before attempting a deploy. Delete unused Firebase sites or move to another Firebase project and update the service account.
Batch building needs planning: if the default provider is Firebase, a 200-site batch cannot fit in one project. Split the batch or send some sites to Cloudflare.
Custom domains and DNS
After connecting a domain, Firebase returns the required A, AAAA, CNAME, TXT or CAA records. CloudSite shows the type, name and value directly on the domain card.
If the domain lives in the connected Cloudflare account, CloudSite tries to apply them safely: TXT is created only when missing; a matching CNAME is unproxied; A / AAAA records are touched only when they match exactly or do not exist; CAA is always left for the user.
When a record cannot be written safely, add it manually from the card. Certificate status comes from cert.state; a CAA restriction must allow pki.goog for Firebase to issue the certificate.
Switching from Cloudflare to Firebase
- Paste the service-account JSON under Settings → Firebase Hosting and verify the connection.
- On the site detail page, switch the deploy provider to Firebase.
- Redeploy once so CloudSite creates or reuses the Firebase site and publishes the current files.
- Reconnect the domain under Domains and apply the records Firebase returns.
- Old Cloudflare domains do not migrate automatically. Remove the old binding only after the new address works.
How to choose
- Automatic CNAME, HTTPS and a high per-project domain limit: Cloudflare Pages.
- Already on Google Cloud or Firebase, or need a web.app address: Firebase Hosting.
- A client requires content to stay on Google infrastructure: Firebase.
- Approaching 36 sites without splitting projects: stay on Cloudflare or split by business unit.