Overview
How to configure SvelteKit for Production
SvelteKit differs from other meta-frameworks because of its Adapter architecture. Instead of building a universal server, SvelteKit compiles your app specifically for your deployment target via svelte.config.js.
Best Practices
- What are Adapters?: Adapters take the built SvelteKit app and package it for a specific environment. `adapter-node` creates a standalone Express-like Node server. `adapter-static` pre-renders your entire site to pure HTML files. `adapter-auto` tries to guess your environment (Vercel, Netlify, Cloudflare), but specifying an adapter explicitly is best practice.
- SSR vs. Prerendering vs. SPA: SvelteKit gives you atomic control over rendering. You can export `ssr = false` in your root layout to create a Single Page Application (like Create React App). You can export `prerender = true` to generate static HTML at build time. Or keep both on (the default) for dynamic Server-Side Rendering.
Security Recommendations
- Content Security Policy (CSP): SvelteKit has built-in support for generating strict CSPs without needing a separate reverse proxy. By enabling CSP in your `svelte.config.js`, SvelteKit will automatically inject the necessary meta tags or HTTP headers to prevent XSS attacks.
- Environment Variables: Variables prefixed with `PUBLIC_` (e.g. `PUBLIC_API_URL`) are safe and exposed to the browser. Any other variables are strictly server-side only. Do not prefix database secrets!
Frequently Asked Questions
Why does my static build fail?
If you use `adapter-static` but have dynamic routes (e.g., `[id].svelte`) that SvelteKit doesn't know about, the build will fail. You must export `prerender = true` and ensure all dynamic paths are crawled or explicitly provided in the config.
How do I configure Vite with SvelteKit?
Vite configuration lives in `vite.config.ts`, not `svelte.config.js`. SvelteKit uses both files. `svelte.config.js` handles framework-specific routing and adapters, while `vite.config.ts` handles asset bundling and dev servers.
Should I disable SSR?
Only if you are building an admin dashboard, internal tool, or application behind a login wall where SEO does not matter. For public-facing marketing sites or blogs, you should always leave SSR enabled.