Publica un sitio estático con Pages

Opfield Pages publica un sitio estático como un artefacto inmutable con un puntero de promoción explícito. Un Deployment es un conjunto fijo de archivos; un Tag es un nombre que se puede mover, como production; una Route envía un dominio público a ese Tag. Esta separación permite a un equipo revisar una versión y revertirla moviendo un puntero en lugar de cambiar archivos en su sitio.

Pages es para salida estática: HTML, JavaScript, CSS, imágenes, fuentes y otros archivos que sirve nginx. No proporciona un entorno de ejecución de aplicaciones del lado del servidor. Se puede usar un framework durante el build, pero su salida debe ser un artefacto estático adecuado para el directorio de artefactos configurado.

El sitio principal de Opfield y este portal de documentación funcionan en Opfield Pages, con los mismos despliegues, Tags, Routes y reversión que se describen aquí.

Empieza por la visión general de Pages. Para la entrega desde Git, prepara los despliegues de Pages desde Git y una integración de control de código fuente. Un dominio personalizado también requiere el camino de dominio, Route y TLS.

Define el contrato de versión

Antes de crear el proyecto, decide:

• qué nodo Ingress o ubicación es responsable de los archivos estáticos;
• quién puede subir o construir despliegues;
• qué Tag representa la producción y quién puede moverlo;
• qué dominio, certificado y Route publican el Tag;
• si los cambios en el código desencadenan builds automáticos o despliegues automáticos;
• qué valores de ejecución visibles para el cliente están permitidos;
• los requisitos de retención de las vistas previas y de los despliegues de reversión.

El proyecto es responsable del historial de despliegues, los Tags, la configuración de ejecución, las Routes y el comportamiento de retención. El repositorio de código, cuando se usa, es responsable del código fuente, pero no es responsable directo de la Route pública.

Prepara el artefacto estático

Construye el sitio en un entorno limpio y confirma que el directorio de salida contiene los documentos de entrada y todos los recursos referenciados. Prueba el enrutamiento del lado del cliente y las rutas base con un servidor estático, no con un servidor de desarrollo. Los servidores de desarrollo pueden ocultar archivos que faltan, renderizado exclusivo del servidor o URL de recursos incorrectas.

No incluyas source maps, fixtures de pruebas, archivos de entorno, metadatos privados del repositorio, credenciales, topología interna ni cachés de build salvo que sean públicos intencionadamente. Todo lo que hay dentro de un artefacto de Pages debe tratarse como contenido público descargable, aunque la interfaz no enlace a un archivo.

Camino con artefacto manual

1. Activa Pages en los ajustes de funciones y confirma que el plan actual permite gestionar Pages.
2. Crea un Pages Project y selecciona un nodo Ingress compatible.
3. Configura las cuotas, la retención y el acceso del proyecto antes de subir un artefacto de producción.
4. Sube el artefacto preparado a través de la consola, de la API de despliegue reanudable o del enlace de subida de MCP remoto autenticado. Un artefacto puede ser tan grande como el File upload limit, 100 MB por defecto y como máximo 500 MB; consulta la visión general de Pages.
5. Finaliza la subida. Opfield valida y crea un despliegue inmutable nuevo en lugar de modificar uno anterior.
6. Abre la vista previa inmutable y verifica el artefacto exacto.
7. Mueve el Tag latest gestionado por el sistema o un Tag de versión personalizado a ese despliegue solo tras la aprobación.
8. Crea o actualiza una Route de Pages para el dominio público y el Tag seleccionado.

Una subida interrumpida no es una versión. Reanuda o reinicia la subida mediante el flujo de trabajo compatible y finalízala una vez; no copies a mano archivos parciales en un nodo Ingress.

Camino con build desde Git

En Business y Enterprise, conecta al Pages Project un repositorio de GitLab, GitHub o Git genérico que esté en la lista de permitidos. Selecciona la rama y la raíz de la aplicación, deja que Opfield descubra package.json cuando corresponda y configura el gestor de paquetes, la versión de Node, el script de build y el directorio del artefacto.

El build se ejecuta en un Build Worker aislado. Añade Build Secrets limitados al origen solo para el acceso durante el build; no deben emitirse en la salida estática. Revisa el commit exacto, los logs, el resultado de vulnerabilidades o de políticas cuando esté disponible, el worker y el artefacto producido antes de publicar.

Mantén separados el build automático y el despliegue automático. El build automático puede preparar un candidato de vista previa en cada evento de código aprobado. El despliegue automático mueve un Tag y cambia lo que sirve una Route; actívalo solo cuando las protecciones de rama y las comprobaciones de aceptación sean lo bastante sólidas para ese riesgo.

Configuración de ejecución

Pages puede servir configuración de ejecución visible para el cliente desde /_opfield/pages/config.js como window.runtime.config. El valor es público, está limitado a 64 KiB y se sirve con no-store. Un objeto Default se aplica de forma general, y las sustituciones de objeto completo por Tag pueden reemplazarlo para un Tag enrutado. Las vistas previas inmutables usan Default.

Usa la configuración de ejecución para valores no secretos que varíen legítimamente según el entorno, como los orígenes de API públicos, la presentación de funciones o los identificadores de analítica. No pongas nunca en ella contraseñas, claves de API, endpoints privados, material de firma, datos exclusivos de clientes ni topología de red.

Cambiar la configuración de ejecución no crea un despliegue nuevo ni cambia el hash del artefacto. Mantén la configuración compatible con versiones anteriores mientras un Tag pueda moverse entre versiones antiguas y nuevas.

Publica el dominio

Crea o selecciona el dominio y el certificado y crea después una Route de Pages que apunte al proyecto y al Tag elegidos. Las Routes apuntan a Tags, no a despliegues en bruto. Así, la promoción y la reversión siguen siendo explícitas y quedan registradas.

Verifica el DNS, TLS, el documento de entrada devuelto, los recursos anidados, la navegación del lado del cliente, el comportamiento de la caché, window.runtime.config y las páginas de error. Prueba desde una sesión de navegador limpia y desde una red externa. Una vista previa inmutable demuestra el artefacto; la Route pública demuestra además el DNS, TLS, la selección del Tag y la materialización en Ingress.

Criterios de éxito

• El despliegue de Pages está Ready y tiene una vista previa inmutable.
• El Tag previsto apunta al despliegue revisado.
• La Route pública sirve ese Tag con un TLS de confianza.
• Los recursos estáticos y las rutas del lado del cliente funcionan desde URL de entrada directas.
• No hay ningún secreto ni archivo solo interno en el artefacto ni en la configuración de ejecución.
• El registro del commit y del build del despliegue es visible cuando se usa la entrega desde Git.
• Sigue disponible un despliegue anterior que se sabe que funciona para la reversión.

Reversión y limpieza

Para revertir, mueve el Tag público al despliegue verificado anterior. Después vuelve a probar la Route, los recursos, la configuración de ejecución y el comportamiento en el navegador. No edites ni sustituyas en su sitio el despliegue fallido; su registro inmutable es útil para el diagnóstico y demuestra lo que realmente se publicó.

Eliminar un despliegue puede eliminar un destino de reversión. Revisa primero las referencias de los Tags y los requisitos de retención. Eliminar un Tag o una Route cambia la accesibilidad, pero no altera el artefacto inmutable. Desactiva Pages de forma global solo con una decisión de producto explícita; desactivar la navegación no sustituye a retirar las Routes públicas y conservar las pruebas necesarias.

Mapa de diagnóstico

Síntoma	Comprueba primero	Guía detallada
La subida se interrumpió	Estado de la subida y Task; no copies archivos parciales a mano	Tasks, eventos y auditoría
El build desde Git falló	Ajustes de origen, Build Worker, logs y decisión de la política	Despliegues de Pages desde Git
La vista previa funciona, pero la Route pública falla	Tag, dominio, DNS, TLS y ubicación en Ingress	Solución de problemas del tráfico entrante
Una URL directa devuelve 404	Documento de entrada, ruta base y enrutamiento del lado del cliente	Despliegues de Pages desde Git
La configuración de ejecución es incorrecta	Default, sustitución de objeto completo por Tag y compatibilidad de versiones	Visión general de Pages
No queda ningún destino de reversión	Referencias de los Tags y retención de los despliegues	Visión general de Pages