Configuration

Whether to use hashes or nonces to restrict <script> and <style> elements. 'auto' will use hashes for prerendered pages, and nonces for dynamically rendered pages.

Directives that will be added to Content-Security-Policy headers.

Directives that will be added to Content-Security-Policy-Report-Only headers.

Whether to check the incoming origin header for POST, PUT, PATCH, or DELETE form submissions and verify that it matches the server's origin.

To allow people to make POST, PUT, PATCH, or DELETE requests with a Content-Type of application/x-www-form-urlencoded, multipart/form-data, or text/plain to your app from other origins, you will need to disable this option. Be careful!

The directory to search for .env files.

A prefix that signals that an environment variable is safe to expose to client-side code. See $env/static/public and $env/dynamic/public. Note that Vite's envPrefix must be set separately if you are using Vite's environment variable handling - though use of that feature should generally be unnecessary.

A prefix that signals that an environment variable is unsafe to expose to client-side code. Environment variables matching neither the public nor the private prefix will be discarded completely. See $env/static/private and $env/dynamic/private.

a place to put static files that should have stable URLs and undergo no processing, such as favicon.ico or manifest.json

your app's internal library, accessible throughout the codebase as $lib

a directory containing parameter matchers

the files that define the structure of your app (see Routing)

the location of your service worker's entry point (see Service workers)

the location of the template for HTML responses

the location of the template for fallback error responses

Whether to generate import maps. This will result in better long term cacheability, as changes to a single module will no longer invalidate all its dependents. However, it will increase the size of the HTML document, and force modulepreload links to be part of the document rather than being added as HTTP headers.

SvelteKit will preload the JavaScript modules needed for the initial page to avoid import 'waterfalls', resulting in faster application startup. There are three strategies with different trade-offs:

• modulepreload - uses <link rel="modulepreload">. This delivers the best results in Chromium-based browsers, in Firefox 115+, and Safari 17+. It is ignored in older browsers.
• preload-js - uses <link rel="preload">. Prevents waterfalls in Chromium and Safari, but Chromium will parse each module twice (once as a script, once as a module). Causes modules to be requested twice in Firefox. This is a good setting if you want to maximise performance for users on iOS devices at the cost of a very slight degradation for Chromium users.
• preload-mjs - uses <link rel="preload"> but with the .mjs extension which prevents double-parsing in Chromium. Some static webservers will fail to serve .mjs files with a Content-Type: application/javascript header, which will cause your application to break. If that doesn't apply to you, this is the option that will deliver the best performance for the largest number of users, until modulepreload is more widely supported.

An absolute path that your app's files are served from. This is useful if your files are served from a storage bucket of some kind.

A root-relative path that must start, but not end with / (e.g. /base-path), unless it is the empty string. This specifies where your app is served from and allows the app to live on a non-root path. Note that you need to prepend all your root-relative links with the base value or they will point to the root of your domain, not your base (this is how the browser works). You can use base from $app/paths for that: <a href="{base}/your-page">Link</a>. If you find yourself writing this often, it may make sense to extract this into a reusable component.

Whether to use relative asset paths.

If true, base and assets imported from $app/paths will be replaced with relative asset paths during server-side rendering, resulting in more portable HTML. If false, %sveltekit.assets% and references to build artifacts will always be root-relative paths, unless paths.assets is an external URL

Single-page app fallback pages will always use absolute paths, regardless of this setting.

If your app uses a <base> element, you should set this to false, otherwise asset URLs will incorrectly be resolved against the <base> URL rather than the current page.

In 1.0, undefined was a valid value, which was set by default. In that case, if paths.assets was not external, SvelteKit would replace %sveltekit.assets% with a relative path and use relative paths to reference build artifacts, but base and assets imported from $app/paths would be as specified in your config.

How many pages can be prerendered simultaneously. JS is single-threaded, but in cases where prerendering performance is network-bound (for example loading content from a remote CMS) this can speed things up by processing other tasks while waiting on the network response.

Whether SvelteKit should find pages to prerender by following links from entries.

An array of pages to prerender, or start crawling from (if crawl: true). The * string includes all routes containing no required [parameters] with optional parameters included as being empty (since SvelteKit doesn't know what value any parameters should have).

How to respond to HTTP errors encountered while prerendering the app.

• 'fail' — fail the build
• 'ignore' - silently ignore the failure and continue
• 'warn' — continue, but print a warning
• (details) => void — a custom error handler that takes a details object with status, path, referrer, referenceType and message properties. If you throw from this function, the build will fail

ts
/** @type {import('@sveltejs/kit').Config} */
const config = {
	kit: {
		prerender: {
			handleHttpError: ({ path, referrer, message }) => {
				// ignore deliberate link to shiny 404 page
				if (path === '/not-found' && referrer === '/blog/how-we-built-our-404-page') {
					return;
				}

				// otherwise fail the build
				throw new Error(message);
			}
		}
	}
};

How to respond when hash links from one prerendered page to another don't correspond to an id on the destination page.

• 'fail' — fail the build
• 'ignore' - silently ignore the failure and continue
• 'warn' — continue, but print a warning
• (details) => void — a custom error handler that takes a details object with path, id, referrers and message properties. If you throw from this function, the build will fail

How to respond when an entry generated by the entries export doesn't match the route it was generated from.

• 'fail' — fail the build
• 'ignore' - silently ignore the failure and continue
• 'warn' — continue, but print a warning
• (details) => void — a custom error handler that takes a details object with generatedFromId, entry, matchedId and message properties. If you throw from this function, the build will fail

The value of url.origin during prerendering; useful if it is included in rendered content.

Whether to automatically register the service worker, if it exists.

Determine which files in your static directory will be available in $service-worker.files.

A function that allows you to edit the generated tsconfig.json. You can mutate the config (recommended) or return a new one. This is useful for extending a shared tsconfig.json in a monorepo root, for example.

The current app version string. If specified, this must be deterministic (e.g. a commit ref rather than Math.random() or Date.now().toString()), otherwise defaults to a timestamp of the build.

For example, to use the current commit hash, you could do use git rev-parse HEAD:

ts
import * as child_process from 'node:child_process';

export default {
	kit: {
		version: {
			name: child_process.execSync('git rev-parse HEAD').toString().trim()
		}
	}
};

The interval in milliseconds to poll for version changes. If this is 0, no polling occurs.