Dominios personalizados para SaaS: cómo dejar que tus clientes usen su propio dominio con Cloudflare for SaaS

En resumen

Para que un cliente use tu aplicación en su propio dominio, por ejemplo portal.cliente.com, registras ese dominio como un custom hostname en tu zona de Cloudflare. El cliente agrega un registro CNAME que apunta a ti, Cloudflare comprueba que controla ese dominio, una autoridad certificadora emite los certificados y las visitas empiezan a llegar a tu aplicación.

A octubre de 2026, la página de planes de Cloudflare for SaaS incluye 100 hostnames personalizados en los planes Free, Pro y Business, cobra USD 0,10 por cada hostname adicional y pone un tope de 50.000 en esos planes.

Dos límites definen el diseño. Tus clientes no pueden apuntar un dominio raíz (cliente.com) sin un complemento pago de Enterprise. Y los hostnames comodín, los certificados propios y la elección de autoridad certificadora son solo de Enterprise. Configurar Cloudflare son pocos pasos; el trabajo de producto alrededor toma más, y de eso trata casi toda esta guía.

Qué es un hostname personalizado

Es un dominio de tu cliente que Cloudflare enruta hacia tu zona. La guía de configuración tiene cuatro piezas:

• Zona SaaS. Tu propio dominio en Cloudflare, con Cloudflare for SaaS activado. Para empezar basta una zona en el plan Free.
• Origen de respaldo (fallback origin). Un registro DNS con proxy, como proxy-fallback.tuapp.com, que recibe el tráfico de los dominios de clientes.
• Destino CNAME. Un nombre opcional y más fácil de recordar al que apuntan tus clientes, como clientes.tuapp.com.
• Hostname personalizado. El dominio del cliente, creado por API o desde el panel, con su propio estado de validación. Cloudflare emite dos certificados por cada uno: uno ECDSA P-256 y otro RSA de 2048 bits para navegadores antiguos.

Si tu aplicación corre en Cloudflare Workers, la plataforma sobre la que construimos en Dardo, el Worker puede ser el origen de respaldo. Una ruta */* recibe las peticiones de todos los dominios de clientes y tu código lee el encabezado Host para identificar al cliente. Cloudflare ofrece metadatos por hostname, pero son un complemento pago de Enterprise; en los demás planes esa relación vive en tu propia base de datos, como D1.

Cómo funciona el flujo

1. El cliente escribe su dominio en la configuración de tu aplicación. Tu backend lo normaliza y llama al endpoint Create Custom Hostname con un método de validación del certificado.
2. El cliente crea el registro DNS que le muestras, por ejemplo portal.cliente.com CNAME clientes.tuapp.com.
3. Cloudflare valida que el dominio es suyo. La validación en tiempo real ocurre cuando aparece el CNAME y puede dejar el sitio caído unos momentos. La prevalidación usa un registro TXT o un token HTTP antes de cambiar el DNS, para dominios que ya están en producción. No funciona si la zona del cliente también está en Cloudflare (la configuración que Cloudflare llama Orange-to-Orange).
4. La autoridad certificadora valida el control del dominio y emite los certificados.
5. El dominio está listo cuando status y ssl.status están en active y el DNS apunta a tu destino. Cloudflare advierte que el navegador puede conectarse por TLS antes de que ssl.status quede activo, así que la fuente de verdad es el endpoint de detalle del hostname.

Métodos de validación del certificado

La guía de validación de Cloudflare ofrece estas opciones:

La validación no espera para siempre. Según su calendario de reintentos, Cloudflare intenta validar el hostname 75 veces durante siete días y, si no lo logra, lo elimina. Los tokens del certificado también vencen: a los 7 días con Let's Encrypt y a los 14 con Google Trust Services o SSL.com.

Cuánto cuesta, a octubre de 2026

La página de planes no dice el periodo de los USD 0,10. El anuncio de Cloudflare de 2022 lo presentó como una rebaja de USD 2 a USD 0,10 al mes. A ese precio mensual, 1.000 dominios de clientes son 900 por encima de los 100 incluidos, es decir, USD 90 al mes.

Dos reglas de cobro afectan el diseño del producto. Según la página de cuotas y facturación, cada hostname cuenta hasta que lo borras, incluidos los que siguen pendientes de validación o activación. Y los planes que no son Enterprise tienen un umbral en la API a partir del cual rechaza hostnames nuevos.

Dónde falla

Dominios raíz

Según la guía de configuración, apuntar con un registro A al destino no está soportado por defecto. La mayoría de proveedores DNS no permite un CNAME en la raíz del dominio, así que tus clientes necesitan un subdominio como www.cliente.com o app.cliente.com. El proxy de dominio raíz asigna a tu cuenta prefijos de IP fijas para que tus clientes usen un registro A, pero es un complemento de Enterprise con costo propio. Sin él, pide un subdominio y explica cómo redirigir el dominio raíz desde su proveedor DNS.

Autoridades certificadoras y registros CAA

La referencia de autoridades certificadoras lista Let's Encrypt (certificados de 90 días), Google Trust Services y SSL.com (14, 30 o 90 días) para hostnames personalizados. Elegir la autoridad es solo de Enterprise; en los demás planes Cloudflare usa la predeterminada y revisa antes los registros CAA. Si los CAA de tu cliente no permiten esa autoridad, la emisión falla con el error CAA records block issuance, y solo el cliente puede corregirlo. La consulta de CAA sigue las cadenas CNAME, así que también cuentan los CAA de tu propio dominio de destino. La guía de solución de problemas suma otras dos fallas del lado del cliente: DNSSEC mal configurado y servidores DNS que responden SERVFAIL.

Renovaciones

Los certificados duran 90 días y se pueden renovar 30 días antes de vencer. Los hostnames activos y sin comodín se renuevan solos por HTTP. Si el hostname dejó de estar activo, por ejemplo porque el cliente cambió su DNS, el cliente tiene que poner un token nuevo, y enviárselo es tu responsabilidad. Los comodines solo se renuevan por TXT, que es justo lo que automatiza Delegated DCV.

Clientes detrás de otra CDN o en Cloudflare

Cloudflare indica que los hostnames que usan otra CDN no son compatibles cuando esa CDN oculta los registros DNS. Los clientes cuyo dominio está en Cloudflare traen el problema contrario: si se van y no borras su hostname, su tráfico puede seguir llegando a tu servicio aunque cambien el DNS.

Un Worker frente a las rutas de validación

Si tu origen de respaldo es un Worker, tiene que dejar pasar sin cambios /.well-known/pki-validation/* y /.well-known/acme-challenge/*. Una ruta que responde a todo con el 404 de tu aplicación rompe la validación por HTTP.

El trabajo de producto alrededor

• Reglas por plan. Decide qué planes incluyen dominio propio y cuántos, y revísalo antes de llamar a Cloudflare. Su cuota y su umbral son topes técnicos, no tu modelo de precios.
• Pantalla de configuración. Un solo campo. Pásalo a minúsculas, quita protocolo y ruta, rechaza dominios raíz si no compraste el proxy de raíz y rechaza el nombre de tu propia zona, que Cloudflare pide no crear nunca como hostname personalizado. Después muestra el registro exacto que hay que crear, con un botón para copiarlo.
• Dos estados, en lenguaje claro. El hostname y el certificado se validan por separado; muestra ambos. Convierte ssl.validation_errors en instrucciones: "Los registros CAA de tu dominio no permiten nuestra autoridad certificadora; agrega este registro" sirve más que "pending_validation". La respuesta al crearlo puede llegar sin los registros de validación; consúltalo otra vez tras unos segundos. Las notificaciones por webhook avisan de la validación y la emisión.
• Monitoreo de renovaciones. Una tarea diaria que marque los hostnames cuyo certificado no está activo o cuyo DNS ya no apunta a ti.
• Limpieza. Borra los hostnames que nunca se validan y los de clientes que se van. Ambos se cobran hasta que los borras.
• Aislamiento entre clientes. Identifica al cliente solo a partir de hostnames activos en tu base de datos. Si tus clientes también reciben subdominios de tu dominio, la documentación de Vercel advierte que una cookie que un cliente fija para el dominio padre llega a los demás; deja tu panel y tu inicio de sesión en otro dominio.
• Guía de soporte. Una página interna que diga quién corrige cada error: CNAME faltante, CAA, DNSSEC y SERVFAIL le tocan al cliente; tokens, límites de la autoridad certificadora y rutas del Worker te tocan a ti.

Es el tipo de trabajo que hacemos en Dardo en el desarrollo de software a la medida, y los portales de clientes de marca blanca son donde más se pide un dominio propio.

Alternativas: Vercel y Netlify

Si tu aplicación ya corre en otro proveedor, ambos manejan dominios de clientes con límites documentados a octubre de 2026.

La diferencia más clara es el dominio raíz: en Vercel tu cliente puede apuntar cliente.com con un registro A. Eso sí, el plan Hobby es solo para uso personal y no comercial según las reglas de Vercel, así que un SaaS que cobra empieza en Pro. La recomendación de 50 alias de Netlify lo hace poco práctico para un solo despliegue con cientos de dominios de clientes.

Cuándo construirlo

Si te lo piden dos o tres clientes, agrega sus hostnames a mano en el panel de Cloudflare y lleva una lista de verificación. Construye el flujo de autoservicio cuando el dominio propio sea parte de un plan que vendes o de una oferta de marca blanca. Si tus clientes necesitan dominios raíz o comodines a escala, habla con Cloudflare sobre Enterprise antes de diseñar alrededor de esos límites.

Si quieres ese flujo dentro de tu producto, con los estados, alertas y guías de soporte de arriba, cuéntanos de tu aplicación.