Despliega Static sites and SPAs en Nodion

Despliega Static sites and SPAs paso a paso

1. Haz commit de un lockfile y un script de build Haz commit de tu lockfile; sin él, la build falla. Nodion ejecuta el script build y toma la carpeta de salida de tu framework: dist/ en Vite, build/ en Create React App, dist/<project>/browser en Angular, public/ en Gatsby y _site/ en Eleventy. package.json

   "scripts": {
     "dev": "vite",
     "build": "vite build"
   }

2. Define las variables de build Tu bundler escribe variables como VITE_*, REACT_APP_* o GATSBY_* en los archivos durante la build, así que necesitan la opción Build en la pestaña Environment. Todo lo que contienen es público: nunca pongas secretos en ellas.
3. Indica otras carpetas de salida en static.toml También funcionan otros generadores: Nodion busca un index.html en dist, build, out, .output/public, public y _site. Si el tuyo escribe en otro sitio, como hace VitePress, añade un static.toml junto al package.json. Además, hace que Nodion trate el repositorio como sitio estático cuando no lo detectaría por sí solo. fallback indica el archivo que se sirve para las rutas que no existen. static.toml

   output-dir = "docs/.vitepress/dist"
   fallback = "index.html"

4. El HTML puro no necesita build Un repositorio con un index.html en la raíz y sin package.json se sirve tal cual. Nodion excluye .git, los archivos .env y algunos archivos de claves habituales, pero considera público todo lo que incluyas en un commit y mantén los secretos fuera del repositorio.
5. Crea la app y haz push En el dashboard, crea una aplicación desde tu repositorio de GitHub, GitLab, Bitbucket o Gitea en la región EU Central y elige el tamaño más pequeño. Cada push genera una nueva release, y el tráfico pasa a ella en cuanto / responde, algo de lo que se encarga tu index.html.

A tener en cuenta

• El routing en el cliente funcionaLas rutas que no coinciden con ningún archivo reciben tu index.html, así que las rutas de React Router, Vue Router y Angular siguen funcionando al recargar la página. El fallback no se puede desactivar; fallback en static.toml solo cambia el archivo.
• Sin procesos de Procfile ni código de servidorLos procesos del Procfile no tienen efecto en un sitio estático, y solo se publica la carpeta de salida. Una línea release: se seguiría ejecutando, pero en una imagen que solo contiene los archivos compilados, así que no la uses. Si tu repositorio es un servidor Node.js con un script de build, lee la guía de Node.js para ver cómo distingue Nodion los dos casos.
• Angular SSRNodion compila los proyectos Angular como sitios estáticos, también con @angular/ssr, así que el renderizado en servidor no se ejecuta. Para SSR, usa un Dockerfile.
• Hugo y JekyllNodion no ejecuta builds de Hugo ni de Jekyll. Compila tú el sitio, haz commit de la carpeta generada (public/ o _site/) y configura Base directory de la app con esa ruta: una carpeta con un index.html y sin package.json se sirve tal cual. O compila el sitio en un Dockerfile.

Lo que Nodion gestiona por ti

• Despliegues sin downtime Haz push a tu rama y Nodion construye una nueva release. El tráfico pasa a las nuevas instancias cuando superan el health check; si una release falla, la que está en marcha sigue activa. En cambio, las apps con un volumen local se reinician porque el disco pertenece a una sola instancia.
• Bases de datos junto a la app PostgreSQL, pgvector, MySQL, Valkey y ClickHouse gestionados en la misma región. Al vincular una base de datos, sus datos de conexión llegan como DATABASE_URL, REDIS_URL o CLICKHOUSE_URL.
• Previews por pull request Activa las previews: cada pull request de tu repositorio tendrá su propia app, con URL y bases de datos nuevas y vacías. Puedes crearla automáticamente o a mano. Se omiten las pull requests de forks y bots.
• Workers, cron jobs y escalado Ejecuta workers como procesos adicionales de la misma app, programa tareas en la pestaña Cron y escala cada proceso hasta 16 instancias.
• Paso de release Con buildpacks, una línea release: del Procfile se ejecuta con cada nueva build. Las apps con Dockerfile, así como los redeploys o rollbacks a una imagen anterior, usan un comando de release definido en la propia app, que además tiene prioridad sobre la línea del Procfile. En los sitios estáticos, el paso de release se ejecuta en una imagen que solo contiene los archivos generados por la build.
• Logs y métricas Logs de build, release y runtime, además de métricas de CPU, memoria, disco y red de cada instancia, en el dashboard.
• Dominios y HTTPS Un nombre de host predeterminado con HTTPS desde el primer despliegue; tus propios dominios reciben certificados automáticamente.

Para seguir leyendo

• Entornos de preview: una app para cada pull request Una copia en ejecución de tu app para cada pull request: para qué sirven los entornos de preview, dónde se complican y cómo los gestiona Nodion.
• Cloud Native Buildpacks: qué son y cómo funcionan Los buildpacks convierten tu código fuente en una imagen de contenedor sin Dockerfile. Te explicamos qué son y cómo funcionan.

Static sites and SPAs en Nodion: preguntas y respuestas