Resumen

  • Fastly permite administrar un dominio sin vincular cada modificación a una nueva versión del servicio. El nombre público y el desarrollo pueden gestionarse por separado.
  • Un cambio de operador exige repartir la autoridad sobre DNS, certificados, cuentas y reglas de encaminamiento; recibir el código no resuelve por sí solo ese reparto.
  • La delegación entre cuentas tiene requisitos y excepciones. No acredita la propiedad jurídica del dominio ni demuestra que trasladar el sitio a otro proveedor resulte sencillo.

La parte de la web que no aparece en la entrega

Supongamos que una empresa encarga a una nueva agencia una parte de su sitio, mientras otra sigue operando el resto. La entrega del código está acordada y ambas colaboran. El público, en cambio, continuará utilizando la misma dirección. ¿Quién decidirá qué solicitudes llegan a cada equipo cuando termine el traspaso?

El supuesto no describe un conflicto de un cliente de Fastly. Sirve para examinar una relación de compra: la empresa contrata trabajo sobre una aplicación, pero necesita conservar la capacidad de asignar ese trabajo a otros. Cuando la dirección pública y la gestión cotidiana quedan confundidas en un solo encargo, esa capacidad puede depender de accesos que nadie incluyó en la entrega.

Fastly hace visible la distinción con sus dominios sin versión. Se administran fuera de una versión concreta del servicio. Pueden incorporarse antes de asociarlos a un servicio y modificarse sin incrementar su versión. Por tanto, preparar el nombre y publicar una aplicación dejan de ser necesariamente una única secuencia de trabajo.

Es una mejora útil para organizar equipos. La administración del dominio puede avanzar mientras se termina el servicio que lo atenderá, y no todas las tareas sobre el nombre requieren otra publicación de la aplicación. Pero también obliga a precisar qué se está comprando: una versión entregada no incluye automáticamente toda la autoridad que sitúa esa versión delante de los usuarios.

Una dirección puede repartir el trabajo

La cuestión se vuelve especialmente clara cuando hay más de un servicio detrás del mismo dominio. Las reglas de encaminamiento de Fastly permiten distribuir solicitudes entre servicios Fastly según rutas y condiciones, sin escribir VCL o código Compute para esa capa. El nombre público puede mantenerse mientras cambian los destinos internos.

En una renovación por etapas, por ejemplo, distintas partes de un sitio podrían quedar a cargo de servicios diferentes. Es una ilustración de la capacidad documentada, no un despliegue observado. La ventaja consiste en disponer de otra manera de repartir trabajo. La consecuencia contractual es que las reglas de reparto también deben tener un responsable cuando se cambia de agencia.

La documentación exige un dominio en Domain Management, un certificado TLS válido y un servicio activo. Es obligatoria una regla predeterminada. Además, la configuración debe estar desplegada y vinculada al dominio: una configuración ya desplegada comienza a dirigir tráfico cuando se establece ese vínculo. La autoridad sobre la asociación tiene, por ello, un alcance distinto de la autoridad sobre el código de destino.

Si la recepción del proyecto solo revisa repositorios, puede pasar por alto quién sigue decidiendo qué solicitudes llegan a la aplicación recibida. No hace falta un desacuerdo entre proveedores para que aparezca ese vacío. Basta con que los equipos organicen sus obligaciones por aplicación, mientras una regla compartida organiza el tráfico por dirección y ruta.

Esta flexibilidad tampoco equivale a una salida hacia otra red de distribución. Las reglas descritas reparten solicitudes entre servicios dentro de Fastly. Resultan valiosas para una reorganización interna, pero no acreditan por sí mismas la portabilidad del conjunto hacia otro proveedor.

La cuenta de destino importa tanto como el servicio

Fastly distingue los dominios sin versión de los clásicos, que forman parte de la configuración y las versiones de un servicio. Cambiar la asociación de un dominio clásico requiere crear una versión nueva. La función clásica está limitada a cuentas creadas antes del 16 de septiembre de 2025; para delegar a otra cuenta un dominio clásico utilizado en una cuenta diferente hay que recurrir al soporte.

Para los dominios sin versión se documenta una vía de delegación autónoma hacia otra cuenta o cliente. Una opción de prueba consiste en obtener un certificado gestionado por Fastly mediante validación DNS y configurar un token DNS. Otra se basa en aportar un certificado válido de una autoridad pública de confianza y su clave privada correspondiente. Son requisitos del producto, no una invitación a circular claves de producción entre contratistas.

El manual de gestión de dominios introduce una excepción que compras no debería perder de vista: los clientes de Platform TLS disponen de acceso de solo lectura a Unified Domain Management y deben contactar con soporte para gestionar dominios o migrar. La autonomía descrita para una modalidad no está garantizada para todas.

Así, el cambio comercial no es que cualquier entrega pueda ejecutarse sin intermediarios. Es que ciertas cuentas, con las pruebas y permisos adecuados, cuentan con una vía adicional para reorganizar la administración. Si el cliente conserva esos medios, puede preparar la entrada del siguiente operador. Si los dejó enteramente en manos de la agencia saliente, una función de autoservicio no se los devuelve de forma automática.

Los documentos públicos no establecen un plazo medio de traspaso, una tarifa ni un ahorro atribuible a esta función. La conclusión es más limitada: separar nombre y versión puede facilitar la sustitución de una relación operativa. El resultado depende de cómo se hayan distribuido los requisitos para autorizarla.

Preparar la entrada antes de cambiar el tráfico

La posibilidad de adelantar trabajo tiene una expresión concreta en los certificados gestionados. Fastly explica en su guía de certificados que la validación ACME por DNS, utilizada por defecto, dirige hacia Fastly únicamente el subdominio de comprobación. Esto permite preparar TLS antes de mover el tráfico de producción.

La validación por HTTP tiene otra consecuencia: encamina el tráfico de inmediato. La propia guía advierte de que una configuración incompleta de TLS o del servicio puede mostrar avisos de seguridad o dejar el sitio inaccesible. Para una empresa que contrata el relevo, no es una mera preferencia técnica. Determina si el trabajo pendiente sigue siendo una tarea de preparación o si sus efectos alcanzan ya al público.

Poder adelantar la comprobación ofrece margen para detectar una autorización ausente antes de la fecha comercial. La nueva agencia puede descubrir qué depende todavía de terceros cuando la anterior continúa atendiendo solicitudes. No hay una promesa de migración sin interrupciones: el servicio receptor y su comportamiento siguen siendo condiciones necesarias. Se gana la posibilidad de ordenar las dependencias, no de ignorarlas.

Tampoco basta con haber conseguido el primer certificado. Los cambios DNS y las restricciones CAA pueden impedir renovaciones. La API de suscripciones TLS contempla estados de emisión, renovación y reintento; que se siga intentando emitir no prolonga la validez de un certificado vencido. El nuevo reparto de responsabilidades debe sostener los requisitos que seguirán existiendo después del traspaso.

La guía distingue incluso entre dejar de servir TLS y dejar de renovar: desactivar todas las activaciones no detiene por sí solo la renovación gestionada, mientras que eliminar la suscripción es otra acción. No son pasos que aquí se proponga ejecutar. La diferencia muestra por qué una entrega debe describir las obligaciones continuas, en lugar de tratar todo el ciclo del certificado como un único interruptor.

Acreditar control no es transferir propiedad

La API de gestión de dominios refleja varias relaciones separadas. Un dominio puede estar verificado mediante la prueba de certificado admitida; su activación indica que existe al menos una activación TLS. La asociación a un servicio y a una configuración de encaminamiento son campos distintos y pueden estar vacíos.

Esas condiciones no resuelven la titularidad jurídica de un nombre registrado, ni la propiedad de una marca o una empresa. Del mismo modo, una activación TLS no prueba que cada función del negocio alcance la aplicación adecuada. Conviene que la recepción del proyecto diga a cuál de esas capacidades se refiere, sin convertirlas todas en una etiqueta de «dominio transferido».

Con los certificados autogestionados, la apariencia de un archivo transferible puede ocultar lo que falta. La guía de certificados propios exige un certificado válido y la clave correspondiente, además de configuración TLS, activaciones y DNS adecuados. Que un certificado cubra varios nombres no significa que todos los dominios previstos hayan sido activados explícitamente de forma automática.

Su renovación sigue siendo responsabilidad del cliente. Una agencia puede recibir archivos y, aun así, no haber recibido una obligación clara de vigilar y mantener la próxima renovación. Los prerrequisitos TLS añaden condiciones de cuenta y permisos. Transmitir instrucciones no transmite por sí mismo la autoridad para llevarlas a cabo.

No se desprende de ello que el cliente tenga que ejecutar cada tarea. Puede contratar especialistas para hacerlo. Lo que necesita preservar es una forma practicable de asignar esas tareas a otra parte y saber qué obligaciones no viajan simplemente con la aplicación.

Cuatro cambios, cuatro alcances

Reasociar un servicio dentro de una cuenta, delegar entre cuentas Fastly, mover tráfico a un proveedor distinto y cambiar de propietario jurídico son operaciones diferentes. Las dos primeras reorganizan trabajo dentro de la plataforma. La tercera requiere también una infraestructura receptora, sus certificados y sus condiciones de funcionamiento. La cuarta no se decide mediante la prueba técnica que pide Fastly.

En la configuración descrita por su guía de encaminamiento de tráfico, Fastly no ofrece DNS gestionado. El cliente elige al proveedor DNS e instala los registros indicados. Existe, por tanto, un ámbito de administración exterior al despliegue de la aplicación. Que el cliente pueda utilizarlo depende de su organización de cuentas y personas, no solo de la arquitectura del producto.

Los registros conservados en caché también condicionan el movimiento de tráfico; no desaparecen cuando se firma el acta de entrega. Por otra parte, modificar una asociación entre dominio y servicio en Fastly no implica haber ejecutado una migración DNS pública. Confundir esas acciones puede llevar a exagerar lo fácil que resulta salir del proveedor y, a la vez, a restar importancia a un cambio dentro de él.

La actividad tiene una escala que justifica prestar atención a sus pequeñas decisiones administrativas. Fastly declaró en sus resultados del segundo trimestre de 2026 ingresos de 183,3 millones de dólares, de los cuales 133,9 millones correspondían a Network Services. Son cifras publicadas por la compañía sobre su negocio, no una medición de la adopción de dominios sin versión ni de sus beneficios económicos.

La pregunta útil para el comprador sigue siendo más concreta: ¿puede encargar a otra parte la operación detrás de su dirección conocida sin reconstruir primero su propia capacidad para autorizar el relevo? Fastly permite separar el dominio de una versión. La empresa debe completar esa separación en las responsabilidades que compra, conserva y entrega.