Desplegar FrameKit

El despliegue inicial compatible de FrameKit consiste en un proceso Node.js de larga duración por contenedor, con HTTPS y limitación de solicitudes proporcionados por un proxy inverso o balanceador de carga externo. El proceso aloja Studio y el renderizado síncrono de PNG del lado del servidor; la API de acceso solo existe cuando FRAMEKIT_AUTH_ENABLED=true.

Entorno de ejecución y configuraciónNode, Chromium, variables de entorno, capacidad de renderizado y estado local del proceso.

Docker y persistenciaLa imagen independiente canónica, /data, persistencia de SQLite y comportamiento al reiniciar.

Seguridad y proxies inversosCredenciales, cookies del mismo origen, tokens Bearer, restricciones de imágenes, HTTPS y exposición pública.

Secuencia de despliegue

1. Decide el modo de acceso. El valor ausente o FRAMEKIT_AUTH_ENABLED=false activa el modo abierto; antes de exponer producción a una red no confiable, define explícitamente FRAMEKIT_AUTH_ENABLED=true.
2. En modo autenticado, establece una FRAMEKIT_ADMIN_PASSWORD segura para crear el primer usuario y mantén los secretos fuera de la imagen y del repositorio de código fuente.
3. En modo autenticado, proporciona una ubicación escribible y duradera para SQLite si los usuarios, las sesiones y los tokens de API deben sobrevivir a los reinicios.
4. Instala el navegador Chromium de Playwright y las dependencias de Linux, o usa el Dockerfile canónico que lo hace durante la compilación de la imagen.
5. Ejecuta una compilación de producción correcta con pnpm framekit build.
6. Inicia la aplicación compilada con pnpm framekit start.
7. En modo autenticado, coloca HTTPS y la limitación de solicitudes de inicio de sesión delante del proceso antes de exponerlo públicamente.

Nota

framekit start es de solo lectura con respecto al registro generado. Espera una compilación correcta y no regenera las plantillas por ti.

Límites del estado

SQLite solo se inicializa cuando la autenticación está activada y almacena los usuarios, las sesiones y los metadatos de los tokens de API. Los trabajos de renderizado son diferentes: viven en un mapa globalThis local al proceso, caducan después de 120 segundos y desaparecen cuando se reinicia el proceso. Por tanto, un volumen de SQLite duradero no hace duradero un trabajo de renderizado en curso.

El renderizador reutiliza un navegador Chromium durante toda la vida del proceso, pero proporciona a cada renderizado un contexto y una página aislados. El número de renderizados simultáneos está limitado por proceso. El tiempo de espera cancela o aborta el trabajo de renderizado; se intenta limpiar la página y el contexto en finally, y esa espera de limpieza no tiene un límite independiente documentado. La topología compatible no es una función serverless ni un conjunto de réplicas que espere compartir los trabajos de renderizado y el estado del navegador locales al proceso.