Deploy SvelteKit on Nodion

Deploy SvelteKit step by step

1. Switch from adapter-auto to adapter-node Run npm i -D @sveltejs/adapter-node, remove @sveltejs/adapter-auto and use the new adapter in your config. Nodion reads the adapter from package.json, and the config decides what the build writes, so change both. In SvelteKit 3 the config lives in the sveltekit() options in vite.config.js; on SvelteKit 2 it is kit.adapter in 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. Commit the lockfile, skip the start script Commit your lockfile; the build fails without one. Nodion runs your build script and starts node build, and adapter-node listens on the PORT that Nodion sets. A start script, if you add one, replaces that command.
3. Set the public origin Nodion terminates HTTPS in front of your app, so SvelteKit cannot tell from the request which URL your visitors use, and without it form submissions are rejected as cross-site. In SvelteKit 3, set paths.origin to your public URL as in the config above; it replaces adapter-node's ORIGIN variable. On SvelteKit 2, set ORIGIN on the Environment tab instead, for example https://shop.example.com.
4. Build-time and runtime variables Values from $env/static/private and $env/static/public are inlined during the build, so they need the Build flag on the Environment tab. $env/dynamic/private and $env/dynamic/public are read while the server runs and work with normal variables.
5. Create the app and push In the dashboard, create an application from your GitHub, GitLab, Bitbucket or Gitea repository in the region EU Central. Every push builds a new release, and traffic moves to it once / answers with a 2xx or 3xx status. If / answers 401 or 404, add a route such as src/routes/health/+server.js that returns 200 and set /health as the health check path.

Good to know

• Static sites with adapter-staticWith @sveltejs/adapter-static, Nodion serves build/ with a static web server and an index.html fallback. Prerender your pages with export const prerender = true in the root +layout.js. For a single-page app, turn off SSR there and set fallback: 'index.html' in the adapter options, because Nodion needs an index.html in build/. No Node.js server runs, so the smallest size is enough.
• Keep one adapter in package.jsonNodion checks for adapter-static first, then adapter-node. If both are installed, the app is built as a static site, so remove the adapter you do not use.

What Nodion runs for you

• Deploys without downtime Push to your branch and Nodion builds a new release. Traffic switches once the new instances answer their health check; a failed release leaves the running one in place. Apps with a local volume restart instead, because the disk belongs to one instance.
• Databases next to the app Managed PostgreSQL, pgvector, MySQL, Valkey and ClickHouse in the same region. Attached databases arrive as DATABASE_URL, REDIS_URL or CLICKHOUSE_URL.
• Previews per pull request Turn on previews and pull requests from your repository get their own app with its own URL and fresh, empty databases, created automatically or by hand. Forks and bot pull requests are skipped.
• Workers, cron jobs and scaling Run workers as extra processes of the same app, schedule jobs on the Cron tab, and scale every process to up to 16 instances.
• Release step With buildpacks, a Procfile release: line runs with every new build. Dockerfile apps, and redeploys or rollbacks to an earlier image, use a release command set on the app itself, which also takes precedence over the Procfile line. On static sites a release step runs in an image that holds only the built files.
• Logs and metrics Build, release and runtime logs plus CPU, memory, disk and network metrics for every instance in the dashboard.
• Domains and HTTPS A default hostname with HTTPS from the first deploy; your own domains get certificates automatically.

Further reading

• Preview Environments Explained: An App per Pull Request A running copy of your app for every pull request: what preview environments are good for, where they get tricky and how Nodion handles them.
• Dockerfile vs Buildpacks: Which One Should You Use? Both turn your code into a container image. What differs is who writes the build steps, and that decides control, maintenance and security updates.

SvelteKit on Nodion: questions and answers