Why does the adapter choice matter so much?

SvelteKit compiles your app differently depending on the target: adapter-node produces a standalone Node server you run yourself, adapter-vercel produces Vercel's serverless/edge function format, and adapter-static pre-renders the whole app to plain HTML/CSS/JS with no server at all. Picking the wrong one means the build either fails to deploy or loses server-side features (like server load functions) it needed.

Why does the CSP example differ per adapter?

A Content-Security-Policy is normally delivered as an HTTP response header, which requires an actual server or edge function to set it, available for the Node and Vercel adapters (via a reverse proxy/hooks.server.ts, or a vercel.json headers rule, respectively). Static hosting has no server to attach headers to, so the CSP has to be delivered via a tag in app.html instead, which is less capable (it can't set some directives like frame-ancestors reliably) but is the only option available.

What does csrf.checkOrigin do?

SvelteKit's built-in CSRF protection rejects form submissions and non-GET requests whose Origin header doesn't match the app's own origin; checkOrigin is on by default and should stay on for almost every app, it's a safety net against cross-site request forgery, and disabling it should only happen for specific, well-understood cases (like a documented public API endpoint).

Do I need vitePreprocess() even if I'm not using TypeScript or SCSS?

It's harmless to include even for plain JS/CSS projects, and needed the moment you add TypeScript, SCSS/Less, or PostCSS to any .svelte file, so most SvelteKit starter templates include it by default rather than requiring you to add it retroactively.

SvelteKit Config Generator - svelte.config.js + CSP

Overview

Introduction

SvelteKit's svelte.config.js is small, but choosing and correctly configuring the right deployment adapter, and then actually delivering a Content-Security-Policy on that target, requires knowing three quite different mechanisms depending on where the app ends up hosted.

This tool generates a working svelte.config.js for the Node, Vercel, or static adapter, plus a CSP example wired the correct way for that specific target.

What Is SvelteKit Config Generator?

A svelte.config.js generator supporting @sveltejs/adapter-node, @sveltejs/adapter-vercel, and @sveltejs/adapter-static, each with the option shape that adapter actually expects, plus a csrf.checkOrigin toggle.

Alongside the config, it produces a matching CSP delivery example: a header value plus a hooks.server.ts/reverse-proxy note for Node, a vercel.json headers rule for Vercel, or a <meta> tag for static hosting.

How SvelteKit Config Generator Works

Selecting an adapter swaps both the `import adapter from "..."` package name and the arguments passed to `adapter(...)`, matching each adapter's own documented options (e.g. static's pages/assets/fallback for SPA-style fallback routing).

The CSP example is generated as a separate, adapter-specific snippet rather than embedded in svelte.config.js itself, since CSP delivery happens at the HTTP/HTML layer, not through SvelteKit's own config file.

When To Use SvelteKit Config Generator

Use it when starting a new SvelteKit project and you already know its deployment target (a Node server, Vercel, or a static host), so the adapter and its options are correct from the first commit.

It's also useful when migrating a SvelteKit app between hosting targets and you need the config and CSP delivery mechanism updated to match.

Often used alongside Vite Config Generator and Next.js Config Generator.

Features

Advantages

Produces the correct adapter-specific options shape (e.g. static's fallback: "index.html" for SPA routing) rather than a generic adapter() call missing target-specific settings.
Delivers a CSP example through the mechanism that actually works for the chosen target, avoiding the common mistake of trying to set an HTTP header on a host with no server.
Keeps csrf.checkOrigin visible and explicit rather than buried, since it's a security-relevant default worth reviewing consciously rather than leaving implicit.

Limitations

The CSP example is a reasonable starting policy (self-only scripts/styles/images/connections); a real app's CSP often needs additional allowed sources (analytics scripts, font CDNs, image hosts) added by hand.
Covers three of SvelteKit's community adapters; other targets (Cloudflare, Netlify, deno) use different adapter packages not covered here.

Examples

Static adapter with its matching meta-tag CSP

Input

adapter: static, csrfCheckOrigin: true

Output

import adapter from "@sveltejs/adapter-static";
import { vitePreprocess } from "@sveltejs/vite-plugin-svelte";

/** @type {import('@sveltejs/kit').Config} */
const config = {
  preprocess: vitePreprocess(),
  kit: {
    adapter: adapter({ pages: "build", assets: "build", fallback: "index.html" }),
    csrf: {
      checkOrigin: true,
    },
  },
};

export default config;

The static adapter's fallback: "index.html" option enables SPA-style client-side routing for paths not pre-rendered at build time.

Best Practices & Notes

Best Practices

Leave csrf.checkOrigin enabled unless you have a specific, well-understood reason to disable it (like a documented cross-origin API endpoint), since it's SvelteKit's main built-in CSRF defense.
Test the generated CSP in report-only mode first (Content-Security-Policy-Report-Only) before enforcing it, so you catch legitimate resources it would otherwise block.
Re-generate this config (and re-check the CSP delivery mechanism) whenever you change deployment targets, since the adapter and CSP approach are both target-specific.

Developer Notes

Each adapter's options object matches that package's actual documented API: adapter-node's `out` sets the build output directory for the resulting standalone Node server, adapter-static's `pages`/`assets`/`fallback` control pre-rendering output and enable SPA-style fallback routing for client-only routes, and adapter-vercel typically needs no required options for a standard deployment. The CSP examples intentionally use a conservative, mostly self-only policy as a safe starting point, since a CSP that's too permissive from the start defeats its own purpose, and it's much easier to loosen a strict policy incrementally than to tighten a loose one after launch.

SvelteKit Config Generator Use Cases

Bootstrapping svelte.config.js for a new SvelteKit project on a known deployment target
Migrating an existing SvelteKit app's adapter and CSP delivery mechanism between hosting platforms
Adding a first Content-Security-Policy to a SvelteKit app in a way that actually works for its host

Common Mistakes

Trying to set a Content-Security-Policy HTTP header on a statically hosted SvelteKit app, which has no server available to send response headers at all.
Disabling csrf.checkOrigin broadly to work around a specific cross-origin request, instead of scoping that exception narrowly and leaving the default protection on elsewhere.

Tips

Use the Vite Config Generator's alias/proxy patterns as a reference if you need additional Vite-level customization beyond what svelte.config.js's preprocess/kit options cover.

SvelteKit Config Generator