The Netlify adapter for SvelteKit is actually a build tool that transforms your SvelteKit app into a set of static assets and serverless functions, optimized for Netlify’s infrastructure.
Let’s see it in action. Imagine you have a simple SvelteKit app.
<!-- src/routes/+page.svelte -->
<script>
export let data;
</script>
<h1>Hello, {data.name}!</h1>
<p>This page was rendered on the server.</p>
// src/routes/+page.js
export async function load({ fetch }) {
const res = await fetch('/api/hello');
const data = await res.json();
return data;
}
// src/routes/api/hello/+server.js
import { json } from '@sveltejs/kit';
export function GET() {
return json({ name: 'Netlify Adapter' });
}
To deploy this to Netlify using the adapter, you’ll need to install it:
npm install -D @sveltejs/adapter-netlify
Then, configure your svelte.config.js:
// svelte.config.js
import adapter from '@sveltejs/adapter-netlify';
/** @type {import('@sveltejs/kit').Config} */
const config = {
kit: {
adapter: adapter()
}
};
export default config;
When you run npm run build, the @sveltejs/adapter-netlify will create a netlify directory in your project’s root. This directory contains:
index.html: The static entry point for your application._headers: Netlify’s header configuration file._redirects: Netlify’s redirect configuration file.api/directory: This will contain your serverless functions, typically built as Node.js functions.
Netlify reads these files during its build process. It deploys the static assets (index.html, CSS, JS, images) to its CDN and deploys the serverless functions (from the api/ directory) to its serverless platform. When a user requests a page, Netlify serves the static asset if available, or routes the request to the appropriate serverless function for dynamic rendering or API calls.
The core problem this adapter solves is bridging the gap between SvelteKit’s versatile rendering modes (SSR, SSG, SPA) and Netlify’s specific deployment targets. Without an adapter, you’d have to manually configure your build to output static files and then figure out how to deploy server-side logic to Netlify’s Functions. The adapter automates this, ensuring SvelteKit’s rendering capabilities are translated into Netlify-compatible formats.
You have several levers to control how the adapter behaves. The most common is edge, which defaults to false. Setting edge: true deploys your serverless functions to Netlify’s Edge Functions, which are geographically distributed and can offer lower latency for users worldwide.
// svelte.config.js
import adapter from '@sveltejs/adapter-netlify';
/** @type {import('@sveltejs/kit').Config} */
const config = {
kit: {
adapter: adapter({
edge: true
})
}
};
export default config;
Another significant option is split = true. When split is enabled (it’s false by default), the adapter will bundle your serverless functions into smaller chunks. This is particularly useful for larger applications where a single monolithic function might exceed deployment size limits or take too long to initialize. Instead, split creates multiple, smaller functions, often organized by route, which can improve cold start times and manageability.
The functionRoutes option allows you to explicitly define which SvelteKit routes should be handled by serverless functions. By default, all dynamic routes and API routes are candidates. However, you might want to force a static route to be rendered dynamically for some reason, or conversely, ensure a dynamic route is not rendered by a function.
// svelte.config.js
import adapter from '@sveltejs/adapter-netlify';
/** @type {import('@sveltejs/kit').Config} */
const config = {
kit: {
adapter: adapter({
functionRoutes: {
// Force /admin to be a serverless function
'/admin': true,
// Prevent /static-page from being a serverless function
'/static-page': false
}
})
}
};
export default config;
When you configure adapter-netlify with edge: true, it doesn’t just copy your server-side code; it transforms it to run within Netlify’s Edge Functions runtime. This involves ensuring your code is compatible with the Edge Functions API, which is based on the Web Standards API, rather than the Node.js API. This means things like process.env might behave differently, and certain Node.js-specific modules might not be available. The adapter handles much of this translation, but it’s a key difference to be aware of if you’re migrating existing SSR code.
The next thing you’ll likely encounter is optimizing function performance and managing Netlify’s build minutes.