En junio, las apps que generábamos se ejecutaban en entornos de vista previa. Podía revisar una pantalla mientras el pipeline la cambiaba. Durante el desarrollo, eso era útil. Pero no metería a los clientes en ese mismo entorno.
Nos propusimos dejar la producción fuera de ese ciclo de edición y ofrecer a los proyectos un traspaso a GitHub.
En la nota de lanzamiento original describí partes de esto con demasiada seguridad. Esta revisión separa el diseño de lo que podemos verificar el 15 de octubre de 2026. La implementación y la documentación incluyen vías para el despliegue y para GitHub. Eso, por sí solo, no verifica cada despliegue real, cada cambio de dominio ni cada vuelta atrás.
La frontera con producción
La vista previa se reconstruye mientras trabajas. El diseño interpone un paso de publicación deliberado entre ese entorno cambiante y la app que usa la gente. Un despliegue de producción debería servir la versión que elegiste.
El servidor de producción está pensado para usar artefactos ya compilados, sin las herramientas de edición de la vista previa. La configuración y las credenciales de producción tienen su propio ámbito. Los usuarios finales de la app también necesitan su propia configuración de identidad, separada de las cuentas que se usan durante el desarrollo.
Guardar un ajuste por separado no demuestra que todos los caminos del código lo traten bien. Comprueba los valores de producción, las redirecciones permitidas y las reglas de acceso antes de enviarle un enlace a un cliente.
Revisa la vista previa, incluidos los permisos y los estados sin datos. Configura el entorno de producción, publica, espera a que esté listo y prueba los flujos de trabajo importantes en la app desplegada.
La guía de publicación actual describe esos pasos y las comprobaciones de capacidad de tu plan. Trata cada operación que salga bien en la interfaz como un paso de la publicación y, después, prueba el servicio resultante.
El dominio
El flujo del dominio conecta el nombre de host de una app con un dominio que controlas. Necesitas los registros DNS correspondientes y tienes que verificar la conexión.
El artículo original lo reducía a añadir un CNAME y que todo funcionara. Dejaba fuera la espera y las comprobaciones que exige un cambio de dominio.
Sigue los valores que se muestran para el despliegue. Cuando el DNS resuelva, verifica el nombre de host, el certificado y la aplicación. Vuelve a comprobar las redirecciones del inicio de sesión en la dirección pública. Que la URL de la vista previa funcione dice poco sobre esto último.
Tenemos vías implementadas para configurar dominios. Esta reescritura no deja constancia de ninguna prueba nueva de DNS o TLS en un entorno real.
El traspaso a GitHub
Quiero que un proyecto pueda seguir siendo útil fuera de la sesión que lo creó. Un repositorio da a los cambios en el código fuente un lugar donde revisarlos y mantenerlos.
La integración con GitHub tiene vías para conectar una cuenta, publicar el código e intercambiar cambios con un repositorio conectado. Así puedes revisar el código del proyecto y sus documentos de apoyo con herramientas que ya conoces.
Publicar el código en GitHub y publicar una app en funcionamiento son operaciones distintas. Un repositorio no opera una base de datos, no configura los secretos ni atiende un incidente en producción.
El diseño del historial usa una única rama principal, push corrientes y, para deshacer cambios, commits de reversión que se suman al historial. Evitamos ofrecer el force-push como una acción normal de la plataforma.
Eso reduce las formas en que nuestro propio flujo de trabajo reescribe el historial. No justifica prometer que un usuario nunca perderá código. Los permisos del repositorio, las ediciones externas y los procedimientos de recuperación siguen importando.
En octubre, la navegación por el historial y la vuelta atrás todavía tienen partes sin comprobaciones operativas recientes. Mantén tu propio plan de recuperación. No des por probada una restauración solo porque haya un botón o una vía implementada.
Credenciales y configuración
El diseño de la integración guarda las credenciales de GitHub cifradas y por proyecto, fuera del disco que contiene el proyecto de la app. La app no debería necesitar un token de acceso personal en su árbol de código fuente para que la conexión funcione.
Esa decisión de almacenamiento no demuestra que todo el despliegue haya superado una auditoría de seguridad.
Llevarse un proyecto a otro sitio exige algo más que descargar el código. Tienes que aportar la configuración de ejecución, los servicios de datos y los ajustes de identidad que espera su código. Revisa esas dependencias antes de decidir dónde alojarlo.
La documentación sobre Git y GitHub explica el flujo de trabajo con el código. El artículo sobre identidad cuenta por qué, en una aplicación, el inicio de sesión es solo una parte de los límites de acceso.
El trabajo de publicar
Para las promesas operativas sigo necesitando pruebas de que se cumplen: un despliegue completado, un dominio que funcione, una recuperación ensayada contra el servicio real. Una revisión de código no puede aportar esas pruebas.
El trabajo de junio nos dio vías para esas tareas. Poner por escrito las comprobaciones que todavía necesitan es menos satisfactorio que dar el problema por resuelto. También es más útil antes de que el primer cliente dependa de ello.
Publicado originalmente el 16 de junio de 2026. Revisado el 15 de octubre de 2026 para corregir afirmaciones absolutas sobre el despliegue y la recuperación, y para distinguir las vías implementadas de la verificación real.