Deploy SvelteKit with adapter-node: build, port and domain

SvelteKit does not produce the same artifact with every adapter. For an app that must respond on the server, @sveltejs/adapter-node creates a standalone Node server. If every route can be generated ahead of time, adapter-static publishes files; auto depends on the target platform and is not a universal format for every host.

This guide focuses on adapter-node and the checks for deploying your Git project through Projects. Review current plans and limits to confirm that the required resources and persistent process fit.

Check routes before choosing an adapter

Identify pages using +page.server, +server, server hooks, sessions or data that changes with each request. Those routes need a production runtime. SvelteKit’s adapter documentation explains that each adapter prepares the app for a different target; its adapter-node guide covers the Node server.

If every page can be prerendered, compare adapter-static and verify its route and fallback requirements. Do not remove hooks or endpoints just to make the project compile if the app relies on them.

Configure the Node output

Install the adapter as a development dependency. In SvelteKit 3 (and versions 2.62 or later), configure it in the SvelteKit plugin inside vite.config.js; this is the current setup used by the tested minimal project:

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

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

Older projects may configure the adapter in svelte.config.js; check the installed version and follow its official migration guide before moving configuration.

Use the repository’s lockfile and existing build script. For an npm project, the usual sequence is:

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

The adapter creates build/, and the server accepts HOST and PORT. Locally check the home page, dynamic routes, endpoints and a missing URL. If there is a proxy in front, set the public origin or forwarded headers consistently with the deployment; an incorrect external URL can affect redirects and absolute links.

Protect variables and deploy from Git

SvelteKit does not make every environment variable public by default: check which imports your code uses. Variables from $env/static/public or $env/dynamic/public go to the browser; do not put secrets there. Keep private credentials in the service configuration.

In Projects, connect the repository, select the branch and review the Node runtime, install/build steps and node build start command. If the selected plan or project detection cannot run that process as configured, use the container workflow documented for the chosen offer. Do not assume a development build or npm run preview is the production server.

Test first on the temporary domain: server rendering, direct navigation, forms, sign-in, API calls, assets, logs and process restarts. Connect the final domain after these checks pass, then verify HTTPS and any callback URLs. If your app only serves prerendered files, compare the operating cost with Sites before keeping a server running.

Local test (9 October 2026): a minimal SvelteKit 3.0.1 project with adapter-node 6.0.0 passed svelte-check with no errors or warnings and built with npm run build; HOST=127.0.0.1 PORT=3000 node build served the home page with HTTP 200 and a missing route with HTTP 404. This sample was not deployed to a Projects account.

Sources: SvelteKit adapters, adapter-node, environment variables, SvelteKit 3 migration and Projects.