Despliega SvelteKit en Nodion

Despliega SvelteKit paso a paso

1. Cambia de adapter-auto a adapter-node Ejecuta npm i -D @sveltejs/adapter-node, quita @sveltejs/adapter-auto y usa el nuevo adapter en tu configuración. Nodion lee el adapter del package.json, y la configuración decide lo que genera la build, así que cambia ambos. En SvelteKit 3, la configuración está en las opciones de sveltekit() en vite.config.js; en SvelteKit 2 es kit.adapter en svelte.config.js. vite.config.js (SvelteKit 3)

   import adapter from "@sveltejs/adapter-node";
   import { sveltekit } from "@sveltejs/kit/vite";
   import { defineConfig } from "vite";
   
   export default defineConfig({
     plugins: [
       sveltekit({
         adapter: adapter(),
         paths: { origin: "https://shop.example.com" },
       }),
     ],
   });

2. Haz commit del lockfile y omite el script start Haz commit de tu lockfile; sin él, la build falla. Nodion ejecuta tu script build y arranca node build, y adapter-node escucha en el PORT que define Nodion. Si añades un script start, sustituye ese comando.
3. Define el origen público Nodion termina HTTPS delante de tu app, así que SvelteKit no puede saber por la petición qué URL usan tus visitantes, y sin ella rechaza los envíos de formularios como cross-site. En SvelteKit 3, define paths.origin con tu URL pública, como en la configuración de arriba; sustituye a la variable ORIGIN de adapter-node. En SvelteKit 2, define en su lugar ORIGIN en la pestaña Environment, por ejemplo https://shop.example.com.
4. Variables de build y de tiempo de ejecución Los valores de $env/static/private y $env/static/public se insertan en el código durante la build, así que necesitan la opción Build en la pestaña Environment. $env/dynamic/private y $env/dynamic/public se leen mientras el servidor está en marcha y funcionan con variables normales.
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. Cada push genera una nueva release, y el tráfico pasa a ella en cuanto / responde con un estado 2xx o 3xx. Si / responde 401 o 404, añade una ruta como src/routes/health/+server.js que devuelva 200 y define /health como ruta de health check.

A tener en cuenta

• Sitios estáticos con adapter-staticCon @sveltejs/adapter-static, Nodion sirve build/ con un servidor web estático y fallback a index.html. Prerenderiza tus páginas con export const prerender = true en el +layout.js raíz. Para una SPA, desactiva ahí el SSR y define fallback: 'index.html' en las opciones del adapter, porque Nodion necesita un index.html en build/. No se ejecuta ningún servidor Node.js, así que basta con el tamaño más pequeño.
• Un solo adapter en el package.jsonNodion busca primero adapter-static y después adapter-node. Si están instalados los dos, la app se compila como sitio estático, así que quita el adapter que no uses.

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.
• Dockerfile vs buildpacks: ¿cuál deberías usar? Los dos convierten tu código en una imagen de contenedor. Lo que cambia es quién escribe los pasos de la build, y eso decide el control, el mantenimiento y las actualizaciones de seguridad.

SvelteKit en Nodion: preguntas y respuestas