Publicar SvelteKit con adapter-node: build, puerto y dominio

SvelteKit no genera el mismo tipo de artefacto con todos sus adaptadores. Si una app debe responder en servidor, @sveltejs/adapter-node crea un servidor Node autónomo. Si cada ruta se puede generar de antemano, adapter-static publica archivos; el modo auto depende de la plataforma de destino y no es un formato universal para cualquier host.

Esta guía se centra en adapter-node y en los controles para desplegar una aplicación propia desde Git mediante Projects. Revisa el plan y los límites vigentes para confirmar que encajan los recursos y el proceso persistente.

Comprueba las rutas antes de elegir adaptador

Identifica páginas que usan +page.server, +server, hooks de servidor, sesiones o datos que cambian en cada petición. Esas rutas necesitan un runtime en producción. La documentación de adaptadores de SvelteKit explica que cada adaptador prepara la app para un destino distinto; la guía de adapter-node cubre el servidor Node.

Si todas las páginas pueden prerenderizarse, compara adapter-static y verifica sus requisitos de rutas y fallback. No borres hooks o endpoints para conseguir que compile si forman parte de la app.

Configura la salida Node

Instala el adaptador como dependencia de desarrollo. En SvelteKit 3 (y versiones 2.62 o posteriores), configura el adaptador en el plugin de SvelteKit dentro de vite.config.js; esta es la forma vigente que usa el proyecto mínimo probado:

import adapter from '@sveltejs/adapter-node';
import { sveltekit } from '@sveltejs/kit/vite';
import { defineConfig } from 'vite';

export default defineConfig({
  plugins: [sveltekit({ adapter: adapter() })]
});

Los proyectos anteriores pueden tener el adaptador en svelte.config.js; comprueba la versión instalada y sigue su guía oficial de migración antes de mover configuración.

Usa el lockfile del repo y el script de build que ya tenga. En un proyecto npm, la secuencia típica es:

npm ci
npm run build
HOST=127.0.0.1 PORT=3000 node build

El adaptador crea build/ y el servidor acepta HOST y PORT. En local comprueba la portada, rutas dinámicas, endpoints y una URL inexistente. Si hay un proxy delante, configura el origen público o las cabeceras reenviadas de forma coherente con el despliegue; una URL externa incorrecta puede afectar redirecciones y enlaces absolutos.

Protege las variables y publica desde Git

SvelteKit no convierte toda variable de entorno en pública por sí sola: revisa qué imports usa el código. Las variables de $env/static/public o $env/dynamic/public se entregan al navegador; no pongas ahí secretos. Guarda credenciales privadas en la configuración del servicio.

En Projects conecta el repositorio, selecciona rama y revisa el runtime Node, la orden de instalación/build y el comando node build. Si el plan o la detección del proyecto no permiten ese proceso tal cual, utiliza el flujo de contenedores documentado para la oferta elegida. No des por hecho que una compilación de desarrollo o npm run preview equivale al servidor de producción.

Prueba primero en el dominio temporal: renderizado de servidor, navegación directa, formularios, login, llamadas a APIs, assets, logs y reinicio del proceso. Conecta el dominio final después de pasar esas comprobaciones y valida HTTPS y cualquier URL de callback. Si tu app solo sirve ficheros prerenderizados, compara el coste operativo con Sites antes de mantener un servidor activo.

Prueba local (9 de octubre de 2026): un proyecto mínimo de SvelteKit 3.0.1 con adapter-node 6.0.0 pasó svelte-check sin errores ni warnings y compiló con npm run build; HOST=127.0.0.1 PORT=3000 node build sirvió la portada con HTTP 200 y una ruta inexistente con HTTP 404. No se ha publicado esta muestra en una cuenta de Projects.

Fuentes: adaptadores SvelteKit, adapter-node, variables de entorno, migración a SvelteKit 3 y Projects.