Learn SvelteKit - Deployment & Hosting

#Introduction

Code that never ships is useless. Episode 20 covers SvelteKit deployment and hosting: the available targets, the differences between serverless and edge runtimes, how to optimize the build, and a safe workflow for production releases.

SvelteKit separates the application from the execution environment through adapters. The same codebase can be deployed to Vercel, Netlify, Cloudflare, or your own server by only swapping the adapter. The choice of platform is usually driven by requirements: data location, budget, and platform features.

After this episode, you can choose the right platform, prepare a correct production configuration, and release without drama.

Throughout this episode the term adapter appears often. Think of an adapter as a bridge: it takes the SvelteKit build output and adapts it to the platform's contract, so the application code does not need to change when you switch hosting.

#Deployment Targets and Adapters

#Choosing an Adapter

Adapters turn the build output into the shape the target platform understands. @sveltejs/adapter-auto picks the adapter automatically at deploy time, while a specific adapter gives more control, for example over routing and caching.

Node adapter for self-hosting

import adapter from "@sveltejs/adapter-node";
 
export default {
    kit: {
        adapter: adapter({ out: "build" })
    }
};

The auto adapter reads the indicators left by the platform at build time and picks the right implementation. For production, though, use an explicit adapter so behavior is predictable and does not depend on the build environment.

#Official Adapters

SvelteKit provides official adapters covering almost all common targets. Install only the adapters you actually use to keep the dependency footprint minimal.

npm install -D @sveltejs/adapter-vercel
npm install -D @sveltejs/adapter-netlify
npm install -D @sveltejs/adapter-cloudflare
npm install -D @sveltejs/adapter-node
npm install -D @sveltejs/adapter-static

Choose based on the hosting platform you use; each adapter's documentation explains the platform-specific settings.

#Managed Platforms vs Self-Hosting

Vercel, Netlify, and Cloudflare Pages handle builds, TLS, and CDN automatically; you just push. Self-hosting with adapter-node gives full control over the runtime, but you must manage the server, load balancer, and monitoring yourself. Choose according to your team's ability to run operations.

For a tidy self-host, wrap the adapter-node build output in a Docker image. A multi-stage image keeps the final result small because it only contains the runtime and build output.

FROM node:22-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build
 
FROM node:22-alpine
WORKDIR /app
COPY --from=build /app/build ./
ENV NODE_ENV=production
EXPOSE 3000
CMD ["node", "build/index.js"]

The command docker build -t sveltekit-app . produces an image ready to run anywhere Docker is available.

#Serverless vs Edge Runtime

#The Key Differences

Serverless runs code in a specific region with large resources, suited to heavy tasks like database queries. Edge runs code near the user across the world with very fast start-up, suited to low-latency responses, but with stricter resource and API limits.

Cloudflare adapter for the edge

import adapter from "@sveltejs/adapter-cloudflare";
 
export default {
    kit: {
        adapter: adapter()
    }
};

#Adapting Code to the Runtime

The edge runtime does not support every Node.js API. Make sure the libraries you use are compatible with the target runtime, and use the matching adapters. For applications that need both, split the routes: static and light pages on the edge, heavy routes on serverless.

As an example, access to the file system or certain Node environment variables works on serverless but not on the edge. Create a small abstraction layer in src/lib/server so business logic is not tied to a specific runtime.

#Optimizing Builds and Asset Deployment

#Efficient Builds

Build the app with npm run build and inspect the output. Static pages are prerendered, JavaScript is split per route, and assets are hashed. Use the generated output to serve through a CDN so assets do not always pass through the application server.

npm install -D @sveltejs/adapter-vercel
npx vercel --prod

#Assets and Environment in Production

Every platform has its own way of setting production environment variables: dashboard, config file, or CLI. Make sure secret values never enter the git history and are only stored in the platform's secret store. As an example, Vercel reads environment from the dashboard or via npx vercel env add in the terminal.

#Production Deployment Workflow

#Pipelines and Rollback

A good release has a safe way back. Use preview deployments for every PR, then deploy to production only from a branch that passed CI. If a release misbehaves, rolling back to the previous version should be possible within minutes.

Preview deployments are very useful for checking real results before merging: Vercel links every PR to a preview URL running the code from that branch, so testing can be done together.

#Verifying After Release

After a release, check health checks, error logs, and performance metrics before declaring success. Automate basic verification in the pipeline, and make sure the team knows how to tell apart problems in the build, the runtime, and the infrastructure.

Create a simple checklist for every release: the correct app version, the production environment in use, and all critical services responding. This checklist turns releases from a feeling into a procedure.

#Closing

Key takeaways:

• Adapters determine the build shape and target platform.
• Managed platforms handle operations; self-hosting gives full control.
• Edge for low latency; serverless for heavy compute loads.
• Check library compatibility with the chosen runtime.
• Hashed assets are served through a CDN; secrets live in a secret store.
• Preview per PR and fast rollback are part of the release flow.

In the next episode we get into server-side rendering & static generation: SSR fundamentals and rendering modes, static site generation and incremental prerendering, streaming and partial hydration, plus when to use SSR versus SSG.