# Table of Contents

- [Introduction • Docs • Svelte](#introduction-docs-svelte)
- [Creating a project • Docs • Svelte](#creating-a-project-docs-svelte)
- [Project structure • Docs • Svelte](#project-structure-docs-svelte)
- [Web standards • Docs • Svelte](#web-standards-docs-svelte)
- [Adapters • Docs • Svelte](#adapters-docs-svelte)
- [Page options • Docs • Svelte](#page-options-docs-svelte)
- [State management • Docs • Svelte](#state-management-docs-svelte)
- [Zero-config deployments • Docs • Svelte](#zero-config-deployments-docs-svelte)
- [Building your app • Docs • Svelte](#building-your-app-docs-svelte)
- [Routing • Docs • Svelte](#routing-docs-svelte)
- [Static site generation • Docs • Svelte](#static-site-generation-docs-svelte)
- [Single-page apps • Docs • Svelte](#single-page-apps-docs-svelte)
- [Cloudflare Pages • Docs • Svelte](#cloudflare-pages-docs-svelte)

---

# Introduction • Docs • Svelte

[Skip to main content](#main)

Before we begin[](#Before-we-begin)

------------------------------------

> If you’re new to Svelte or SvelteKit we recommend checking out the [interactive tutorial](/tutorial/kit)
> .
> 
> If you get stuck, reach out for help in the [Discord chatroom](/chat)
> .

What is SvelteKit?[](#What-is-SvelteKit)

-----------------------------------------

SvelteKit is a framework for rapidly developing robust, performant web applications using [Svelte](../svelte)
. If you’re coming from React, SvelteKit is similar to Next. If you’re coming from Vue, SvelteKit is similar to Nuxt.

To learn more about the kinds of applications you can build with SvelteKit, see the [FAQ](faq#What-can-I-make-with-SvelteKit)
.

What is Svelte?[](#What-is-Svelte)

-----------------------------------

In short, Svelte is a way of writing user interface components — like a navigation bar, comment section, or contact form — that users see and interact with in their browsers. The Svelte compiler converts your components to JavaScript that can be run to render the HTML for the page and to CSS that styles the page. You don’t need to know Svelte to understand the rest of this guide, but it will help. If you’d like to learn more, check out [the Svelte tutorial](/tutorial)
.

SvelteKit vs Svelte[](#SvelteKit-vs-Svelte)

--------------------------------------------

Svelte renders UI components. You can compose these components and render an entire page with just Svelte, but you need more than just Svelte to write an entire app.

SvelteKit helps you build web apps while following modern best practices and providing solutions to common development challenges. It offers everything from basic functionalities — like a [router](glossary#Routing)
 that updates your UI when a link is clicked — to more advanced capabilities. Its extensive list of features includes [build optimizations](https://vitejs.dev/guide/features.html#build-optimizations)
 to load only the minimal required code; [offline support](service-workers)
; [preloading](link-options#data-sveltekit-preload-data)
 pages before user navigation; [configurable rendering](page-options)
 to handle different parts of your app on the server via [SSR](glossary#SSR)
, in the browser through [client-side rendering](glossary#CSR)
, or at build-time with [prerendering](glossary#Prerendering)
; [image optimization](images)
; and much more. Building an app with all the modern best practices is fiendishly complicated, but SvelteKit does all the boring stuff for you so that you can get on with the creative part.

It reflects changes to your code in the browser instantly to provide a lightning-fast and feature-rich development experience by leveraging [Vite](https://vitejs.dev/)
 with a [Svelte plugin](https://github.com/sveltejs/vite-plugin-svelte)
 to do [Hot Module Replacement (HMR)](https://github.com/sveltejs/vite-plugin-svelte/blob/main/docs/config.md#hot)
.

[Edit this page on GitHub](https://github.com/sveltejs/kit/edit/main/documentation/docs/10-getting-started/10-introduction.md)

previous next

[Creating a project](/docs/kit/creating-a-project)

---

# Creating a project • Docs • Svelte

[Skip to main content](#main)

The easiest way to start building a SvelteKit app is to run `npx sv create`:

    npx sv create my-app
    cd my-app
    npm install
    npm run dev

The first command will scaffold a new project in the `my-app` directory asking you if you’d like to set up some basic tooling such as TypeScript. See [integrations](./integrations)
 for pointers on setting up additional tooling. The subsequent commands will then install its dependencies and start a server on [localhost:5173](http://localhost:5173)
.

There are two basic concepts:

*   Each page of your app is a [Svelte](../svelte)
     component
*   You create pages by adding files to the `src/routes` directory of your project. These will be server-rendered so that a user’s first visit to your app is as fast as possible, then a client-side app takes over

Try editing the files to get a feel for how everything works.

Editor setup[](#Editor-setup)

------------------------------

We recommend using [Visual Studio Code (aka VS Code)](https://code.visualstudio.com/download)
 with [the Svelte extension](https://marketplace.visualstudio.com/items?itemName=svelte.svelte-vscode)
, but [support also exists for numerous other editors](https://sveltesociety.dev/resources#editor-support)
.

[Edit this page on GitHub](https://github.com/sveltejs/kit/edit/main/documentation/docs/10-getting-started/20-creating-a-project.md)

previous next

[Introduction](/docs/kit/introduction)
 [Project structure](/docs/kit/project-structure)

---

# Project structure • Docs • Svelte

[Skip to main content](#main)

A typical SvelteKit project looks like this:

    my-project/
    ├ src/
    │ ├ lib/
    │ │ ├ server/
    │ │ │ └ [your server-only lib files]
    │ │ └ [your lib files]
    │ ├ params/
    │ │ └ [your param matchers]
    │ ├ routes/
    │ │ └ [your routes]
    │ ├ app.html
    │ ├ error.html
    │ ├ hooks.client.js
    │ ├ hooks.server.js
    │ └ service-worker.js
    ├ static/
    │ └ [your static assets]
    ├ tests/
    │ └ [your tests]
    ├ package.json
    ├ svelte.config.js
    ├ tsconfig.json
    └ vite.config.js

You’ll also find common files like `.gitignore` and `.npmrc` (and `.prettierrc` and `eslint.config.js` and so on, if you chose those options when running `npx sv create`).

Project files[](#Project-files)

--------------------------------

### src[](#Project-files-src)

The `src` directory contains the meat of your project. Everything except `src/routes` and `src/app.html` is optional.

*   `lib` contains your library code (utilities and components), which can be imported via the [`$lib`]($lib)
     alias, or packaged up for distribution using [`svelte-package`](packaging)
    *   `server` contains your server-only library code. It can be imported by using the [`$lib/server`](server-only-modules)
         alias. SvelteKit will prevent you from importing these in client code.
*   `params` contains any [param matchers](advanced-routing#Matching)
     your app needs
*   `routes` contains the [routes](routing)
     of your application. You can also colocate other components that are only used within a single route here
*   `app.html` is your page template — an HTML document containing the following placeholders:
    *   `%sveltekit.head%` — `<link>` and `<script>` elements needed by the app, plus any `<svelte:head>` content
    *   `%sveltekit.body%` — the markup for a rendered page. This should live inside a `<div>` or other element, rather than directly inside `<body>`, to prevent bugs caused by browser extensions injecting elements that are then destroyed by the hydration process. SvelteKit will warn you in development if this is not the case
    *   `%sveltekit.assets%` — either [`paths.assets`](configuration#paths)
        , if specified, or a relative path to [`paths.base`](configuration#paths)
        
    *   `%sveltekit.nonce%` — a [CSP](configuration#csp)
         nonce for manually included links and scripts, if used
    *   `%sveltekit.env.[NAME]%` - this will be replaced at render time with the `[NAME]` environment variable, which must begin with the [`publicPrefix`](configuration#env)
         (usually `PUBLIC_`). It will fallback to `''` if not matched.
*   `error.html` is the page that is rendered when everything else fails. It can contain the following placeholders:
    *   `%sveltekit.status%` — the HTTP status
    *   `%sveltekit.error.message%` — the error message
*   `hooks.client.js` contains your client [hooks](hooks)
    
*   `hooks.server.js` contains your server [hooks](hooks)
    
*   `service-worker.js` contains your [service worker](service-workers)
    

(Whether the project contains `.js` or `.ts` files depends on whether you opt to use TypeScript when you create your project. You can switch between JavaScript and TypeScript in the documentation using the toggle at the bottom of this page.)

If you added [Vitest](https://vitest.dev)
 when you set up your project, your unit tests will live in the `src` directory with a `.test.js` extension.

### static[](#Project-files-static)

Any static assets that should be served as-is, like `robots.txt` or `favicon.png`, go in here.

### tests[](#Project-files-tests)

If you added [Playwright](https://playwright.dev/)
 for browser testing when you set up your project, the tests will live in this directory.

### package.json[](#Project-files-package.json)

Your `package.json` file must include `@sveltejs/kit`, `svelte` and `vite` as `devDependencies`.

When you create a project with `npx sv create`, you’ll also notice that `package.json` includes `"type": "module"`. This means that `.js` files are interpreted as native JavaScript modules with `import` and `export` keywords. Legacy CommonJS files need a `.cjs` file extension.

### svelte.config.js[](#Project-files-svelte.config.js)

This file contains your Svelte and SvelteKit [configuration](configuration)
.

### tsconfig.json[](#Project-files-tsconfig.json)

This file (or `jsconfig.json`, if you prefer type-checked `.js` files over `.ts` files) configures TypeScript, if you added typechecking during `npx sv create`. Since SvelteKit relies on certain configuration being set a specific way, it generates its own `.svelte-kit/tsconfig.json` file which your own config `extends`.

### vite.config.js[](#Project-files-vite.config.js)

A SvelteKit project is really just a [Vite](https://vitejs.dev)
 project that uses the [`@sveltejs/kit/vite`](@sveltejs-kit-vite)
 plugin, along with any other [Vite configuration](https://vitejs.dev/config/)
.

Other files[](#Other-files)

----------------------------

### .svelte-kit[](#Other-files-.svelte-kit)

As you develop and build your project, SvelteKit will generate files in a `.svelte-kit` directory (configurable as [`outDir`](configuration#outDir)
). You can ignore its contents, and delete them at any time (they will be regenerated when you next `dev` or `build`).

[Edit this page on GitHub](https://github.com/sveltejs/kit/edit/main/documentation/docs/10-getting-started/30-project-structure.md)

previous next

[Creating a project](/docs/kit/creating-a-project)
 [Web standards](/docs/kit/web-standards)

---

# Web standards • Docs • Svelte

[Skip to main content](#main)

Throughout this documentation, you’ll see references to the standard [Web APIs](https://developer.mozilla.org/en-US/docs/Web/API)
 that SvelteKit builds on top of. Rather than reinventing the wheel, we _use the platform_, which means your existing web development skills are applicable to SvelteKit. Conversely, time spent learning SvelteKit will help you be a better web developer elsewhere.

These APIs are available in all modern browsers and in many non-browser environments like Cloudflare Workers, Deno, and Vercel Functions. During development, and in [adapters](adapters)
 for Node-based environments (including AWS Lambda), they’re made available via polyfills where necessary (for now, that is — Node is rapidly adding support for more web standards).

In particular, you’ll get comfortable with the following:

Fetch APIs[](#Fetch-APIs)

--------------------------

SvelteKit uses [`fetch`](https://developer.mozilla.org/en-US/docs/Web/API/fetch)
 for getting data from the network. It’s available in [hooks](hooks)
 and [server routes](routing#server)
 as well as in the browser.

> A special version of `fetch` is available in [`load`](load)
>  functions, [server hooks](hooks#Server-hooks)
>  and [API routes](routing#server)
>  for invoking endpoints directly during server-side rendering, without making an HTTP call, while preserving credentials. (To make credentialled fetches in server-side code outside `load`, you must explicitly pass `cookie` and/or `authorization` headers.) It also allows you to make relative requests, whereas server-side `fetch` normally requires a fully qualified URL.

Besides `fetch` itself, the [Fetch API](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API)
 includes the following interfaces:

### Request[](#Fetch-APIs-Request)

An instance of [`Request`](https://developer.mozilla.org/en-US/docs/Web/API/Request)
 is accessible in [hooks](hooks)
 and [server routes](routing#server)
 as `event.request`. It contains useful methods like `request.json()` and `request.formData()` for getting data that was posted to an endpoint.

### Response[](#Fetch-APIs-Response)

An instance of [`Response`](https://developer.mozilla.org/en-US/docs/Web/API/Response)
 is returned from `await fetch(...)` and handlers in `+server.js` files. Fundamentally, a SvelteKit app is a machine for turning a `Request` into a `Response`.

### Headers[](#Fetch-APIs-Headers)

The [`Headers`](https://developer.mozilla.org/en-US/docs/Web/API/Headers)
 interface allows you to read incoming `request.headers` and set outgoing `response.headers`. For example, you can get the `request.headers` as shown below, and use the [`json` convenience function](@sveltejs-kit#json)
 to send modified `response.headers`:

src/routes/what-is-my-user-agent/+server

    import { function json(data: any, init?: ResponseInit | undefined): ResponseCreate a JSON Response object from the supplied data.
    @paramdata The value that will be serialized as JSON.@paraminit Options such as status and headers that will be added to the response. Content-Type: application/json and Content-Length headers will be added automatically.json } from '@sveltejs/kit';
    
    /** @type {import('./$types').RequestHandler} */
    export function function GET({ request }: {
        request: any;
    }): Response@type{import('./$types').RequestHandler}GET({ request: anyrequest }) {
    	// log all headers
    	var console: ConsoleThe console module provides a simple debugging console that is similar to the
    JavaScript console mechanism provided by web browsers.
    The module exports two specific components:
    
    A Console class with methods such as console.log(), console.error() and console.warn() that can be used to write to any Node.js stream.
    A global console instance configured to write to process.stdout and
    process.stderr. The global console can be used without calling require('console').
    
    Warning: The global console object’s methods are neither consistently
    synchronous like the browser APIs they resemble, nor are they consistently
    asynchronous like all other Node.js streams. See the note on process I/O for
    more information.
    Example using the global console:
    console.log('hello world');
    // Prints: hello world, to stdout
    console.log('hello %s', 'world');
    // Prints: hello world, to stdout
    console.error(new Error('Whoops, something bad happened'));
    // Prints error message and stack trace to stderr:
    //   Error: Whoops, something bad happened
    //     at [eval]:5:15
    //     at Script.runInThisContext (node:vm:132:18)
    //     at Object.runInThisContext (node:vm:309:38)
    //     at node:internal/process/execution:77:19
    //     at [eval]-wrapper:6:22
    //     at evalScript (node:internal/process/execution:76:60)
    //     at node:internal/main/eval_string:23:3
    
    const name = 'Will Robinson';
    console.warn(`Danger ${name}! Danger!`);
    // Prints: Danger Will Robinson! Danger!, to stderrExample using the Console class:
    const out = getStreamSomehow();
    const err = getStreamSomehow();
    const myConsole = new console.Console(out, err);
    
    myConsole.log('hello world');
    // Prints: hello world, to out
    myConsole.log('hello %s', 'world');
    // Prints: hello world, to out
    myConsole.error(new Error('Whoops, something bad happened'));
    // Prints: [Error: Whoops, something bad happened], to err
    
    const name = 'Will Robinson';
    myConsole.warn(`Danger ${name}! Danger!`);
    // Prints: Danger Will Robinson! Danger!, to err@seesourceconsole.Console.log(message?: any, ...optionalParams: any[]): void (+1 overload)Prints to stdout with newline. Multiple arguments can be passed, with the
    first used as the primary message and all additional used as substitution
    values similar to printf(3)
    (the arguments are all passed to util.format()).
    const count = 5;
    console.log('count: %d', count);
    // Prints: count: 5, to stdout
    console.log('count:', count);
    // Prints: count: 5, to stdoutSee util.format() for more information.
    @sincev0.1.100log(...request: anyrequest.headers);
    
    	// create a JSON Response using a header we received
    	return function json(data: any, init?: ResponseInit | undefined): ResponseCreate a JSON Response object from the supplied data.
    @paramdata The value that will be serialized as JSON.@paraminit Options such as status and headers that will be added to the response. Content-Type: application/json and Content-Length headers will be added automatically.json({
    		// retrieve a specific header
    		userAgent: anyuserAgent: request: anyrequest.headers.get('user-agent')
    	}, {
    		// set a header on the response
    		ResponseInit.headers?: HeadersInit | undefinedheaders: { 'x-custom-header': 'potato' }
    	});
    }

    import { function json(data: any, init?: ResponseInit | undefined): ResponseCreate a JSON Response object from the supplied data.
    @paramdata The value that will be serialized as JSON.@paraminit Options such as status and headers that will be added to the response. Content-Type: application/json and Content-Length headers will be added automatically.json } from '@sveltejs/kit';
    import type { type RequestHandler = (event: Kit.RequestEvent<Record<string, any>, string | null>) => MaybePromise<Response>
    type RequestHandler = (event: Kit.RequestEvent<Record<string, any>, string | null>) => MaybePromise<Response>RequestHandler } from './$types';
    
    export const const GET: RequestHandlerGET: type RequestHandler = (event: Kit.RequestEvent<Record<string, any>, string | null>) => MaybePromise<Response>
    type RequestHandler = (event: Kit.RequestEvent<Record<string, any>, string | null>) => MaybePromise<Response>RequestHandler = ({ request: RequestThe original request object
    request }) => {
    	// log all headers
    	var console: ConsoleThe console module provides a simple debugging console that is similar to the
    JavaScript console mechanism provided by web browsers.
    The module exports two specific components:
    
    A Console class with methods such as console.log(), console.error() and console.warn() that can be used to write to any Node.js stream.
    A global console instance configured to write to process.stdout and
    process.stderr. The global console can be used without calling require('console').
    
    Warning: The global console object’s methods are neither consistently
    synchronous like the browser APIs they resemble, nor are they consistently
    asynchronous like all other Node.js streams. See the note on process I/O for
    more information.
    Example using the global console:
    console.log('hello world');
    // Prints: hello world, to stdout
    console.log('hello %s', 'world');
    // Prints: hello world, to stdout
    console.error(new Error('Whoops, something bad happened'));
    // Prints error message and stack trace to stderr:
    //   Error: Whoops, something bad happened
    //     at [eval]:5:15
    //     at Script.runInThisContext (node:vm:132:18)
    //     at Object.runInThisContext (node:vm:309:38)
    //     at node:internal/process/execution:77:19
    //     at [eval]-wrapper:6:22
    //     at evalScript (node:internal/process/execution:76:60)
    //     at node:internal/main/eval_string:23:3
    
    const name = 'Will Robinson';
    console.warn(`Danger ${name}! Danger!`);
    // Prints: Danger Will Robinson! Danger!, to stderrExample using the Console class:
    const out = getStreamSomehow();
    const err = getStreamSomehow();
    const myConsole = new console.Console(out, err);
    
    myConsole.log('hello world');
    // Prints: hello world, to out
    myConsole.log('hello %s', 'world');
    // Prints: hello world, to out
    myConsole.error(new Error('Whoops, something bad happened'));
    // Prints: [Error: Whoops, something bad happened], to err
    
    const name = 'Will Robinson';
    myConsole.warn(`Danger ${name}! Danger!`);
    // Prints: Danger Will Robinson! Danger!, to err@seesourceconsole.Console.log(message?: any, ...optionalParams: any[]): void (+1 overload)Prints to stdout with newline. Multiple arguments can be passed, with the
    first used as the primary message and all additional used as substitution
    values similar to printf(3)
    (the arguments are all passed to util.format()).
    const count = 5;
    console.log('count: %d', count);
    // Prints: count: 5, to stdout
    console.log('count:', count);
    // Prints: count: 5, to stdoutSee util.format() for more information.
    @sincev0.1.100log(...request: RequestThe original request object
    request.Request.headers: HeadersReturns a Headers object consisting of the headers associated with request. Note that headers added in the network layer by the user agent will not be accounted for in this object, e.g., the “Host” header.
    MDN Reference
    headers);
    
    	// create a JSON Response using a header we received
    	return function json(data: any, init?: ResponseInit | undefined): ResponseCreate a JSON Response object from the supplied data.
    @paramdata The value that will be serialized as JSON.@paraminit Options such as status and headers that will be added to the response. Content-Type: application/json and Content-Length headers will be added automatically.json({
    		// retrieve a specific header
    		userAgent: string | nulluserAgent: request: RequestThe original request object
    request.Request.headers: HeadersReturns a Headers object consisting of the headers associated with request. Note that headers added in the network layer by the user agent will not be accounted for in this object, e.g., the “Host” header.
    MDN Reference
    headers.Headers.get(name: string): string | nullMDN Reference
    get('user-agent')
    	}, {
    		// set a header on the response
    		ResponseInit.headers?: HeadersInit | undefinedheaders: { 'x-custom-header': 'potato' }
    	});
    };

FormData[](#FormData)

----------------------

When dealing with HTML native form submissions you’ll be working with [`FormData`](https://developer.mozilla.org/en-US/docs/Web/API/FormData)
 objects.

src/routes/hello/+server

    import { function json(data: any, init?: ResponseInit | undefined): ResponseCreate a JSON Response object from the supplied data.
    @paramdata The value that will be serialized as JSON.@paraminit Options such as status and headers that will be added to the response. Content-Type: application/json and Content-Length headers will be added automatically.json } from '@sveltejs/kit';
    
    /** @type {import('./$types').RequestHandler} */
    export async function function POST(event: any): Promise<Response>@type{import('./$types').RequestHandler}POST(event: anyevent) {
    	const const body: anybody = await event: anyevent.request.formData();
    
    	// log all fields
    	var console: ConsoleThe console module provides a simple debugging console that is similar to the
    JavaScript console mechanism provided by web browsers.
    The module exports two specific components:
    
    A Console class with methods such as console.log(), console.error() and console.warn() that can be used to write to any Node.js stream.
    A global console instance configured to write to process.stdout and
    process.stderr. The global console can be used without calling require('console').
    
    Warning: The global console object’s methods are neither consistently
    synchronous like the browser APIs they resemble, nor are they consistently
    asynchronous like all other Node.js streams. See the note on process I/O for
    more information.
    Example using the global console:
    console.log('hello world');
    // Prints: hello world, to stdout
    console.log('hello %s', 'world');
    // Prints: hello world, to stdout
    console.error(new Error('Whoops, something bad happened'));
    // Prints error message and stack trace to stderr:
    //   Error: Whoops, something bad happened
    //     at [eval]:5:15
    //     at Script.runInThisContext (node:vm:132:18)
    //     at Object.runInThisContext (node:vm:309:38)
    //     at node:internal/process/execution:77:19
    //     at [eval]-wrapper:6:22
    //     at evalScript (node:internal/process/execution:76:60)
    //     at node:internal/main/eval_string:23:3
    
    const name = 'Will Robinson';
    console.warn(`Danger ${name}! Danger!`);
    // Prints: Danger Will Robinson! Danger!, to stderrExample using the Console class:
    const out = getStreamSomehow();
    const err = getStreamSomehow();
    const myConsole = new console.Console(out, err);
    
    myConsole.log('hello world');
    // Prints: hello world, to out
    myConsole.log('hello %s', 'world');
    // Prints: hello world, to out
    myConsole.error(new Error('Whoops, something bad happened'));
    // Prints: [Error: Whoops, something bad happened], to err
    
    const name = 'Will Robinson';
    myConsole.warn(`Danger ${name}! Danger!`);
    // Prints: Danger Will Robinson! Danger!, to err@seesourceconsole.Console.log(message?: any, ...optionalParams: any[]): void (+1 overload)Prints to stdout with newline. Multiple arguments can be passed, with the
    first used as the primary message and all additional used as substitution
    values similar to printf(3)
    (the arguments are all passed to util.format()).
    const count = 5;
    console.log('count: %d', count);
    // Prints: count: 5, to stdout
    console.log('count:', count);
    // Prints: count: 5, to stdoutSee util.format() for more information.
    @sincev0.1.100log([...const body: anybody]);
    
    	return function json(data: any, init?: ResponseInit | undefined): ResponseCreate a JSON Response object from the supplied data.
    @paramdata The value that will be serialized as JSON.@paraminit Options such as status and headers that will be added to the response. Content-Type: application/json and Content-Length headers will be added automatically.json({
    		// get a specific field's value
    		name: anyname: const body: anybody.get('name') ?? 'world'
    	});
    }

    import { function json(data: any, init?: ResponseInit | undefined): ResponseCreate a JSON Response object from the supplied data.
    @paramdata The value that will be serialized as JSON.@paraminit Options such as status and headers that will be added to the response. Content-Type: application/json and Content-Length headers will be added automatically.json } from '@sveltejs/kit';
    import type { type RequestHandler = (event: Kit.RequestEvent<Record<string, any>, string | null>) => MaybePromise<Response>
    type RequestHandler = (event: Kit.RequestEvent<Record<string, any>, string | null>) => MaybePromise<Response>RequestHandler } from './$types';
    
    export const const POST: RequestHandlerPOST: type RequestHandler = (event: Kit.RequestEvent<Record<string, any>, string | null>) => MaybePromise<Response>
    type RequestHandler = (event: Kit.RequestEvent<Record<string, any>, string | null>) => MaybePromise<Response>RequestHandler = async (event: Kit.RequestEvent<Record<string, any>, string | null>event) => {
    	const const body: FormDatabody = await event: Kit.RequestEvent<Record<string, any>, string | null>event.RequestEvent<Record<string, any>, string | null>.request: RequestThe original request object
    request.Body.formData(): Promise<FormData>MDN Reference
    formData();
    
    	// log all fields
    	var console: ConsoleThe console module provides a simple debugging console that is similar to the
    JavaScript console mechanism provided by web browsers.
    The module exports two specific components:
    
    A Console class with methods such as console.log(), console.error() and console.warn() that can be used to write to any Node.js stream.
    A global console instance configured to write to process.stdout and
    process.stderr. The global console can be used without calling require('console').
    
    Warning: The global console object’s methods are neither consistently
    synchronous like the browser APIs they resemble, nor are they consistently
    asynchronous like all other Node.js streams. See the note on process I/O for
    more information.
    Example using the global console:
    console.log('hello world');
    // Prints: hello world, to stdout
    console.log('hello %s', 'world');
    // Prints: hello world, to stdout
    console.error(new Error('Whoops, something bad happened'));
    // Prints error message and stack trace to stderr:
    //   Error: Whoops, something bad happened
    //     at [eval]:5:15
    //     at Script.runInThisContext (node:vm:132:18)
    //     at Object.runInThisContext (node:vm:309:38)
    //     at node:internal/process/execution:77:19
    //     at [eval]-wrapper:6:22
    //     at evalScript (node:internal/process/execution:76:60)
    //     at node:internal/main/eval_string:23:3
    
    const name = 'Will Robinson';
    console.warn(`Danger ${name}! Danger!`);
    // Prints: Danger Will Robinson! Danger!, to stderrExample using the Console class:
    const out = getStreamSomehow();
    const err = getStreamSomehow();
    const myConsole = new console.Console(out, err);
    
    myConsole.log('hello world');
    // Prints: hello world, to out
    myConsole.log('hello %s', 'world');
    // Prints: hello world, to out
    myConsole.error(new Error('Whoops, something bad happened'));
    // Prints: [Error: Whoops, something bad happened], to err
    
    const name = 'Will Robinson';
    myConsole.warn(`Danger ${name}! Danger!`);
    // Prints: Danger Will Robinson! Danger!, to err@seesourceconsole.Console.log(message?: any, ...optionalParams: any[]): void (+1 overload)Prints to stdout with newline. Multiple arguments can be passed, with the
    first used as the primary message and all additional used as substitution
    values similar to printf(3)
    (the arguments are all passed to util.format()).
    const count = 5;
    console.log('count: %d', count);
    // Prints: count: 5, to stdout
    console.log('count:', count);
    // Prints: count: 5, to stdoutSee util.format() for more information.
    @sincev0.1.100log([...const body: FormDatabody]);
    
    	return function json(data: any, init?: ResponseInit | undefined): ResponseCreate a JSON Response object from the supplied data.
    @paramdata The value that will be serialized as JSON.@paraminit Options such as status and headers that will be added to the response. Content-Type: application/json and Content-Length headers will be added automatically.json({
    		// get a specific field's value
    		name: FormDataEntryValuename: const body: FormDatabody.FormData.get(name: string): FormDataEntryValue | nullMDN Reference
    get('name') ?? 'world'
    	});
    };

Stream APIs[](#Stream-APIs)

----------------------------

Most of the time, your endpoints will return complete data, as in the `userAgent` example above. Sometimes, you may need to return a response that’s too large to fit in memory in one go, or is delivered in chunks, and for this the platform provides [streams](https://developer.mozilla.org/en-US/docs/Web/API/Streams_API)
 — [ReadableStream](https://developer.mozilla.org/en-US/docs/Web/API/ReadableStream)
, [WritableStream](https://developer.mozilla.org/en-US/docs/Web/API/WritableStream)
 and [TransformStream](https://developer.mozilla.org/en-US/docs/Web/API/TransformStream)
.

URL APIs[](#URL-APIs)

----------------------

URLs are represented by the [`URL`](https://developer.mozilla.org/en-US/docs/Web/API/URL)
 interface, which includes useful properties like `origin` and `pathname` (and, in the browser, `hash`). This interface shows up in various places — `event.url` in [hooks](hooks)
 and [server routes](routing#server)
, [`page.url`]($app-state)
 in [pages](routing#page)
, `from` and `to` in [`beforeNavigate` and `afterNavigate`]($app-navigation)
 and so on.

### URLSearchParams[](#URL-APIs-URLSearchParams)

Wherever you encounter a URL, you can access query parameters via `url.searchParams`, which is an instance of [`URLSearchParams`](https://developer.mozilla.org/en-US/docs/Web/API/URLSearchParams)
:

    const const foo: string | nullfoo = const url: URLurl.URL.searchParams: URLSearchParamsMDN Reference
    searchParams.URLSearchParams.get(name: string): string | nullReturns the first value associated to the given search parameter.
    MDN Reference
    get('foo');

Web Crypto[](#Web-Crypto)

--------------------------

The [Web Crypto API](https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_API)
 is made available via the `crypto` global. It’s used internally for [Content Security Policy](configuration#csp)
 headers, but you can also use it for things like generating UUIDs:

    const const uuid: `${string}-${string}-${string}-${string}-${string}`uuid = var crypto: CryptoMDN Reference
    crypto.Crypto.randomUUID(): `${string}-${string}-${string}-${string}-${string}`Available only in secure contexts.
    MDN Reference
    randomUUID();

[Edit this page on GitHub](https://github.com/sveltejs/kit/edit/main/documentation/docs/10-getting-started/40-web-standards.md)

previous next

[Project structure](/docs/kit/project-structure)
 [Routing](/docs/kit/routing)

---

# Adapters • Docs • Svelte

[Skip to main content](#main)

Before you can deploy your SvelteKit app, you need to _adapt_ it for your deployment target. Adapters are small plugins that take the built app as input and generate output for deployment.

Official adapters exist for a variety of platforms — these are documented on the following pages:

*   [`@sveltejs/adapter-cloudflare`](adapter-cloudflare)
     for Cloudflare Pages
*   [`@sveltejs/adapter-cloudflare-workers`](adapter-cloudflare-workers)
     for Cloudflare Workers
*   [`@sveltejs/adapter-netlify`](adapter-netlify)
     for Netlify
*   [`@sveltejs/adapter-node`](adapter-node)
     for Node servers
*   [`@sveltejs/adapter-static`](adapter-static)
     for static site generation (SSG)
*   [`@sveltejs/adapter-vercel`](adapter-vercel)
     for Vercel

Additional [community-provided adapters](https://sveltesociety.dev/packages?category=sveltekit-adapters)
 exist for other platforms.

Using adapters[](#Using-adapters)

----------------------------------

Your adapter is specified in `svelte.config.js`:

svelte.config

    import const adapter: (opts: any) => import("@sveltejs/kit").Adapteradapter from 'svelte-adapter-foo';
    
    /** @type {import('@sveltejs/kit').Config} */
    const const config: Config@type{import('@sveltejs/kit').Config}config = {
    	Config.kit?: KitConfig | undefinedSvelteKit options
    kit: {
    		KitConfig.adapter?: Adapter | undefinedYour adapter is run when executing vite build. It determines how the output is converted for different platforms.
    @defaultundefinedadapter: function adapter(opts: any): import("@sveltejs/kit").Adapteradapter({
    			// adapter options go here
    		})
    	}
    };
    
    export default const config: Config@type{import('@sveltejs/kit').Config}config;

Platform-specific context[](#Platform-specific-context)

--------------------------------------------------------

Some adapters may have access to additional information about the request. For example, Cloudflare Workers can access an `env` object containing KV namespaces etc. This can be passed to the `RequestEvent` used in [hooks](hooks)
 and [server routes](routing#server)
 as the `platform` property — consult each adapter’s documentation to learn more.

[Edit this page on GitHub](https://github.com/sveltejs/kit/edit/main/documentation/docs/25-build-and-deploy/20-adapters.md)

previous next

[Building your app](/docs/kit/building-your-app)
 [Zero-config deployments](/docs/kit/adapter-auto)

---

# Page options • Docs • Svelte

[Skip to main content](#main)

By default, SvelteKit will render (or [prerender](glossary#Prerendering)
) any component first on the server and send it to the client as HTML. It will then render the component again in the browser to make it interactive in a process called [**hydration**](glossary#Hydration)
. For this reason, you need to ensure that components can run in both places. SvelteKit will then initialize a [**router**](routing)
 that takes over subsequent navigations.

You can control each of these on a page-by-page basis by exporting options from [`+page.js`](routing#page-page.js)
 or [`+page.server.js`](routing#page-page.server.js)
, or for groups of pages using a shared [`+layout.js`](routing#layout-layout.js)
 or [`+layout.server.js`](routing#layout-layout.server.js)
. To define an option for the whole app, export it from the root layout. Child layouts and pages override values set in parent layouts, so — for example — you can enable prerendering for your entire app then disable it for pages that need to be dynamically rendered.

You can mix and match these options in different areas of your app. For example you could prerender your marketing page for maximum speed, server-render your dynamic pages for SEO and accessibility and turn your admin section into an SPA by rendering it on the client only. This makes SvelteKit very versatile.

prerender[](#prerender)

------------------------

It’s likely that at least some routes of your app can be represented as a simple HTML file generated at build time. These routes can be [_prerendered_](glossary#Prerendering)
.

+page.js/+page.server.js/+server

    export const const prerender: trueprerender = true;

Alternatively, you can set `export const prerender = true` in your root `+layout.js` or `+layout.server.js` and prerender everything except pages that are explicitly marked as _not_ prerenderable:

+page.js/+page.server.js/+server

    export const const prerender: falseprerender = false;

Routes with `prerender = true` will be excluded from manifests used for dynamic SSR, making your server (or serverless/edge functions) smaller. In some cases you might want to prerender a route but also include it in the manifest (for example, with a route like `/blog/[slug]` where you want to prerender your most recent/popular content but server-render the long tail) — for these cases, there’s a third option, ‘auto’:

+page.js/+page.server.js/+server

    export const const prerender: "auto"prerender = 'auto';

> If your entire app is suitable for prerendering, you can use [`adapter-static`](https://github.com/sveltejs/kit/tree/main/packages/adapter-static)
> , which will output files suitable for use with any static webserver.

The prerenderer will start at the root of your app and generate files for any prerenderable pages or `+server.js` routes it finds. Each page is scanned for `<a>` elements that point to other pages that are candidates for prerendering — because of this, you generally don’t need to specify which pages should be accessed. If you _do_ need to specify which pages should be accessed by the prerenderer, you can do so with [`config.kit.prerender.entries`](configuration#prerender)
, or by exporting an [`entries`](#entries)
 function from your dynamic route.

While prerendering, the value of `building` imported from [`$app/environment`]($app-environment)
 will be `true`.

### Prerendering server routes[](#prerender-Prerendering-server-routes)

Unlike the other page options, `prerender` also applies to `+server.js` files. These files are _not_ affected by layouts, but will inherit default values from the pages that fetch data from them, if any. For example if a `+page.js` contains this `load` function...

+page

    export const const prerender: trueprerender = true;
    
    /** @type {import('./$types').PageLoad} */
    export async function function load({ fetch }: {
        fetch: any;
    }): Promise<any>@type{import('./$types').PageLoad}load({ fetch: anyfetch }) {
    	const const res: anyres = await fetch: anyfetch('/my-server-route.json');
    	return await const res: anyres.json();
    }

    import type { type PageLoad = (event: Kit.LoadEvent<Record<string, any>, Record<string, any> | null, Record<string, any>, string | null>) => MaybePromise<void | Record<string, any>>
    type PageLoad = (event: Kit.LoadEvent<Record<string, any>, Record<string, any> | null, Record<string, any>, string | null>) => MaybePromise<void | Record<string, any>>PageLoad } from './$types';
    export const const prerender: trueprerender = true;
    
    export const const load: PageLoadload: type PageLoad = (event: Kit.LoadEvent<Record<string, any>, Record<string, any> | null, Record<string, any>, string | null>) => MaybePromise<void | Record<string, any>>
    type PageLoad = (event: Kit.LoadEvent<Record<string, any>, Record<string, any> | null, Record<string, any>, string | null>) => MaybePromise<void | Record<string, any>>PageLoad = async ({ fetch: {
        (input: RequestInfo | URL, init?: RequestInit): Promise<Response>;
        (input: string | URL | globalThis.Request, init?: RequestInit): Promise<Response>;
    }fetch is equivalent to the native fetch web API, with a few additional features:
    
    It can be used to make credentialed requests on the server, as it inherits the cookie and authorization headers for the page request.
    It can make relative requests on the server (ordinarily, fetch requires a URL with an origin when used in a server context).
    Internal requests (e.g. for +server.js routes) go directly to the handler function when running on the server, without the overhead of an HTTP call.
    During server-side rendering, the response will be captured and inlined into the rendered HTML by hooking into the text and json methods of the Response object. Note that headers will not be serialized, unless explicitly included via filterSerializedResponseHeaders
    During hydration, the response will be read from the HTML, guaranteeing consistency and preventing an additional network request.
    
    You can learn more about making credentialed requests with cookies here
    fetch }) => {
    	const const res: Responseres = await fetch: (input: string | URL | globalThis.Request, init?: RequestInit) => Promise<Response> (+1 overload)MDN Reference
    fetch('/my-server-route.json');
    	return await const res: Responseres.Body.json(): Promise<any>MDN Reference
    json();
    };

...then `src/routes/my-server-route.json/+server.js` will be treated as prerenderable if it doesn’t contain its own `export const prerender = false`.

### When not to prerender[](#prerender-When-not-to-prerender)

The basic rule is this: for a page to be prerenderable, any two users hitting it directly must get the same content from the server.

> Not all pages are suitable for prerendering. Any content that is prerendered will be seen by all users. You can of course fetch personalized data in `onMount` in a prerendered page, but this may result in a poorer user experience since it will involve blank initial content or loading indicators.

Note that you can still prerender pages that load data based on the page’s parameters, such as a `src/routes/blog/[slug]/+page.svelte` route.

Accessing [`url.searchParams`](load#Using-URL-data-url)
 during prerendering is forbidden. If you need to use it, ensure you are only doing so in the browser (for example in `onMount`).

Pages with [actions](form-actions)
 cannot be prerendered, because a server must be able to handle the action `POST` requests.

### Route conflicts[](#prerender-Route-conflicts)

Because prerendering writes to the filesystem, it isn’t possible to have two endpoints that would cause a directory and a file to have the same name. For example, `src/routes/foo/+server.js` and `src/routes/foo/bar/+server.js` would try to create `foo` and `foo/bar`, which is impossible.

For that reason among others, it’s recommended that you always include a file extension — `src/routes/foo.json/+server.js` and `src/routes/foo/bar.json/+server.js` would result in `foo.json` and `foo/bar.json` files living harmoniously side-by-side.

For _pages_, we skirt around this problem by writing `foo/index.html` instead of `foo`.

### Troubleshooting[](#prerender-Troubleshooting)

If you encounter an error like ‘The following routes were marked as prerenderable, but were not prerendered’ it’s because the route in question (or a parent layout, if it’s a page) has `export const prerender = true` but the page wasn’t reached by the prerendering crawler and thus wasn’t prerendered.

Since these routes cannot be dynamically server-rendered, this will cause errors when people try to access the route in question. There are a few ways to fix it:

*   Ensure that SvelteKit can find the route by following links from [`config.kit.prerender.entries`](configuration#prerender)
     or the [`entries`](#entries)
     page option. Add links to dynamic routes (i.e. pages with `[parameters]` ) to this option if they are not found through crawling the other entry points, else they are not prerendered because SvelteKit doesn’t know what value the parameters should have. Pages not marked as prerenderable will be ignored and their links to other pages will not be crawled, even if some of them would be prerenderable.
*   Ensure that SvelteKit can find the route by discovering a link to it from one of your other prerendered pages that have server-side rendering enabled.
*   Change `export const prerender = true` to `export const prerender = 'auto'`. Routes with `'auto'` can be dynamically server rendered

entries[](#entries)

--------------------

SvelteKit will discover pages to prerender automatically, by starting at _entry points_ and crawling them. By default, all your non-dynamic routes are considered entry points — for example, if you have these routes...

    /    # non-dynamic
    /blog# non-dynamic
    /blog/[slug]  # dynamic, because of `[slug]`

...SvelteKit will prerender `/` and `/blog`, and in the process discover links like `<a href="/blog/hello-world">` which give it new pages to prerender.

Most of the time, that’s enough. In some situations, links to pages like `/blog/hello-world` might not exist (or might not exist on prerendered pages), in which case we need to tell SvelteKit about their existence.

This can be done with [`config.kit.prerender.entries`](configuration#prerender)
, or by exporting an `entries` function from a `+page.js`, a `+page.server.js` or a `+server.js` belonging to a dynamic route:

src/routes/blog/\[slug\]/+page.server

    /** @type {import('./$types').EntryGenerator} */
    export function function entries(): {
        slug: string;
    }[]@type{import('./$types').EntryGenerator}entries() {
    	return [\
    		{ slug: stringslug: 'hello-world' },\
    		{ slug: stringslug: 'another-blog-post' }\
    	];
    }
    
    export const const prerender: trueprerender = true;

    import type { type EntryGenerator = () => Promise<Array<Record<string, any>>> | Array<Record<string, any>>
    type EntryGenerator = () => Promise<Array<Record<string, any>>> | Array<Record<string, any>>EntryGenerator } from './$types';
    
    export const const entries: EntryGeneratorentries: type EntryGenerator = () => Promise<Array<Record<string, any>>> | Array<Record<string, any>>
    type EntryGenerator = () => Promise<Array<Record<string, any>>> | Array<Record<string, any>>EntryGenerator = () => {
    	return [\
    		{ slug: stringslug: 'hello-world' },\
    		{ slug: stringslug: 'another-blog-post' }\
    	];
    };
    
    export const const prerender: trueprerender = true;

`entries` can be an `async` function, allowing you to (for example) retrieve a list of posts from a CMS or database, in the example above.

ssr[](#ssr)

------------

Normally, SvelteKit renders your page on the server first and sends that HTML to the client where it’s [hydrated](glossary#Hydration)
. If you set `ssr` to `false`, it renders an empty ‘shell’ page instead. This is useful if your page is unable to be rendered on the server (because you use browser-only globals like `document` for example), but in most situations it’s not recommended ([see appendix](glossary#SSR)
).

+page

    export const const ssr: falsessr = false;
    // If both `ssr` and `csr` are `false`, nothing will be rendered!

If you add `export const ssr = false` to your root `+layout.js`, your entire app will only be rendered on the client — which essentially means you turn your app into an SPA.

csr[](#csr)

------------

Ordinarily, SvelteKit [hydrates](glossary#Hydration)
 your server-rendered HTML into an interactive client-side-rendered (CSR) page. Some pages don’t require JavaScript at all — many blog posts and ‘about’ pages fall into this category. In these cases you can disable CSR:

+page

    export const const csr: falsecsr = false;
    // If both `csr` and `ssr` are `false`, nothing will be rendered!

Disabling CSR does not ship any JavaScript to the client. This means:

*   The webpage should work with HTML and CSS only.
*   `<script>` tags inside all Svelte components are removed.
*   `<form>` elements cannot be [progressively enhanced](form-actions#Progressive-enhancement)
    .
*   Links are handled by the browser with a full-page navigation.
*   Hot Module Replacement (HMR) will be disabled.

You can enable `csr` during development (for example to take advantage of HMR) like so:

+page

    import { const dev: booleanWhether the dev server is running. This is not guaranteed to correspond to NODE_ENV or MODE.
    dev } from '$app/environment';
    
    export const const csr: booleancsr = const dev: booleanWhether the dev server is running. This is not guaranteed to correspond to NODE_ENV or MODE.
    dev;

trailingSlash[](#trailingSlash)

--------------------------------

By default, SvelteKit will remove trailing slashes from URLs — if you visit `/about/`, it will respond with a redirect to `/about`. You can change this behaviour with the `trailingSlash` option, which can be one of `'never'` (the default), `'always'`, or `'ignore'`.

As with other page options, you can export this value from a `+layout.js` or a `+layout.server.js` and it will apply to all child pages. You can also export the configuration from `+server.js` files.

src/routes/+layout

    export const const trailingSlash: "always"trailingSlash = 'always';

This option also affects [prerendering](#prerender)
. If `trailingSlash` is `always`, a route like `/about` will result in an `about/index.html` file, otherwise it will create `about.html`, mirroring static webserver conventions.

> Ignoring trailing slashes is not recommended — the semantics of relative paths differ between the two cases (`./y` from `/x` is `/y`, but from `/x/` is `/x/y`), and `/x` and `/x/` are treated as separate URLs which is harmful to SEO.

config[](#config)

------------------

With the concept of [adapters](adapters)
, SvelteKit is able to run on a variety of platforms. Each of these might have specific configuration to further tweak the deployment — for example on Vercel you could choose to deploy some parts of your app on the edge and others on serverless environments.

`config` is an object with key-value pairs at the top level. Beyond that, the concrete shape is dependent on the adapter you’re using. Every adapter should provide a `Config` interface to import for type safety. Consult the documentation of your adapter for more information.

src/routes/+page

    /** @type {import('some-adapter').Config} */
    export const const config: Config@type{import('some-adapter').Config}config = {
    	Config.runtime: stringruntime: 'edge'
    };

    import type { Config } from 'some-adapter';
    
    export const const config: Configconfig: Config = {
    	Config.runtime: stringruntime: 'edge'
    };

`config` objects are merged at the top level (but _not_ deeper levels). This means you don’t need to repeat all the values in a `+page.js` if you want to only override some of the values in the upper `+layout.js`. For example this layout configuration...

src/routes/+layout

    export const const config: {
        runtime: string;
        regions: string;
        foo: {
            bar: boolean;
        };
    }config = {
    	runtime: stringruntime: 'edge',
    	regions: stringregions: 'all',
    	foo: {
        bar: boolean;
    }foo: {
    		bar: booleanbar: true
    	}
    }

...is overridden by this page configuration...

src/routes/+page

    export const const config: {
        regions: string[];
        foo: {
            baz: boolean;
        };
    }config = {
    	regions: string[]regions: ['us1', 'us2'],
    	foo: {
        baz: boolean;
    }foo: {
    		baz: booleanbaz: true
    	}
    }

...which results in the config value `{ runtime: 'edge', regions: ['us1', 'us2'], foo: { baz: true } }` for that page.

Further reading[](#Further-reading)

------------------------------------

*   [Tutorial: Page options](/tutorial/kit/page-options)
    

[Edit this page on GitHub](https://github.com/sveltejs/kit/edit/main/documentation/docs/20-core-concepts/40-page-options.md)

previous next

[Form actions](/docs/kit/form-actions)
 [State management](/docs/kit/state-management)

---

# State management • Docs • Svelte

[Skip to main content](#main)

If you’re used to building client-only apps, state management in an app that spans server and client might seem intimidating. This section provides tips for avoiding some common gotchas.

Avoid shared state on the server[](#Avoid-shared-state-on-the-server)

----------------------------------------------------------------------

Browsers are _stateful_ — state is stored in memory as the user interacts with the application. Servers, on the other hand, are _stateless_ — the content of the response is determined entirely by the content of the request.

Conceptually, that is. In reality, servers are often long-lived and shared by multiple users. For that reason it’s important not to store data in shared variables. For example, consider this code:

+page.server

    let let user: anyuser;
    
    /** @type {import('./$types').PageServerLoad} */
    export function function load(): {
        user: any;
    }@type{import('./$types').PageServerLoad}load() {
    	return { user: anyuser };
    }
    
    /** @satisfies {import('./$types').Actions} */
    export const const actions: {
        default: ({ request }: {
            request: any;
        }) => Promise<void>;
    }@satisfies{import('./$types').Actions}actions = {
    	default: ({ request }: {
        request: any;
    }) => Promise<void>default: async ({ request: anyrequest }) => {
    		const const data: anydata = await request: anyrequest.formData();
    
    		// NEVER DO THIS!
    		let user: anyuser = {
    			name: anyname: const data: anydata.get('name'),
    			embarrassingSecret: anyembarrassingSecret: const data: anydata.get('secret')
    		};
    	}
    }

    import type { type PageServerLoad = (event: Kit.ServerLoadEvent<Record<string, any>, Record<string, any>, string | null>) => MaybePromise<void | Record<string, any>>
    type PageServerLoad = (event: Kit.ServerLoadEvent<Record<string, any>, Record<string, any>, string | null>) => MaybePromise<void | Record<string, any>>PageServerLoad, type Actions = {
        [x: string]: Kit.Action<Record<string, any>, void | Record<string, any>, string | null>;
    }
    type Actions = {
        [x: string]: Kit.Action<Record<string, any>, void | Record<string, any>, string | null>;
    }Actions } from './$types';
    let let user: anyuser;
    
    export const const load: PageServerLoadload: type PageServerLoad = (event: Kit.ServerLoadEvent<Record<string, any>, Record<string, any>, string | null>) => MaybePromise<void | Record<string, any>>
    type PageServerLoad = (event: Kit.ServerLoadEvent<Record<string, any>, Record<string, any>, string | null>) => MaybePromise<void | Record<string, any>>PageServerLoad = () => {
    	return { user: anyuser };
    };
    
    export const const actions: {
        default: ({ request }: Kit.RequestEvent<Record<string, any>, string | null>) => Promise<void>;
    }actions = {
    	default: ({ request }: Kit.RequestEvent<Record<string, any>, string | null>) => Promise<void>default: async ({ request: RequestThe original request object
    request }) => {
    		const const data: FormDatadata = await request: RequestThe original request object
    request.Body.formData(): Promise<FormData>MDN Reference
    formData();
    
    		// NEVER DO THIS!
    		let user: anyuser = {
    			name: FormDataEntryValue | nullname: const data: FormDatadata.FormData.get(name: string): FormDataEntryValue | nullMDN Reference
    get('name'),
    			embarrassingSecret: FormDataEntryValue | nullembarrassingSecret: const data: FormDatadata.FormData.get(name: string): FormDataEntryValue | nullMDN Reference
    get('secret')
    		};
    	}
    } satisfies type Actions = {
        [x: string]: Kit.Action<Record<string, any>, void | Record<string, any>, string | null>;
    }
    type Actions = {
        [x: string]: Kit.Action<Record<string, any>, void | Record<string, any>, string | null>;
    }Actions

The `user` variable is shared by everyone who connects to this server. If Alice submitted an embarrassing secret, and Bob visited the page after her, Bob would know Alice’s secret. In addition, when Alice returns to the site later in the day, the server may have restarted, losing her data.

Instead, you should _authenticate_ the user using [`cookies`](load#Cookies)
 and persist the data to a database.

No side-effects in load[](#No-side-effects-in-load)

----------------------------------------------------

For the same reason, your `load` functions should be _pure_ — no side-effects (except maybe the occasional `console.log(...)`). For example, you might be tempted to write to a store or global state inside a `load` function so that you can use the value in your components:

+page

    import { const user: {
        set: (value: any) => void;
    }user } from '$lib/user';
    
    /** @type {import('./$types').PageLoad} */
    export async function function load(event: LoadEvent<Record<string, any>, Record<string, any> | null, Record<string, any>, string | null>): MaybePromise<void | Record<string, any>>@type{import('./$types').PageLoad}load({ fetch: {
        (input: RequestInfo | URL, init?: RequestInit): Promise<Response>;
        (input: string | URL | globalThis.Request, init?: RequestInit): Promise<Response>;
    }fetch is equivalent to the native fetch web API, with a few additional features:
    
    It can be used to make credentialed requests on the server, as it inherits the cookie and authorization headers for the page request.
    It can make relative requests on the server (ordinarily, fetch requires a URL with an origin when used in a server context).
    Internal requests (e.g. for +server.js routes) go directly to the handler function when running on the server, without the overhead of an HTTP call.
    During server-side rendering, the response will be captured and inlined into the rendered HTML by hooking into the text and json methods of the Response object. Note that headers will not be serialized, unless explicitly included via filterSerializedResponseHeaders
    During hydration, the response will be read from the HTML, guaranteeing consistency and preventing an additional network request.
    
    You can learn more about making credentialed requests with cookies here
    fetch }) {
    	const const response: Responseresponse = await fetch: (input: string | URL | globalThis.Request, init?: RequestInit) => Promise<Response> (+1 overload)MDN Reference
    fetch('/api/user');
    
    	// NEVER DO THIS!
    	const user: {
        set: (value: any) => void;
    }user.set: (value: any) => voidset(await const response: Responseresponse.Body.json(): Promise<any>MDN Reference
    json());
    }

    import { const user: {
        set: (value: any) => void;
    }user } from '$lib/user';
    import type { type PageLoad = (event: LoadEvent<Record<string, any>, Record<string, any> | null, Record<string, any>, string | null>) => MaybePromise<void | Record<string, any>>PageLoad } from './$types';
    
    export const const load: PageLoadload: type PageLoad = (event: LoadEvent<Record<string, any>, Record<string, any> | null, Record<string, any>, string | null>) => MaybePromise<void | Record<string, any>>PageLoad = async ({ fetch: {
        (input: RequestInfo | URL, init?: RequestInit): Promise<Response>;
        (input: string | URL | globalThis.Request, init?: RequestInit): Promise<Response>;
    }fetch is equivalent to the native fetch web API, with a few additional features:
    
    It can be used to make credentialed requests on the server, as it inherits the cookie and authorization headers for the page request.
    It can make relative requests on the server (ordinarily, fetch requires a URL with an origin when used in a server context).
    Internal requests (e.g. for +server.js routes) go directly to the handler function when running on the server, without the overhead of an HTTP call.
    During server-side rendering, the response will be captured and inlined into the rendered HTML by hooking into the text and json methods of the Response object. Note that headers will not be serialized, unless explicitly included via filterSerializedResponseHeaders
    During hydration, the response will be read from the HTML, guaranteeing consistency and preventing an additional network request.
    
    You can learn more about making credentialed requests with cookies here
    fetch }) => {
    	const const response: Responseresponse = await fetch: (input: string | URL | globalThis.Request, init?: RequestInit) => Promise<Response> (+1 overload)MDN Reference
    fetch('/api/user');
    
    	// NEVER DO THIS!
    	const user: {
        set: (value: any) => void;
    }user.set: (value: any) => voidset(await const response: Responseresponse.Body.json(): Promise<any>MDN Reference
    json());
    };

As with the previous example, this puts one user’s information in a place that is shared by _all_ users. Instead, just return the data...

+page

    /** @type {import('./$types').PageServerLoad} */
    export async function function load({ fetch }: {
        fetch: any;
    }): Promise<{
        user: any;
    }>@type{import('./$types').PageServerLoad}load({ fetch: anyfetch }) {
    	const const response: anyresponse = await fetch: anyfetch('/api/user');
    
    	return {
    		user: anyuser: await const response: anyresponse.json()
    	};
    }

    import type { type PageServerLoad = (event: Kit.ServerLoadEvent<Record<string, any>, Record<string, any>, string | null>) => MaybePromise<void | Record<string, any>>
    type PageServerLoad = (event: Kit.ServerLoadEvent<Record<string, any>, Record<string, any>, string | null>) => MaybePromise<void | Record<string, any>>PageServerLoad } from './$types';
    
    export const const load: PageServerLoadload: type PageServerLoad = (event: Kit.ServerLoadEvent<Record<string, any>, Record<string, any>, string | null>) => MaybePromise<void | Record<string, any>>
    type PageServerLoad = (event: Kit.ServerLoadEvent<Record<string, any>, Record<string, any>, string | null>) => MaybePromise<void | Record<string, any>>PageServerLoad = async ({ fetch: {
        (input: RequestInfo | URL, init?: RequestInit): Promise<Response>;
        (input: string | URL | globalThis.Request, init?: RequestInit): Promise<Response>;
    }fetch is equivalent to the native fetch web API, with a few additional features:
    
    It can be used to make credentialed requests on the server, as it inherits the cookie and authorization headers for the page request.
    It can make relative requests on the server (ordinarily, fetch requires a URL with an origin when used in a server context).
    Internal requests (e.g. for +server.js routes) go directly to the handler function when running on the server, without the overhead of an HTTP call.
    During server-side rendering, the response will be captured and inlined into the rendered HTML by hooking into the text and json methods of the Response object. Note that headers will not be serialized, unless explicitly included via filterSerializedResponseHeaders
    During hydration, the response will be read from the HTML, guaranteeing consistency and preventing an additional network request.
    
    You can learn more about making credentialed requests with cookies here
    fetch }) => {
    	const const response: Responseresponse = await fetch: (input: string | URL | globalThis.Request, init?: RequestInit) => Promise<Response> (+1 overload)MDN Reference
    fetch('/api/user');
    
    	return {
    		user: anyuser: await const response: Responseresponse.Body.json(): Promise<any>MDN Reference
    json()
    	};
    };

...and pass it around to the components that need it, or use [`page.data`](load#page.data)
.

If you’re not using SSR, then there’s no risk of accidentally exposing one user’s data to another. But you should still avoid side-effects in your `load` functions — your application will be much easier to reason about without them.

Using state and stores with context[](#Using-state-and-stores-with-context)

----------------------------------------------------------------------------

You might wonder how we’re able to use `page.data` and other [app state]($app-state)
 (or [app stores]($app-stores)
) if we can’t use global state. The answer is that app state and app stores on the server use Svelte’s [context API](/tutorial/svelte/context-api)
 — the state (or store) is attached to the component tree with `setContext`, and when you subscribe you retrieve it with `getContext`. We can do the same thing with our own state:

src/routes/+layout

    <script>
    	import { setContext } from 'svelte';
    
    	/** @type {{ data: import('./$types').LayoutData }} */
    	let { data } = $props();
    
    	// Pass a function referencing our state
    	// to the context for child components to access
    	setContext('user', () => data.user);
    </script>

    <script lang="ts">
    	import { setContext } from 'svelte';
    	import type { LayoutData } from './$types';
    
    	let { data }: { data: LayoutData } = $props();
    
    	// Pass a function referencing our state
    	// to the context for child components to access
    	setContext('user', () => data.user);
    </script>

src/routes/user/+page

    <script>
    	import { getContext } from 'svelte';
    
    	// Retrieve user store from context
    	const user = getContext('user');
    </script>
    
    <p>Welcome {user().name}</p>

    <script lang="ts">
    	import { getContext } from 'svelte';
    
    	// Retrieve user store from context
    	const user = getContext('user');
    </script>
    
    <p>Welcome {user().name}</p>

> We’re passing a function into `setContext` to keep reactivity across boundaries. Read more about it [here](/docs/svelte/$state#Passing-state-into-functions)

> Legacy mode
> 
> You also use stores from `svelte/store` for this, but when using Svelte 5 it is recommended to make use of universal reactivity instead.

Updating the value of context-based state in deeper-level pages or components while the page is being rendered via SSR will not affect the value in the parent component because it has already been rendered by the time the state value is updated. In contrast, on the client (when CSR is enabled, which is the default) the value will be propagated and components, pages, and layouts higher in the hierarchy will react to the new value. Therefore, to avoid values ‘flashing’ during state updates during hydration, it is generally recommended to pass state down into components rather than up.

If you’re not using SSR (and can guarantee that you won’t need to use SSR in future) then you can safely keep state in a shared module, without using the context API.

Component and page state is preserved[](#Component-and-page-state-is-preserved)

--------------------------------------------------------------------------------

When you navigate around your application, SvelteKit reuses existing layout and page components. For example, if you have a route like this...

src/routes/blog/\[slug\]/+page

    <script>
    	/** @type {{ data: import('./$types').PageData }} */
    	let { data } = $props();
    
    	// THIS CODE IS BUGGY!
    	const wordCount = data.content.split(' ').length;
    	const estimatedReadingTime = wordCount / 250;
    </script>
    
    <header>
    	<h1>{data.title}</h1>
    	<p>Reading time: {Math.round(estimatedReadingTime)} minutes</p>
    </header>
    
    <div>{@html data.content}</div>

    <script lang="ts">
    	import type { PageData } from './$types';
    
    	let { data }: { data: PageData } = $props();
    
    	// THIS CODE IS BUGGY!
    	const wordCount = data.content.split(' ').length;
    	const estimatedReadingTime = wordCount / 250;
    </script>
    
    <header>
    	<h1>{data.title}</h1>
    	<p>Reading time: {Math.round(estimatedReadingTime)} minutes</p>
    </header>
    
    <div>{@html data.content}</div>

...then navigating from `/blog/my-short-post` to `/blog/my-long-post` won’t cause the layout, page and any other components within to be destroyed and recreated. Instead the `data` prop (and by extension `data.title` and `data.content`) will update (as it would with any other Svelte component) and, because the code isn’t rerunning, lifecycle methods like `onMount` and `onDestroy` won’t rerun and `estimatedReadingTime` won’t be recalculated.

Instead, we need to make the value [_reactive_](/tutorial/svelte/state)
:

src/routes/blog/\[slug\]/+page

    <script>
    	/** @type {{ data: import('./$types').PageData }} */
    	let { data } = $props();
    
    	let wordCount = $derived(data.content.split(' ').length);
    	let estimatedReadingTime = $derived(wordCount / 250);
    </script>

    <script lang="ts">
    	import type { PageData } from './$types';
    
    	let { data }: { data: PageData } = $props();
    
    	let wordCount = $derived(data.content.split(' ').length);
    	let estimatedReadingTime = $derived(wordCount / 250);
    </script>

> If your code in `onMount` and `onDestroy` has to run again after navigation you can use [afterNavigate]($app-navigation#afterNavigate)
>  and [beforeNavigate]($app-navigation#beforeNavigate)
>  respectively.

Reusing components like this means that things like sidebar scroll state are preserved, and you can easily animate between changing values. In the case that you do need to completely destroy and remount a component on navigation, you can use this pattern:

    <script>
    	import { page } from '$app/state';
    </script>
    
    {#key page.url.pathname}
    	<BlogPost title={data.title} content={data.title} />
    {/key}

Storing state in the URL[](#Storing-state-in-the-URL)

------------------------------------------------------

If you have state that should survive a reload and/or affect SSR, such as filters or sorting rules on a table, URL search parameters (like `?sort=price&order=ascending`) are a good place to put them. You can put them in `<a href="...">` or `<form action="...">` attributes, or set them programmatically via `goto('?key=value')`. They can be accessed inside `load` functions via the `url` parameter, and inside components via `page.url.searchParams`.

Storing ephemeral state in snapshots[](#Storing-ephemeral-state-in-snapshots)

------------------------------------------------------------------------------

Some UI state, such as ‘is the accordion open?’, is disposable — if the user navigates away or refreshes the page, it doesn’t matter if the state is lost. In some cases, you _do_ want the data to persist if the user navigates to a different page and comes back, but storing the state in the URL or in a database would be overkill. For this, SvelteKit provides [snapshots](snapshots)
, which let you associate component state with a history entry.

[Edit this page on GitHub](https://github.com/sveltejs/kit/edit/main/documentation/docs/20-core-concepts/50-state-management.md)

previous next

[Page options](/docs/kit/page-options)
 [Building your app](/docs/kit/building-your-app)

---

# Zero-config deployments • Docs • Svelte

[Skip to main content](#main)

When you create a new SvelteKit project with `npx sv create`, it installs [`adapter-auto`](https://github.com/sveltejs/kit/tree/main/packages/adapter-auto)
 by default. This adapter automatically installs and uses the correct adapter for supported environments when you deploy:

*   [`@sveltejs/adapter-cloudflare`](adapter-cloudflare)
     for [Cloudflare Pages](https://developers.cloudflare.com/pages/)
    
*   [`@sveltejs/adapter-netlify`](adapter-netlify)
     for [Netlify](https://netlify.com/)
    
*   [`@sveltejs/adapter-vercel`](adapter-vercel)
     for [Vercel](https://vercel.com/)
    
*   [`svelte-adapter-azure-swa`](https://github.com/geoffrich/svelte-adapter-azure-swa)
     for [Azure Static Web Apps](https://docs.microsoft.com/en-us/azure/static-web-apps/)
    
*   [`svelte-kit-sst`](https://github.com/sst/sst/tree/master/packages/svelte-kit-sst)
     for [AWS via SST](https://sst.dev/docs/start/aws/svelte)
    
*   [`@sveltejs/adapter-node`](adapter-node)
     for [Google Cloud Run](https://cloud.google.com/run)
    

It’s recommended to install the appropriate adapter to your `devDependencies` once you’ve settled on a target environment, since this will add the adapter to your lockfile and slightly improve install times on CI.

Environment-specific configuration[](#Environment-specific-configuration)

--------------------------------------------------------------------------

To add configuration options, such as `{ edge: true }` in [`adapter-vercel`](adapter-vercel)
 and [`adapter-netlify`](adapter-netlify)
, you must install the underlying adapter — `adapter-auto` does not take any options.

Adding community adapters[](#Adding-community-adapters)

--------------------------------------------------------

You can add zero-config support for additional adapters by editing [adapters.js](https://github.com/sveltejs/kit/blob/main/packages/adapter-auto/adapters.js)
 and opening a pull request.

[Edit this page on GitHub](https://github.com/sveltejs/kit/edit/main/documentation/docs/25-build-and-deploy/30-adapter-auto.md)

previous next

[Adapters](/docs/kit/adapters)
 [Node servers](/docs/kit/adapter-node)

---

# Building your app • Docs • Svelte

[Skip to main content](#main)

Building a SvelteKit app happens in two stages, which both happen when you run `vite build` (usually via `npm run build`).

Firstly, Vite creates an optimized production build of your server code, your browser code, and your service worker (if you have one). [Prerendering](page-options#prerender)
 is executed at this stage, if appropriate.

Secondly, an _adapter_ takes this production build and tunes it for your target environment — more on this on the following pages.

During the build[](#During-the-build)

--------------------------------------

SvelteKit will load your `+page/layout(.server).js` files (and all files they import) for analysis during the build. Any code that should _not_ be executed at this stage must check that `building` from [`$app/environment`]($app-environment)
 is `false`:

    import { const building: booleanSvelteKit analyses your app during the build step by running it. During this process, building is true. This also applies during prerendering.
    building } from '$app/environment';
    import { import setupMyDatabasesetupMyDatabase } from '$lib/server/database';
    
    if (!const building: booleanSvelteKit analyses your app during the build step by running it. During this process, building is true. This also applies during prerendering.
    building) {
    	import setupMyDatabasesetupMyDatabase();
    }
    
    export function function load(): voidload() {
    	// ...
    }

Preview your app[](#Preview-your-app)

--------------------------------------

After building, you can view your production build locally with `vite preview` (via `npm run preview`). Note that this will run the app in Node, and so is not a perfect reproduction of your deployed app — adapter-specific adjustments like the [`platform` object](adapters#Platform-specific-context)
 do not apply to previews.

[Edit this page on GitHub](https://github.com/sveltejs/kit/edit/main/documentation/docs/25-build-and-deploy/10-building-your-app.md)

previous next

[State management](/docs/kit/state-management)
 [Adapters](/docs/kit/adapters)

---

# Routing • Docs • Svelte

[Skip to main content](#main)

At the heart of SvelteKit is a _filesystem-based router_. The routes of your app — i.e. the URL paths that users can access — are defined by the directories in your codebase:

*   `src/routes` is the root route
*   `src/routes/about` creates an `/about` route
*   `src/routes/blog/[slug]` creates a route with a _parameter_, `slug`, that can be used to load data dynamically when a user requests a page like `/blog/hello-world`

> You can change `src/routes` to a different directory by editing the [project config](configuration)
> .

Each route directory contains one or more _route files_, which can be identified by their `+` prefix.

We’ll introduce these files in a moment in more detail, but here are a few simple rules to help you remember how SvelteKit’s routing works:

*   All files can run on the server
*   All files run on the client except `+server` files
*   `+layout` and `+error` files apply to subdirectories as well as the directory they live in

+page[](#page)

---------------

### +page.svelte[](#page-page.svelte)

A `+page.svelte` component defines a page of your app. By default, pages are rendered both on the server ([SSR](glossary#SSR)
) for the initial request and in the browser ([CSR](glossary#CSR)
) for subsequent navigation.

src/routes/+page

    <h1>Hello and welcome to my site!</h1>
    <a href="/about">About my site</a>

src/routes/about/+page

    <h1>About this site</h1>
    <p>TODO...</p>
    <a href="/">Home</a>

Pages can receive data from `load` functions via the `data` prop.

src/routes/blog/\[slug\]/+page

    <script>
    	/** @type {{ data: import('./$types').PageData }} */
    	let { data } = $props();
    </script>
    
    <h1>{data.title}</h1>
    <div>{@html data.content}</div>

    <script lang="ts">
    	import type { PageData } from './$types';
    
    	let { data }: { data: PageData } = $props();
    </script>
    
    <h1>{data.title}</h1>
    <div>{@html data.content}</div>

> Legacy mode
> 
> In Svelte 4, you’d use `export let data` instead

> SvelteKit uses `<a>` elements to navigate between routes, rather than a framework-specific `<Link>` component.

### +page.js[](#page-page.js)

Often, a page will need to load some data before it can be rendered. For this, we add a `+page.js` module that exports a `load` function:

src/routes/blog/\[slug\]/+page

    import { function error(status: number, body: App.Error): never (+1 overload)Throws an error with a HTTP status code and an optional message.
    When called during request handling, this will cause SvelteKit to
    return an error response without invoking handleError.
    Make sure you’re not catching the thrown error, which would prevent SvelteKit from handling it.
    @paramstatus The HTTP status code. Must be in the range 400-599.@parambody An object that conforms to the App.Error type. If a string is passed, it will be used as the message property.@throwsHttpError This error instructs SvelteKit to initiate HTTP error handling.@throwsError If the provided status is invalid (not between 400 and 599).error } from '@sveltejs/kit';
    
    /** @type {import('./$types').PageLoad} */
    export function function load({ params }: {
        params: any;
    }): {
        title: string;
        content: string;
    }@type{import('./$types').PageLoad}load({ params: anyparams }) {
    	if (params: anyparams.slug === 'hello-world') {
    		return {
    			title: stringtitle: 'Hello world!',
    			content: stringcontent: 'Welcome to our blog. Lorem ipsum dolor sit amet...'
    		};
    	}
    
    	function error(status: number, body?: {
        message: string;
    } extends App.Error ? App.Error | string | undefined : never): never (+1 overload)Throws an error with a HTTP status code and an optional message.
    When called during request handling, this will cause SvelteKit to
    return an error response without invoking handleError.
    Make sure you’re not catching the thrown error, which would prevent SvelteKit from handling it.
    @paramstatus The HTTP status code. Must be in the range 400-599.@parambody An object that conforms to the App.Error type. If a string is passed, it will be used as the message property.@throwsHttpError This error instructs SvelteKit to initiate HTTP error handling.@throwsError If the provided status is invalid (not between 400 and 599).error(404, 'Not found');
    }

    import { function error(status: number, body: App.Error): never (+1 overload)Throws an error with a HTTP status code and an optional message.
    When called during request handling, this will cause SvelteKit to
    return an error response without invoking handleError.
    Make sure you’re not catching the thrown error, which would prevent SvelteKit from handling it.
    @paramstatus The HTTP status code. Must be in the range 400-599.@parambody An object that conforms to the App.Error type. If a string is passed, it will be used as the message property.@throwsHttpError This error instructs SvelteKit to initiate HTTP error handling.@throwsError If the provided status is invalid (not between 400 and 599).error } from '@sveltejs/kit';
    import type { type PageLoad = (event: Kit.LoadEvent<Record<string, any>, Record<string, any> | null, Record<string, any>, string | null>) => MaybePromise<void | Record<string, any>>
    type PageLoad = (event: Kit.LoadEvent<Record<string, any>, Record<string, any> | null, Record<string, any>, string | null>) => MaybePromise<void | Record<string, any>>PageLoad } from './$types';
    
    export const const load: PageLoadload: type PageLoad = (event: Kit.LoadEvent<Record<string, any>, Record<string, any> | null, Record<string, any>, string | null>) => MaybePromise<void | Record<string, any>>
    type PageLoad = (event: Kit.LoadEvent<Record<string, any>, Record<string, any> | null, Record<string, any>, string | null>) => MaybePromise<void | Record<string, any>>PageLoad = ({ params: Record<string, any>The parameters of the current page - e.g. for a route like /blog/[slug], a { slug: string } object
    params }) => {
    	if (params: Record<string, any>The parameters of the current page - e.g. for a route like /blog/[slug], a { slug: string } object
    params.slug === 'hello-world') {
    		return {
    			title: stringtitle: 'Hello world!',
    			content: stringcontent: 'Welcome to our blog. Lorem ipsum dolor sit amet...'
    		};
    	}
    
    	function error(status: number, body?: {
        message: string;
    } extends App.Error ? App.Error | string | undefined : never): never (+1 overload)Throws an error with a HTTP status code and an optional message.
    When called during request handling, this will cause SvelteKit to
    return an error response without invoking handleError.
    Make sure you’re not catching the thrown error, which would prevent SvelteKit from handling it.
    @paramstatus The HTTP status code. Must be in the range 400-599.@parambody An object that conforms to the App.Error type. If a string is passed, it will be used as the message property.@throwsHttpError This error instructs SvelteKit to initiate HTTP error handling.@throwsError If the provided status is invalid (not between 400 and 599).error(404, 'Not found');
    };

This function runs alongside `+page.svelte`, which means it runs on the server during server-side rendering and in the browser during client-side navigation. See [`load`](load)
 for full details of the API.

As well as `load`, `+page.js` can export values that configure the page’s behaviour:

*   `export const prerender = true` or `false` or `'auto'`
*   `export const ssr = true` or `false`
*   `export const csr = true` or `false`

You can find more information about these in [page options](page-options)
.

### +page.server.js[](#page-page.server.js)

If your `load` function can only run on the server — for example, if it needs to fetch data from a database or you need to access private [environment variables]($env-static-private)
 like API keys — then you can rename `+page.js` to `+page.server.js` and change the `PageLoad` type to `PageServerLoad`.

src/routes/blog/\[slug\]/+page.server

    import { function error(status: number, body: App.Error): never (+1 overload)Throws an error with a HTTP status code and an optional message.
    When called during request handling, this will cause SvelteKit to
    return an error response without invoking handleError.
    Make sure you’re not catching the thrown error, which would prevent SvelteKit from handling it.
    @paramstatus The HTTP status code. Must be in the range 400-599.@parambody An object that conforms to the App.Error type. If a string is passed, it will be used as the message property.@throwsHttpError This error instructs SvelteKit to initiate HTTP error handling.@throwsError If the provided status is invalid (not between 400 and 599).error } from '@sveltejs/kit';
    
    /** @type {import('./$types').PageServerLoad} */
    export async function function load(event: ServerLoadEvent<Record<string, any>, Record<string, any>, string | null>): MaybePromise<void | Record<string, any>>@type{import('./$types').PageServerLoad}load({ params: Record<string, any>The parameters of the current route - e.g. for a route like /blog/[slug], a { slug: string } object
    params }) {
    	const const post: {
        title: string;
        content: string;
    }post = await const getPostFromDatabase: (slug: string) => {
        title: string;
        content: string;
    }getPostFromDatabase(params: Record<string, any>The parameters of the current route - e.g. for a route like /blog/[slug], a { slug: string } object
    params.slug);
    
    	if (const post: {
        title: string;
        content: string;
    }post) {
    		return const post: {
        title: string;
        content: string;
    }post;
    	}
    
    	function error(status: number, body?: {
        message: string;
    } extends App.Error ? App.Error | string | undefined : never): never (+1 overload)Throws an error with a HTTP status code and an optional message.
    When called during request handling, this will cause SvelteKit to
    return an error response without invoking handleError.
    Make sure you’re not catching the thrown error, which would prevent SvelteKit from handling it.
    @paramstatus The HTTP status code. Must be in the range 400-599.@parambody An object that conforms to the App.Error type. If a string is passed, it will be used as the message property.@throwsHttpError This error instructs SvelteKit to initiate HTTP error handling.@throwsError If the provided status is invalid (not between 400 and 599).error(404, 'Not found');
    }

    import { function error(status: number, body: App.Error): never (+1 overload)Throws an error with a HTTP status code and an optional message.
    When called during request handling, this will cause SvelteKit to
    return an error response without invoking handleError.
    Make sure you’re not catching the thrown error, which would prevent SvelteKit from handling it.
    @paramstatus The HTTP status code. Must be in the range 400-599.@parambody An object that conforms to the App.Error type. If a string is passed, it will be used as the message property.@throwsHttpError This error instructs SvelteKit to initiate HTTP error handling.@throwsError If the provided status is invalid (not between 400 and 599).error } from '@sveltejs/kit';
    import type { type PageServerLoad = (event: ServerLoadEvent<Record<string, any>, Record<string, any>, string | null>) => MaybePromise<void | Record<string, any>>PageServerLoad } from './$types';
    
    export const const load: PageServerLoadload: type PageServerLoad = (event: ServerLoadEvent<Record<string, any>, Record<string, any>, string | null>) => MaybePromise<void | Record<string, any>>PageServerLoad = async ({ params: Record<string, any>The parameters of the current route - e.g. for a route like /blog/[slug], a { slug: string } object
    params }) => {
    	const const post: {
        title: string;
        content: string;
    }post = await const getPostFromDatabase: (slug: string) => {
        title: string;
        content: string;
    }getPostFromDatabase(params: Record<string, any>The parameters of the current route - e.g. for a route like /blog/[slug], a { slug: string } object
    params.slug);
    
    	if (const post: {
        title: string;
        content: string;
    }post) {
    		return const post: {
        title: string;
        content: string;
    }post;
    	}
    
    	function error(status: number, body?: {
        message: string;
    } extends App.Error ? App.Error | string | undefined : never): never (+1 overload)Throws an error with a HTTP status code and an optional message.
    When called during request handling, this will cause SvelteKit to
    return an error response without invoking handleError.
    Make sure you’re not catching the thrown error, which would prevent SvelteKit from handling it.
    @paramstatus The HTTP status code. Must be in the range 400-599.@parambody An object that conforms to the App.Error type. If a string is passed, it will be used as the message property.@throwsHttpError This error instructs SvelteKit to initiate HTTP error handling.@throwsError If the provided status is invalid (not between 400 and 599).error(404, 'Not found');
    };

During client-side navigation, SvelteKit will load this data from the server, which means that the returned value must be serializable using [devalue](https://github.com/rich-harris/devalue)
. See [`load`](load)
 for full details of the API.

Like `+page.js`, `+page.server.js` can export [page options](page-options)
 — `prerender`, `ssr` and `csr`.

A `+page.server.js` file can also export _actions_. If `load` lets you read data from the server, `actions` let you write data _to_ the server using the `<form>` element. To learn how to use them, see the [form actions](form-actions)
 section.

+error[](#error)

-----------------

If an error occurs during `load`, SvelteKit will render a default error page. You can customise this error page on a per-route basis by adding an `+error.svelte` file:

src/routes/blog/\[slug\]/+error

    <script>
    	import { page } from '$app/state';
    </script>
    
    <h1>{page.status}: {page.error.message}</h1>

    <script lang="ts">
    	import { page } from '$app/state';
    </script>
    
    <h1>{page.status}: {page.error.message}</h1>

> Legacy mode
> 
> `$app/state` was added in SvelteKit 2.12. If you’re using an earlier version or are using Svelte 4, use `$app/stores` instead.

SvelteKit will ‘walk up the tree’ looking for the closest error boundary — if the file above didn’t exist it would try `src/routes/blog/+error.svelte` and then `src/routes/+error.svelte` before rendering the default error page. If _that_ fails (or if the error was thrown from the `load` function of the root `+layout`, which sits ‘above’ the root `+error`), SvelteKit will bail out and render a static fallback error page, which you can customise by creating a `src/error.html` file.

If the error occurs inside a `load` function in `+layout(.server).js`, the closest error boundary in the tree is an `+error.svelte` file _above_ that layout (not next to it).

If no route can be found (404), `src/routes/+error.svelte` (or the default error page, if that file does not exist) will be used.

> `+error.svelte` is _not_ used when an error occurs inside [`handle`](hooks#Server-hooks-handle)
>  or a [+server.js](#server)
>  request handler.

You can read more about error handling [here](errors)
.

+layout[](#layout)

-------------------

So far, we’ve treated pages as entirely standalone components — upon navigation, the existing `+page.svelte` component will be destroyed, and a new one will take its place.

But in many apps, there are elements that should be visible on _every_ page, such as top-level navigation or a footer. Instead of repeating them in every `+page.svelte`, we can put them in _layouts_.

### +layout.svelte[](#layout-layout.svelte)

To create a layout that applies to every page, make a file called `src/routes/+layout.svelte`. The default layout (the one that SvelteKit uses if you don’t bring your own) looks like this...

    <script>
    	let { children } = $props();
    </script>
    
    {@render children()}

...but we can add whatever markup, styles and behaviour we want. The only requirement is that the component includes a `@render` tag for the page content. For example, let’s add a nav bar:

src/routes/+layout

    <script>
    	let { children } = $props();
    </script>
    
    <nav>
    	<a href="/">Home</a>
    	<a href="/about">About</a>
    	<a href="/settings">Settings</a>
    </nav>
    
    {@render children()}

    <script lang="ts">
    	let { children } = $props();
    </script>
    
    <nav>
    	<a href="/">Home</a>
    	<a href="/about">About</a>
    	<a href="/settings">Settings</a>
    </nav>
    
    {@render children()}

If we create pages for `/`, `/about` and `/settings`...

src/routes/+page

    <h1>Home</h1>

src/routes/about/+page

    <h1>About</h1>

src/routes/settings/+page

    <h1>Settings</h1>

...the nav will always be visible, and clicking between the three pages will only result in the `<h1>` being replaced.

Layouts can be _nested_. Suppose we don’t just have a single `/settings` page, but instead have nested pages like `/settings/profile` and `/settings/notifications` with a shared submenu (for a real-life example, see [github.com/settings](https://github.com/settings)
).

We can create a layout that only applies to pages below `/settings` (while inheriting the root layout with the top-level nav):

src/routes/settings/+layout

    <script>
    	/** @type {{ data: import('./$types').LayoutData, children: import('svelte').Snippet }} */
    	let { data, children } = $props();
    </script>
    
    <h1>Settings</h1>
    
    <div class="submenu">
    	{#each data.sections as section}
    		<a href="/settings/{section.slug}">{section.title}</a>
    	{/each}
    </div>
    
    {@render children()}

    <script lang="ts">
    	import type { LayoutData } from './$types';
    	import type { Snippet } from 'svelte';
    
    	let { data, children }: { data: LayoutData, children: Snippet } = $props();
    </script>
    
    <h1>Settings</h1>
    
    <div class="submenu">
    	{#each data.sections as section}
    		<a href="/settings/{section.slug}">{section.title}</a>
    	{/each}
    </div>
    
    {@render children()}

You can see how `data` is populated by looking at the `+layout.js` example in the next section just below.

By default, each layout inherits the layout above it. Sometimes that isn’t what you want - in this case, [advanced layouts](advanced-routing#Advanced-layouts)
 can help you.

### +layout.js[](#layout-layout.js)

Just like `+page.svelte` loading data from `+page.js`, your `+layout.svelte` component can get data from a [`load`](load)
 function in `+layout.js`.

src/routes/settings/+layout

    /** @type {import('./$types').LayoutLoad} */
    export function function load(): {
        sections: {
            slug: string;
            title: string;
        }[];
    }@type{import('./$types').LayoutLoad}load() {
    	return {
    		sections: {
        slug: string;
        title: string;
    }[]sections: [\
    			{ slug: stringslug: 'profile', title: stringtitle: 'Profile' },\
    			{ slug: stringslug: 'notifications', title: stringtitle: 'Notifications' }\
    		]
    	};
    }

    import type { type LayoutLoad = (event: Kit.LoadEvent<Record<string, any>, Record<string, any> | null, Record<string, any>, string | null>) => MaybePromise<void | Record<string, any>>
    type LayoutLoad = (event: Kit.LoadEvent<Record<string, any>, Record<string, any> | null, Record<string, any>, string | null>) => MaybePromise<void | Record<string, any>>LayoutLoad } from './$types';
    
    export const const load: LayoutLoadload: type LayoutLoad = (event: Kit.LoadEvent<Record<string, any>, Record<string, any> | null, Record<string, any>, string | null>) => MaybePromise<void | Record<string, any>>
    type LayoutLoad = (event: Kit.LoadEvent<Record<string, any>, Record<string, any> | null, Record<string, any>, string | null>) => MaybePromise<void | Record<string, any>>LayoutLoad = () => {
    	return {
    		sections: {
        slug: string;
        title: string;
    }[]sections: [\
    			{ slug: stringslug: 'profile', title: stringtitle: 'Profile' },\
    			{ slug: stringslug: 'notifications', title: stringtitle: 'Notifications' }\
    		]
    	};
    };

If a `+layout.js` exports [page options](page-options)
 — `prerender`, `ssr` and `csr` — they will be used as defaults for child pages.

Data returned from a layout’s `load` function is also available to all its child pages:

src/routes/settings/profile/+page

    <script>
    	/** @type {{ data: import('./$types').PageData }} */
    	let { data } = $props();
    
    	console.log(data.sections); // [{ slug: 'profile', title: 'Profile' }, ...]
    </script>

    <script lang="ts">
    	import type { PageData } from './$types';
    
    	let { data }: { data: PageData } = $props();
    
    	console.log(data.sections); // [{ slug: 'profile', title: 'Profile' }, ...]
    </script>

> Often, layout data is unchanged when navigating between pages. SvelteKit will intelligently rerun [`load`](load)
>  functions when necessary.

### +layout.server.js[](#layout-layout.server.js)

To run your layout’s `load` function on the server, move it to `+layout.server.js`, and change the `LayoutLoad` type to `LayoutServerLoad`.

Like `+layout.js`, `+layout.server.js` can export [page options](page-options)
 — `prerender`, `ssr` and `csr`.

+server[](#server)

-------------------

As well as pages, you can define routes with a `+server.js` file (sometimes referred to as an ‘API route’ or an ‘endpoint’), which gives you full control over the response. Your `+server.js` file exports functions corresponding to HTTP verbs like `GET`, `POST`, `PATCH`, `PUT`, `DELETE`, `OPTIONS`, and `HEAD` that take a `RequestEvent` argument and return a [`Response`](https://developer.mozilla.org/en-US/docs/Web/API/Response)
 object.

For example we could create an `/api/random-number` route with a `GET` handler:

src/routes/api/random-number/+server

    import { function error(status: number, body: App.Error): never (+1 overload)Throws an error with a HTTP status code and an optional message.
    When called during request handling, this will cause SvelteKit to
    return an error response without invoking handleError.
    Make sure you’re not catching the thrown error, which would prevent SvelteKit from handling it.
    @paramstatus The HTTP status code. Must be in the range 400-599.@parambody An object that conforms to the App.Error type. If a string is passed, it will be used as the message property.@throwsHttpError This error instructs SvelteKit to initiate HTTP error handling.@throwsError If the provided status is invalid (not between 400 and 599).error } from '@sveltejs/kit';
    
    /** @type {import('./$types').RequestHandler} */
    export function function GET({ url }: {
        url: any;
    }): Response@type{import('./$types').RequestHandler}GET({ url: anyurl }) {
    	const const min: numbermin = var Number: NumberConstructor
    (value?: any) => numberAn object that represents a number of any kind. All JavaScript numbers are 64-bit floating-point numbers.
    Number(url: anyurl.searchParams.get('min') ?? '0');
    	const const max: numbermax = var Number: NumberConstructor
    (value?: any) => numberAn object that represents a number of any kind. All JavaScript numbers are 64-bit floating-point numbers.
    Number(url: anyurl.searchParams.get('max') ?? '1');
    
    	const const d: numberd = const max: numbermax - const min: numbermin;
    
    	if (function isNaN(number: number): booleanReturns a Boolean value that indicates whether a value is the reserved value NaN (not a number).
    @paramnumber A numeric value.isNaN(const d: numberd) || const d: numberd < 0) {
    		function error(status: number, body?: {
        message: string;
    } extends App.Error ? App.Error | string | undefined : never): never (+1 overload)Throws an error with a HTTP status code and an optional message.
    When called during request handling, this will cause SvelteKit to
    return an error response without invoking handleError.
    Make sure you’re not catching the thrown error, which would prevent SvelteKit from handling it.
    @paramstatus The HTTP status code. Must be in the range 400-599.@parambody An object that conforms to the App.Error type. If a string is passed, it will be used as the message property.@throwsHttpError This error instructs SvelteKit to initiate HTTP error handling.@throwsError If the provided status is invalid (not between 400 and 599).error(400, 'min and max must be numbers, and min must be less than max');
    	}
    
    	const const random: numberrandom = const min: numbermin + var Math: MathAn intrinsic object that provides basic mathematics functionality and constants.
    Math.Math.random(): numberReturns a pseudorandom number between 0 and 1.
    random() * const d: numberd;
    
    	return new var Response: new (body?: BodyInit | null, init?: ResponseInit) => ResponseThis Fetch API interface represents the response to a request.
    MDN Reference
    Response(var String: StringConstructor
    (value?: any) => stringAllows manipulation and formatting of text strings and determination and location of substrings within strings.
    String(const random: numberrandom));
    }

    import { function error(status: number, body: App.Error): never (+1 overload)Throws an error with a HTTP status code and an optional message.
    When called during request handling, this will cause SvelteKit to
    return an error response without invoking handleError.
    Make sure you’re not catching the thrown error, which would prevent SvelteKit from handling it.
    @paramstatus The HTTP status code. Must be in the range 400-599.@parambody An object that conforms to the App.Error type. If a string is passed, it will be used as the message property.@throwsHttpError This error instructs SvelteKit to initiate HTTP error handling.@throwsError If the provided status is invalid (not between 400 and 599).error } from '@sveltejs/kit';
    import type { type RequestHandler = (event: Kit.RequestEvent<Record<string, any>, string | null>) => MaybePromise<Response>
    type RequestHandler = (event: Kit.RequestEvent<Record<string, any>, string | null>) => MaybePromise<Response>RequestHandler } from './$types';
    
    export const const GET: RequestHandlerGET: type RequestHandler = (event: Kit.RequestEvent<Record<string, any>, string | null>) => MaybePromise<Response>
    type RequestHandler = (event: Kit.RequestEvent<Record<string, any>, string | null>) => MaybePromise<Response>RequestHandler = ({ url: URLThe requested URL.
    url }) => {
    	const const min: numbermin = var Number: NumberConstructor
    (value?: any) => numberAn object that represents a number of any kind. All JavaScript numbers are 64-bit floating-point numbers.
    Number(url: URLThe requested URL.
    url.URL.searchParams: URLSearchParamsMDN Reference
    searchParams.URLSearchParams.get(name: string): string | nullReturns the first value associated to the given search parameter.
    MDN Reference
    get('min') ?? '0');
    	const const max: numbermax = var Number: NumberConstructor
    (value?: any) => numberAn object that represents a number of any kind. All JavaScript numbers are 64-bit floating-point numbers.
    Number(url: URLThe requested URL.
    url.URL.searchParams: URLSearchParamsMDN Reference
    searchParams.URLSearchParams.get(name: string): string | nullReturns the first value associated to the given search parameter.
    MDN Reference
    get('max') ?? '1');
    
    	const const d: numberd = const max: numbermax - const min: numbermin;
    
    	if (function isNaN(number: number): booleanReturns a Boolean value that indicates whether a value is the reserved value NaN (not a number).
    @paramnumber A numeric value.isNaN(const d: numberd) || const d: numberd < 0) {
    		function error(status: number, body?: {
        message: string;
    } extends App.Error ? App.Error | string | undefined : never): never (+1 overload)Throws an error with a HTTP status code and an optional message.
    When called during request handling, this will cause SvelteKit to
    return an error response without invoking handleError.
    Make sure you’re not catching the thrown error, which would prevent SvelteKit from handling it.
    @paramstatus The HTTP status code. Must be in the range 400-599.@parambody An object that conforms to the App.Error type. If a string is passed, it will be used as the message property.@throwsHttpError This error instructs SvelteKit to initiate HTTP error handling.@throwsError If the provided status is invalid (not between 400 and 599).error(400, 'min and max must be numbers, and min must be less than max');
    	}
    
    	const const random: numberrandom = const min: numbermin + var Math: MathAn intrinsic object that provides basic mathematics functionality and constants.
    Math.Math.random(): numberReturns a pseudorandom number between 0 and 1.
    random() * const d: numberd;
    
    	return new var Response: new (body?: BodyInit | null, init?: ResponseInit) => ResponseThis Fetch API interface represents the response to a request.
    MDN Reference
    Response(var String: StringConstructor
    (value?: any) => stringAllows manipulation and formatting of text strings and determination and location of substrings within strings.
    String(const random: numberrandom));
    };

The first argument to `Response` can be a [`ReadableStream`](https://developer.mozilla.org/en-US/docs/Web/API/ReadableStream)
, making it possible to stream large amounts of data or create server-sent events (unless deploying to platforms that buffer responses, like AWS Lambda).

You can use the [`error`](@sveltejs-kit#error)
, [`redirect`](@sveltejs-kit#redirect)
 and [`json`](@sveltejs-kit#json)
 methods from `@sveltejs/kit` for convenience (but you don’t have to).

If an error is thrown (either `error(...)` or an unexpected error), the response will be a JSON representation of the error or a fallback error page — which can be customised via `src/error.html` — depending on the `Accept` header. The [`+error.svelte`](#error)
 component will _not_ be rendered in this case. You can read more about error handling [here](errors)
.

> When creating an `OPTIONS` handler, note that Vite will inject `Access-Control-Allow-Origin` and `Access-Control-Allow-Methods` headers — these will not be present in production unless you add them.

> `+layout` files have no effect on `+server.js` files. If you want to run some logic before each request, add it to the server [`handle`](hooks#Server-hooks-handle)
>  hook.

### Receiving data[](#server-Receiving-data)

By exporting `POST` / `PUT`/`PATCH`/`DELETE`/`OPTIONS`/`HEAD` handlers, `+server.js` files can be used to create a complete API:

src/routes/add/+page

    <script>
    	let a = 0;
    	let b = 0;
    	let total = 0;
    
    	async function add() {
    		const response = await fetch('/api/add', {
    			method: 'POST',
    			body: JSON.stringify({ a, b }),
    			headers: {
    				'content-type': 'application/json'
    			}
    		});
    
    		total = await response.json();
    	}
    </script>
    
    <input type="number" bind:value={a}> +
    <input type="number" bind:value={b}> =
    {total}
    
    <button onclick={add}>Calculate</button>

    <script lang="ts">
    	let a = 0;
    	let b = 0;
    	let total = 0;
    
    	async function add() {
    		const response = await fetch('/api/add', {
    			method: 'POST',
    			body: JSON.stringify({ a, b }),
    			headers: {
    				'content-type': 'application/json'
    			}
    		});
    
    		total = await response.json();
    	}
    </script>
    
    <input type="number" bind:value={a}> +
    <input type="number" bind:value={b}> =
    {total}
    
    <button onclick={add}>Calculate</button>

src/routes/api/add/+server

    import { function json(data: any, init?: ResponseInit | undefined): ResponseCreate a JSON Response object from the supplied data.
    @paramdata The value that will be serialized as JSON.@paraminit Options such as status and headers that will be added to the response. Content-Type: application/json and Content-Length headers will be added automatically.json } from '@sveltejs/kit';
    
    /** @type {import('./$types').RequestHandler} */
    export async function function POST({ request }: {
        request: any;
    }): Promise<Response>@type{import('./$types').RequestHandler}POST({ request: anyrequest }) {
    	const { const a: anya, const b: anyb } = await request: anyrequest.json();
    	return function json(data: any, init?: ResponseInit | undefined): ResponseCreate a JSON Response object from the supplied data.
    @paramdata The value that will be serialized as JSON.@paraminit Options such as status and headers that will be added to the response. Content-Type: application/json and Content-Length headers will be added automatically.json(const a: anya + const b: anyb);
    }

    import { function json(data: any, init?: ResponseInit | undefined): ResponseCreate a JSON Response object from the supplied data.
    @paramdata The value that will be serialized as JSON.@paraminit Options such as status and headers that will be added to the response. Content-Type: application/json and Content-Length headers will be added automatically.json } from '@sveltejs/kit';
    import type { type RequestHandler = (event: Kit.RequestEvent<Record<string, any>, string | null>) => MaybePromise<Response>
    type RequestHandler = (event: Kit.RequestEvent<Record<string, any>, string | null>) => MaybePromise<Response>RequestHandler } from './$types';
    
    export const const POST: RequestHandlerPOST: type RequestHandler = (event: Kit.RequestEvent<Record<string, any>, string | null>) => MaybePromise<Response>
    type RequestHandler = (event: Kit.RequestEvent<Record<string, any>, string | null>) => MaybePromise<Response>RequestHandler = async ({ request: RequestThe original request object
    request }) => {
    	const { const a: anya, const b: anyb } = await request: RequestThe original request object
    request.Body.json(): Promise<any>MDN Reference
    json();
    	return function json(data: any, init?: ResponseInit | undefined): ResponseCreate a JSON Response object from the supplied data.
    @paramdata The value that will be serialized as JSON.@paraminit Options such as status and headers that will be added to the response. Content-Type: application/json and Content-Length headers will be added automatically.json(const a: anya + const b: anyb);
    };

> In general, [form actions](form-actions)
>  are a better way to submit data from the browser to the server.

> If a `GET` handler is exported, a `HEAD` request will return the `content-length` of the `GET` handler’s response body.

### Fallback method handler[](#server-Fallback-method-handler)

Exporting the `fallback` handler will match any unhandled request methods, including methods like `MOVE` which have no dedicated export from `+server.js`.

src/routes/api/add/+server

    import { function json(data: any, init?: ResponseInit | undefined): ResponseCreate a JSON Response object from the supplied data.
    @paramdata The value that will be serialized as JSON.@paraminit Options such as status and headers that will be added to the response. Content-Type: application/json and Content-Length headers will be added automatically.json, function text(body: string, init?: ResponseInit | undefined): ResponseCreate a Response object from the supplied body.
    @parambody The value that will be used as-is.@paraminit Options such as status and headers that will be added to the response. A Content-Length header will be added automatically.text } from '@sveltejs/kit';
    
    export async function function POST({ request }: {
        request: any;
    }): Promise<Response>POST({ request: anyrequest }) {
    	const { const a: anya, const b: anyb } = await request: anyrequest.json();
    	return function json(data: any, init?: ResponseInit | undefined): ResponseCreate a JSON Response object from the supplied data.
    @paramdata The value that will be serialized as JSON.@paraminit Options such as status and headers that will be added to the response. Content-Type: application/json and Content-Length headers will be added automatically.json(const a: anya + const b: anyb);
    }
    
    // This handler will respond to PUT, PATCH, DELETE, etc.
    /** @type {import('./$types').RequestHandler} */
    export async function function fallback({ request }: {
        request: any;
    }): Promise<Response>@type{import('./$types').RequestHandler}fallback({ request: anyrequest }) {
    	return function text(body: string, init?: ResponseInit | undefined): ResponseCreate a Response object from the supplied body.
    @parambody The value that will be used as-is.@paraminit Options such as status and headers that will be added to the response. A Content-Length header will be added automatically.text(`I caught your ${request: anyrequest.method} request!`);
    }

    import { function json(data: any, init?: ResponseInit | undefined): ResponseCreate a JSON Response object from the supplied data.
    @paramdata The value that will be serialized as JSON.@paraminit Options such as status and headers that will be added to the response. Content-Type: application/json and Content-Length headers will be added automatically.json, function text(body: string, init?: ResponseInit | undefined): ResponseCreate a Response object from the supplied body.
    @parambody The value that will be used as-is.@paraminit Options such as status and headers that will be added to the response. A Content-Length header will be added automatically.text } from '@sveltejs/kit';
    import type { type RequestHandler = (event: Kit.RequestEvent<Record<string, any>, string | null>) => MaybePromise<Response>
    type RequestHandler = (event: Kit.RequestEvent<Record<string, any>, string | null>) => MaybePromise<Response>RequestHandler } from './$types';
    
    export async function function POST({ request }: {
        request: any;
    }): Promise<Response>POST({ request: anyrequest }) {
    	const { const a: anya, const b: anyb } = await request: anyrequest.json();
    	return function json(data: any, init?: ResponseInit | undefined): ResponseCreate a JSON Response object from the supplied data.
    @paramdata The value that will be serialized as JSON.@paraminit Options such as status and headers that will be added to the response. Content-Type: application/json and Content-Length headers will be added automatically.json(const a: anya + const b: anyb);
    }
    
    // This handler will respond to PUT, PATCH, DELETE, etc.
    export const const fallback: RequestHandlerfallback: type RequestHandler = (event: Kit.RequestEvent<Record<string, any>, string | null>) => MaybePromise<Response>
    type RequestHandler = (event: Kit.RequestEvent<Record<string, any>, string | null>) => MaybePromise<Response>RequestHandler = async ({ request: RequestThe original request object
    request }) => {
    	return function text(body: string, init?: ResponseInit | undefined): ResponseCreate a Response object from the supplied body.
    @parambody The value that will be used as-is.@paraminit Options such as status and headers that will be added to the response. A Content-Length header will be added automatically.text(`I caught your ${request: RequestThe original request object
    request.Request.method: stringReturns request’s HTTP method, which is “GET” by default.
    MDN Reference
    method} request!`);
    };

> For `HEAD` requests, the `GET` handler takes precedence over the `fallback` handler.

### Content negotiation[](#server-Content-negotiation)

`+server.js` files can be placed in the same directory as `+page` files, allowing the same route to be either a page or an API endpoint. To determine which, SvelteKit applies the following rules:

*   `PUT` / `PATCH`/`DELETE`/`OPTIONS` requests are always handled by `+server.js` since they do not apply to pages
*   `GET` / `POST`/`HEAD` requests are treated as page requests if the `accept` header prioritises `text/html` (in other words, it’s a browser page request), else they are handled by `+server.js`.
*   Responses to `GET` requests will include a `Vary: Accept` header, so that proxies and browsers cache HTML and JSON responses separately.

$types[](#$types)

------------------

Throughout the examples above, we’ve been importing types from a `$types.d.ts` file. This is a file SvelteKit creates for you in a hidden directory if you’re using TypeScript (or JavaScript with JSDoc type annotations) to give you type safety when working with your root files.

For example, annotating `let { data } = $props()` with `PageData` (or `LayoutData`, for a `+layout.svelte` file) tells TypeScript that the type of `data` is whatever was returned from `load`:

src/routes/blog/\[slug\]/+page

    <script>
    	/** @type {{ data: import('./$types').PageData }} */
    	let { data } = $props();
    </script>

    <script lang="ts">
    	import type { PageData } from './$types';
    
    	let { data }: { data: PageData } = $props();
    </script>

In turn, annotating the `load` function with `PageLoad`, `PageServerLoad`, `LayoutLoad` or `LayoutServerLoad` (for `+page.js`, `+page.server.js`, `+layout.js` and `+layout.server.js` respectively) ensures that `params` and the return value are correctly typed.

If you’re using VS Code or any IDE that supports the language server protocol and TypeScript plugins then you can omit these types _entirely_! Svelte’s IDE tooling will insert the correct types for you, so you’ll get type checking without writing them yourself. It also works with our command line tool `svelte-check`.

You can read more about omitting `$types` in our [blog post](/blog/zero-config-type-safety)
 about it.

Other files[](#Other-files)

----------------------------

Any other files inside a route directory are ignored by SvelteKit. This means you can colocate components and utility modules with the routes that need them.

If components and modules are needed by multiple routes, it’s a good idea to put them in [`$lib`]($lib)
.

Further reading[](#Further-reading)

------------------------------------

*   [Tutorial: Routing](/tutorial/kit/pages)
    
*   [Tutorial: API routes](/tutorial/kit/get-handlers)
    
*   [Docs: Advanced routing](advanced-routing)
    

[Edit this page on GitHub](https://github.com/sveltejs/kit/edit/main/documentation/docs/20-core-concepts/10-routing.md)

previous next

[Web standards](/docs/kit/web-standards)
 [Loading data](/docs/kit/load)

---

# Static site generation • Docs • Svelte

[Skip to main content](#main)

To use SvelteKit as a static site generator (SSG), use [`adapter-static`](https://github.com/sveltejs/kit/tree/main/packages/adapter-static)
.

This will prerender your entire site as a collection of static files. If you’d like to prerender only some pages and dynamically server-render others, you will need to use a different adapter together with [the `prerender` option](page-options#prerender)
.

Usage[](#Usage)

----------------

Install with `npm i -D @sveltejs/adapter-static`, then add the adapter to your `svelte.config.js`:

svelte.config

    import import adapteradapter from '@sveltejs/adapter-static';
    
    export default {
    	kit: {
        adapter: any;
    }kit: {
    		adapter: anyadapter: import adapteradapter({
    			// default options are shown. On some platforms
    			// these options are set automatically — see below
    			pages: stringpages: 'build',
    			assets: stringassets: 'build',
    			fallback: undefinedfallback: var undefinedundefined,
    			precompress: booleanprecompress: false,
    			strict: booleanstrict: true
    		})
    	}
    };

...and add the [`prerender`](page-options#prerender)
 option to your root layout:

src/routes/+layout

    // This can be false if you're using a fallback (i.e. SPA mode)
    export const const prerender: trueprerender = true;

> You must ensure SvelteKit’s [`trailingSlash`](page-options#trailingSlash)
>  option is set appropriately for your environment. If your host does not render `/a.html` upon receiving a request for `/a` then you will need to set `trailingSlash: 'always'` in your root layout to create `/a/index.html` instead.

Zero-config support[](#Zero-config-support)

--------------------------------------------

Some platforms have zero-config support (more to come in future):

*   [Vercel](https://vercel.com)
    

On these platforms, you should omit the adapter options so that `adapter-static` can provide the optimal configuration:

svelte.config

    export default {
    	kit: {
        adapter: any;
    }kit: {
    		adapter: anyadapter: adapter({...})
    	}
    };

Options[](#Options)

--------------------

### pages[](#Options-pages)

The directory to write prerendered pages to. It defaults to `build`.

### assets[](#Options-assets)

The directory to write static assets (the contents of `static`, plus client-side JS and CSS generated by SvelteKit) to. Ordinarily this should be the same as `pages`, and it will default to whatever the value of `pages` is, but in rare circumstances you might need to output pages and assets to separate locations.

### fallback[](#Options-fallback)

Specify a fallback page for [SPA mode](single-page-apps)
, e.g. `index.html` or `200.html` or `404.html`.

### precompress[](#Options-precompress)

If `true`, precompresses files with brotli and gzip. This will generate `.br` and `.gz` files.

### strict[](#Options-strict)

By default, `adapter-static` checks that either all pages and endpoints (if any) of your app were prerendered, or you have the `fallback` option set. This check exists to prevent you from accidentally publishing an app where some parts of it are not accessible, because they are not contained in the final output. If you know this is ok (for example when a certain page only exists conditionally), you can set `strict` to `false` to turn off this check.

GitHub Pages[](#GitHub-Pages)

------------------------------

When building for [GitHub Pages](https://docs.github.com/en/pages/getting-started-with-github-pages/about-github-pages)
, if your repo name is not equivalent to `your-username.github.io`, make sure to update [`config.kit.paths.base`](configuration#paths)
 to match your repo name. This is because the site will be served from `https://your-username.github.io/your-repo-name` rather than from the root.

You’ll also want to generate a fallback `404.html` page to replace the default 404 page shown by GitHub Pages.

A config for GitHub Pages might look like the following:

svelte.config

    import import adapteradapter from '@sveltejs/adapter-static';
    
    /** @type {import('@sveltejs/kit').Config} */
    const const config: {
        kit: {
            adapter: any;
            paths: {
     base: string | undefined;
            };
        };
    }@type{import('@sveltejs/kit').Config}config = {
    	kit: {
        adapter: any;
        paths: {
            base: string | undefined;
        };
    }kit: {
    		adapter: anyadapter: import adapteradapter({
    			fallback: stringfallback: '404.html'
    		}),
    		paths: {
        base: string | undefined;
    }paths: {
    			base: string | undefinedbase: var process: NodeJS.Processprocess.NodeJS.Process.argv: string[]The process.argv property returns an array containing the command-line
    arguments passed when the Node.js process was launched. The first element will
    be 
    {@link 
    execPath
    }
    . See process.argv0 if access to the original value
    of argv[0] is needed. The second element will be the path to the JavaScript
    file being executed. The remaining elements will be any additional command-line
    arguments.
    For example, assuming the following script for process-args.js:
    import { argv } from 'node:process';
    
    // print process.argv
    argv.forEach((val, index) => {
      console.log(`${index}: ${val}`);
    });Launching the Node.js process as:
    node process-args.js one two=three fourWould generate the output:
    0: /usr/local/bin/node
    1: /Users/mjr/work/node/process-args.js
    2: one
    3: two=three
    4: four@sincev0.1.27argv.Array<string>.includes(searchElement: string, fromIndex?: number): booleanDetermines whether an array includes a certain element, returning true or false as appropriate.
    @paramsearchElement The element to search for.@paramfromIndex The position in this array at which to begin searching for searchElement.includes('dev') ? '' : var process: NodeJS.Processprocess.NodeJS.Process.env: NodeJS.ProcessEnvThe process.env property returns an object containing the user environment.
    See environ(7).
    An example of this object looks like:
    {
      TERM: 'xterm-256color',
      SHELL: '/usr/local/bin/bash',
      USER: 'maciej',
      PATH: '~/.bin/:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin',
      PWD: '/Users/maciej',
      EDITOR: 'vim',
      SHLVL: '1',
      HOME: '/Users/maciej',
      LOGNAME: 'maciej',
      _: '/usr/local/bin/node'
    }It is possible to modify this object, but such modifications will not be
    reflected outside the Node.js process, or (unless explicitly requested)
    to other Worker threads.
    In other words, the following example would not work:
    node -e 'process.env.foo = "bar"' &#x26;#x26;&#x26;#x26; echo $fooWhile the following will:
    import { env } from 'node:process';
    
    env.foo = 'bar';
    console.log(env.foo);Assigning a property on process.env will implicitly convert the value
    to a string. This behavior is deprecated. Future versions of Node.js may
    throw an error when the value is not a string, number, or boolean.
    import { env } from 'node:process';
    
    env.test = null;
    console.log(env.test);
    // => 'null'
    env.test = undefined;
    console.log(env.test);
    // => 'undefined'Use delete to delete a property from process.env.
    import { env } from 'node:process';
    
    env.TEST = 1;
    delete env.TEST;
    console.log(env.TEST);
    // => undefinedOn Windows operating systems, environment variables are case-insensitive.
    import { env } from 'node:process';
    
    env.TEST = 1;
    console.log(env.test);
    // => 1Unless explicitly specified when creating a Worker instance,
    each Worker thread has its own copy of process.env, based on its
    parent thread’s process.env, or whatever was specified as the env option
    to the Worker constructor. Changes to process.env will not be visible
    across Worker threads, and only the main thread can make changes that
    are visible to the operating system or to native add-ons. On Windows, a copy of process.env on a Worker instance operates in a case-sensitive manner
    unlike the main thread.
    @sincev0.1.27env.string | undefinedBASE_PATH
    		}
    	}
    };
    
    export default const config: {
        kit: {
            adapter: any;
            paths: {
     base: string | undefined;
            };
        };
    }@type{import('@sveltejs/kit').Config}config;

You can use GitHub actions to automatically deploy your site to GitHub Pages when you make a change. Here’s an example workflow:

.github/workflows/deploy

    name: Deploy to GitHub Pages
    
    on:
      push:
        branches: 'main'
    
    jobs:
      build_site:
        runs-on: ubuntu-latest
        steps:
          - name: Checkout
            uses: actions/checkout@v4
    
          # If you're using pnpm, add this step then change the commands and cache key below to use `pnpm`
          # - name: Install pnpm
          #   uses: pnpm/action-setup@v3
          #   with:
          #     version: 8
    
          - name: Install Node.js
            uses: actions/setup-node@v4
            with:
     node-version: 20
     cache: npm
    
          - name: Install dependencies
            run: npm install
    
          - name: build
            env:
     BASE_PATH: '/${{ github.event.repository.name }}'
            run: |
     npm run build
    
          - name: Upload Artifacts
            uses: actions/upload-pages-artifact@v3
            with:
     # this should match the `pages` option in your adapter-static options
     path: 'build/'
    
      deploy:
        needs: build_site
        runs-on: ubuntu-latest
    
        permissions:
          pages: write
          id-token: write
    
        environment:
          name: github-pages
          url: ${{ steps.deployment.outputs.page_url }}
    
        steps:
          - name: Deploy
            id: deployment
            uses: actions/deploy-pages@v4

If you’re not using GitHub actions to deploy your site (for example, you’re pushing the built site to its own repo), add an empty `.nojekyll` file in your `static` directory to prevent Jekyll from interfering.

[Edit this page on GitHub](https://github.com/sveltejs/kit/edit/main/documentation/docs/25-build-and-deploy/50-adapter-static.md)

previous next

[Node servers](/docs/kit/adapter-node)
 [Single-page apps](/docs/kit/single-page-apps)

---

# Single-page apps • Docs • Svelte

[Skip to main content](#main)

You can turn any SvelteKit app, using any adapter, into a fully client-rendered single-page app (SPA) by disabling SSR at the root layout:

src/routes/+layout

    export const const ssr: falsessr = false;

> In most situations this is not recommended: it harms SEO, tends to slow down perceived performance, and makes your app inaccessible to users if JavaScript fails or is disabled (which happens [more often than you probably think](https://kryogenix.org/code/browser/everyonehasjs.html)
> ).

If you don’t have any server-side logic (i.e. `+page.server.js`, `+layout.server.js` or `+server.js` files) you can use [`adapter-static`](adapter-static)
 to create your SPA by adding a _fallback page_.

Usage[](#Usage)

----------------

Install with `npm i -D @sveltejs/adapter-static`, then add the adapter to your `svelte.config.js` with the following options:

svelte.config

    import import adapteradapter from '@sveltejs/adapter-static';
    
    export default {
    	kit: {
        adapter: any;
    }kit: {
    		adapter: anyadapter: import adapteradapter({
    			fallback: stringfallback: '200.html' // may differ from host to host
    		})
    	}
    };

The `fallback` page is an HTML page created by SvelteKit from your page template (e.g. `app.html`) that loads your app and navigates to the correct route. For example [Surge](https://surge.sh/help/adding-a-200-page-for-client-side-routing)
, a static web host, lets you add a `200.html` file that will handle any requests that don’t correspond to static assets or prerendered pages.

On some hosts it may be `index.html` or something else entirely — consult your platform’s documentation.

> Note that the fallback page will always contain absolute asset paths (i.e. beginning with `/` rather than `.`) regardless of the value of [`paths.relative`](configuration#paths)
> , since it is used to respond to requests for arbitrary paths.

Apache[](#Apache)

------------------

To run an SPA on [Apache](https://httpd.apache.org/)
, you should add a `static/.htaccess` file to route requests to the fallback page:

    <IfModule mod_rewrite.c>
    	RewriteEngine On
    	RewriteBase /
    	RewriteRule ^200\.html$ - [L]
    	RewriteCond %{REQUEST_FILENAME} !-f
    	RewriteCond %{REQUEST_FILENAME} !-d
    	RewriteRule . /200.html [L]
    </IfModule>

Prerendering individual pages[](#Prerendering-individual-pages)

----------------------------------------------------------------

If you want certain pages to be prerendered, you can re-enable `ssr` alongside `prerender` for just those parts of your app:

src/routes/my-prerendered-page/+page

    export const const prerender: trueprerender = true;
    export const const ssr: truessr = true;

[Edit this page on GitHub](https://github.com/sveltejs/kit/edit/main/documentation/docs/25-build-and-deploy/55-single-page-apps.md)

previous next

[Static site generation](/docs/kit/adapter-static)
 [Cloudflare Pages](/docs/kit/adapter-cloudflare)

---

# Cloudflare Pages • Docs • Svelte

[Skip to main content](#main)

To deploy to [Cloudflare Pages](https://developers.cloudflare.com/pages/)
, use [`adapter-cloudflare`](https://github.com/sveltejs/kit/tree/main/packages/adapter-cloudflare)
.

This adapter will be installed by default when you use [`adapter-auto`](adapter-auto)
. If you plan on staying with Cloudflare Pages, you can switch from [`adapter-auto`](adapter-auto)
 to using this adapter directly so that values specific to Cloudflare Workers are emulated during local development, type declarations are automatically applied, and the ability to set Cloudflare-specific options is provided.

Comparisons[](#Comparisons)

----------------------------

*   `adapter-cloudflare` – supports all SvelteKit features; builds for [Cloudflare Pages](https://blog.cloudflare.com/cloudflare-pages-goes-full-stack/)
    
*   `adapter-cloudflare-workers` – supports all SvelteKit features; builds for Cloudflare Workers
*   `adapter-static` – only produces client-side static assets; compatible with Cloudflare Pages

Usage[](#Usage)

----------------

Install with `npm i -D @sveltejs/adapter-cloudflare`, then add the adapter to your `svelte.config.js`:

svelte.config

    import import adapteradapter from '@sveltejs/adapter-cloudflare';
    
    export default {
    	kit: {
        adapter: any;
    }kit: {
    		adapter: anyadapter: import adapteradapter({
    			// See below for an explanation of these options
    			routes: {
        include: string[];
        exclude: string[];
    }routes: {
    				include: string[]include: ['/*'],
    				exclude: string[]exclude: ['<all>']
    			},
    			platformProxy: {
        configPath: string;
        environment: undefined;
        experimentalJsonConfig: boolean;
        persist: boolean;
    }platformProxy: {
    				configPath: stringconfigPath: 'wrangler.toml',
    				environment: undefinedenvironment: var undefinedundefined,
    				experimentalJsonConfig: booleanexperimentalJsonConfig: false,
    				persist: booleanpersist: false
    			}
    		})
    	}
    };

Options[](#Options)

--------------------

### routes[](#Options-routes)

Allows you to customise the [`_routes.json`](https://developers.cloudflare.com/pages/platform/functions/routing/#create-a-_routesjson-file)
 file generated by `adapter-cloudflare`.

*   `include` defines routes that will invoke a function, and defaults to `['/*']`
*   `exclude` defines routes that will _not_ invoke a function — this is a faster and cheaper way to serve your app’s static assets. This array can include the following special values:
    *   `<build>` contains your app’s build artifacts (the files generated by Vite)
    *   `<files>` contains the contents of your `static` directory
    *   `<prerendered>` contains a list of prerendered pages
    *   `<all>` (the default) contains all of the above

You can have up to 100 `include` and `exclude` rules combined. Generally you can omit the `routes` options, but if (for example) your `<prerendered>` paths exceed that limit, you may find it helpful to manually create an `exclude` list that includes `'/articles/*'` instead of the auto-generated `['/articles/foo', '/articles/bar', '/articles/baz', ...]`.

### platformProxy[](#Options-platformProxy)

Preferences for the emulated `platform.env` local bindings. See the [getPlatformProxy](https://developers.cloudflare.com/workers/wrangler/api/#syntax)
 Wrangler API documentation for a full list of options.

Deployment[](#Deployment)

--------------------------

Please follow the [Get Started Guide](https://developers.cloudflare.com/pages/get-started)
 for Cloudflare Pages to begin.

When configuring your project settings, you must use the following settings:

*   **Framework preset** – SvelteKit
*   **Build command** – `npm run build` or `vite build`
*   **Build output directory** – `.svelte-kit/cloudflare`

Runtime APIs[](#Runtime-APIs)

------------------------------

The [`env`](https://developers.cloudflare.com/workers/runtime-apis/fetch-event#parameters)
 object contains your project’s [bindings](https://developers.cloudflare.com/pages/platform/functions/bindings/)
, which consist of KV/DO namespaces, etc. It is passed to SvelteKit via the `platform` property, along with [`context`](https://developers.cloudflare.com/workers/runtime-apis/handlers/fetch/#contextwaituntil)
, [`caches`](https://developers.cloudflare.com/workers/runtime-apis/cache/)
, and [`cf`](https://developers.cloudflare.com/workers/runtime-apis/request/#the-cf-property-requestinitcfproperties)
, meaning that you can access it in hooks and endpoints:

    export async function function POST({ request, platform }: {
        request: any;
        platform: any;
    }): Promise<void>POST({ request, platform }) {
    
    	const const x: anyx = platform: anyplatform.env.YOUR_DURABLE_OBJECT_NAMESPACE.idFromName('x');
    }

> SvelteKit’s built-in `$env` module should be preferred for environment variables.

To include type declarations for your bindings, reference them in your `src/app.d.ts`:

src/app.d

    import { interface KVNamespace<Key extends string = string>KVNamespace, interface DurableObjectNamespace<T extends Rpc.DurableObjectBranded | undefined = undefined>DurableObjectNamespace } from '@cloudflare/workers-types';
    
    declare global {
    	namespace App {
    		interface interface App.PlatformIf your adapter provides platform-specific context via event.platform, you can specify it here.
    Platform {
    			App.Platform.env?: {
        YOUR_KV_NAMESPACE: KVNamespace;
        YOUR_DURABLE_OBJECT_NAMESPACE: DurableObjectNamespace;
    } | undefinedenv?: {
    				type YOUR_KV_NAMESPACE: KVNamespace<string>YOUR_KV_NAMESPACE: interface KVNamespace<Key extends string = string>KVNamespace;
    				type YOUR_DURABLE_OBJECT_NAMESPACE: DurableObjectNamespace<undefined>YOUR_DURABLE_OBJECT_NAMESPACE: interface DurableObjectNamespace<T extends Rpc.DurableObjectBranded | undefined = undefined>DurableObjectNamespace;
    			};
    		}
    	}
    }
    
    export {};

### Testing Locally[](#Runtime-APIs-Testing-Locally)

Cloudflare Workers specific values in the `platform` property are emulated during dev and preview modes. Local [bindings](https://developers.cloudflare.com/workers/wrangler/configuration/#bindings)
 are created based on the configuration in your `wrangler.toml` file and are used to populate `platform.env` during development and preview. Use the adapter config [`platformProxy` option](#Options-platformProxy)
 to change your preferences for the bindings.

For testing the build, you should use [wrangler](https://developers.cloudflare.com/workers/cli-wrangler)
 **version 3**. Once you have built your site, run `wrangler pages dev .svelte-kit/cloudflare`.

Notes[](#Notes)

----------------

Functions contained in the `/functions` directory at the project’s root will _not_ be included in the deployment, which is compiled to a [single `_worker.js` file](https://developers.cloudflare.com/pages/platform/functions/#advanced-mode)
. Functions should be implemented as [server endpoints](routing#server)
 in your SvelteKit app.

The `_headers` and `_redirects` files specific to Cloudflare Pages can be used for static asset responses (like images) by putting them into the `/static` folder.

However, they will have no effect on responses dynamically rendered by SvelteKit, which should return custom headers or redirect responses from [server endpoints](routing#server)
 or with the [`handle`](hooks#Server-hooks-handle)
 hook.

Troubleshooting[](#Troubleshooting)

------------------------------------

### Further reading[](#Troubleshooting-Further-reading)

You may wish to refer to [Cloudflare’s documentation for deploying a SvelteKit site](https://developers.cloudflare.com/pages/framework-guides/deploy-a-svelte-site)
.

### Accessing the file system[](#Troubleshooting-Accessing-the-file-system)

You can’t use `fs` in Cloudflare Workers — you must [prerender](page-options#prerender)
 the routes in question.

[Edit this page on GitHub](https://github.com/sveltejs/kit/edit/main/documentation/docs/25-build-and-deploy/60-adapter-cloudflare.md)

previous next

[Single-page apps](/docs/kit/single-page-apps)
 [Cloudflare Workers](/docs/kit/adapter-cloudflare-workers)

---