i wrote a post about leaving vercel for cloudflare. i was already on firebase.

cybersecurity · May 25, 2026 · 1 min read

the post i wrote about leaving vercel for cloudflare pages was wrong.

i did not move this site. it has been on firebase hosting the entire time, and the reason nobody caught the mistake is that the files claiming otherwise were sitting right there in the repo: a wrangler.toml, a public/_headers, and a functions/ directory full of cloudflare pages functions. all three described a hosting setup that was never the one answering traffic.

how i found out

i went to look at my own response headers instead of trusting the repo. vary: x-fh-requested-host — fh is firebase hosting. then i diffed the html the domain was actually serving against the site i believed was live, and they were byte identical, both of them an april build that predated most of this site.

the project also holds four hosting sites. the project default and the one behind the real domain were returning the exact same 2713 bytes of html. a plain firebase deploy without an explicit target would have overwritten the wrong one, silently, with no error and no warning.

what is actually running

  • static hosting for the whole app, with a rewrite mapping every client route to one html document
  • cache headers written down in a file i can read, instead of a rules engine that merges them with commas
  • one command to deploy, from a config that fits on a screen

what i gave up, honestly

the functions/ directory was cloudflare pages functions. firebase hosting is static, so they do not run. which means:

  • /ping, /json, /help and the terminal view answer with the page html instead of text
  • the guestbook endpoint returns nothing useful
  • the per-post og: rewriting for bots never executes

i can port those to cloud functions when i actually need them. i have not, and i would rather write that here than let a 200 with the wrong body keep looking like it works.

the actual lesson

not that firebase is better than cloudflare. it is not, and i am not claiming it is. the lesson is that a config file in your repo is a claim about your infrastructure, and nothing verifies it. i knew where this site lived only because i read the headers instead of reading the repository.

a comment is not a deployment.