Adapters and Deployment

A finished SvelteKit build isn't automatically ready to run anywhere — a Node server, a serverless platform, and a static file host all expect different output shapes. Adapters are the plugin that produces the right shape for wherever you're deploying, configured in svelte.config.js.

Why adapters exist

Without an adapter layer, SvelteKit would need built-in special cases for every possible host. Instead, the framework produces an internal, portable representation of your app, and an adapter's only job is translating that into what a specific platform expects — a server.js entry point for Node, a set of edge functions for Cloudflare, or a folder of static HTML for any plain file host.

adapter-auto: the default

// svelte.config.js
import adapter from '@sveltejs/adapter-auto';

export default {
  kit: { adapter: adapter() }
};

adapter-auto detects common platforms (Vercel, Netlify, Cloudflare Pages, Azure) from environment variables set during their build process and delegates to the matching platform-specific adapter automatically. It's a good default while developing, but once you know your target host, switch to that adapter explicitly — adapter-auto doesn't expose every platform-specific configuration option, and pinning a real adapter makes your build reproducible outside that platform's own CI too.

adapter-node: your own server

npm install -D @sveltejs/adapter-node

// svelte.config.js
import adapter from '@sveltejs/adapter-node';

export default {
  kit: { adapter: adapter() }
};

Building with adapter-node produces a standalone Node.js server in build/, run with node build. Use this when you're deploying to a VM, a container, or any environment where you manage the Node process yourself — it needs a persistent server, unlike the serverless adapters below.

adapter-static: no server at all

npm install -D @sveltejs/adapter-static

// svelte.config.js
import adapter from '@sveltejs/adapter-static';

export default {
  kit: {
    adapter: adapter(),
    prerender: { entries: ['*'] }
  }
};

This produces a plain folder of static files — the entire app must be prerenderable (see the previous lesson), since there's no server to run load per request at all. It's the right choice for a fully static site: a blog, documentation, a marketing site with no personalized or per-request content anywhere.

Platform-specific adapters

@sveltejs/adapter-vercel, @sveltejs/adapter-netlify, and others target a specific platform's serverless or edge runtime directly, exposing platform-specific options adapter-auto doesn't — for example, configuring individual routes to run on the edge versus a regional serverless function.

// svelte.config.js
import adapter from '@sveltejs/adapter-vercel';

export default {
  kit: {
    adapter: adapter({ runtime: 'nodejs20.x' })
  }
};

Choosing an adapter

Ask two questions: does any route need per-request server logic (a database call in load, a form action, an authenticated dashboard)? If no, adapter-static is simplest and cheapest to host. If yes, do you control the runtime yourself, or are you deploying to a specific managed platform? Self-managed points to adapter-node; a managed platform points to that platform's own adapter, for access to its specific features (edge functions, image optimization, and so on) beyond what the generic Node build provides.

Switching adapters later is usually just a config and dependency change — the routing, load functions, and components you've written don't need to change, because they were never written against a specific host to begin with.