escribí una entrada sobre dejar vercel por cloudflare. ya estaba en firebase.
cybersecurity · May 25, 2026 · 1 min read
la entrada que escribí sobre dejar vercel por cloudflare pages estaba equivocada.
no moví este sitio. ha estado en firebase hosting todo el tiempo, y la razón de que nadie detectara el error es que los archivos que afirmaban lo contrario estaban ahí mismo en el repositorio: un wrangler.toml, un public/_headers y un directorio functions/ lleno de cloudflare pages functions. los tres describían una configuración de hosting que nunca fue la que atendía el tráfico.
cómo me enteré
fui a mirar mis propias cabeceras de respuesta en lugar de fiarme del repositorio. vary: x-fh-requested-host — fh es firebase hosting. luego comparé el html que el dominio estaba sirviendo de verdad contra el sitio que yo creía vivo, y eran idénticos byte a byte, los dos una compilación de abril anterior a casi todo este sitio.
el proyecto también tiene cuatro sitios de hosting. el site por defecto del proyecto y el que está detrás del dominio real devolvían exactamente los mismos 2.713 bytes de html. un firebase deploy normal sin target explícito habría sobrescrito el equivocado, en silencio, sin error ni aviso.
qué está corriendo de verdad
- hosting estático para toda la app, con una reescritura que mapea cada ruta de cliente a un documento html
- cabeceras de caché escritas en un archivo que puedo leer, en lugar de un motor de reglas que las mezcla con comas
- un comando para desplegar, desde una configuración que cabe en una pantalla
lo que dejé atrás, con honestidad
el directorio functions/ eran cloudflare pages functions. firebase hosting es estático, así que no se ejecutan. lo que significa:
/ping,/json,/helpy la vista de terminal responden con el html de la página en lugar de texto- el endpoint del libro de visitas no devuelve nada útil
- la reescritura de
og:por entrada para bots nunca se ejecuta
puedo portarlas a cloud functions cuando realmente las necesite. no lo he hecho, y prefiero escribirlo aquí antes que dejar que un 200 con el cuerpo equivocado siga pareciendo que funciona.
la lección real
no es que firebase sea mejor que cloudflare. no lo es, y no lo reclamo. la lección es que un archivo de configuración en tu repositorio es una afirmación sobre tu infraestructura, y nada la verifica. supe dónde vivía este sitio solo porque leí las cabeceras en lugar de leer el repositorio.
un comentario no es un despliegue.