Learn Svelte - Deployment & Hosting

#Introduction

A perfect build means nothing until it runs in production. Deployment connects code to users: the hosting platform, the right adapter, and caching configuration determine the real experience.

This episode covers deployment options such as Vercel, Netlify, Cloudflare Pages, and static hosting, SvelteKit adapters and serverless deployment, production output optimization, and caching and CDN integration.

When you're done, you can choose the right platform and understand what happens between the build command and the page reaching users.

Throughout this episode, remember that deployment is repeatable configuration, not a secret ritual. Changes should be traceable in history and replayable at any time.

#Deployment Options

#Serverless vs Static Platforms

Platform choice depends on your app's needs. Apps with server-side rendering and form actions need a server runtime; purely static apps can be hosted on a cheap, fast CDN. Vercel, Netlify, and Cloudflare Pages offer both with different experiences.

Serverless platforms handle scaling automatically — no servers to manage. But watch out for cold starts: rarely invoked functions can delay the first response.

#Choosing Considerations

Pay attention to a few things: server function needs, user region location, free tier limits, and integration with the tooling you already use. There's no universal answer — measure according to your workload.

Cost also matters: serverless platforms charge by usage, while VPS charges by capacity. Small apps with low traffic are often cheaper on static platforms.

#SvelteKit Adapters and Serverless Deployment

#The Adapter Determines the Target

An adapter is the bridge between a SvelteKit app and a hosting platform. adapter-vercel produces serverless functions for Vercel:

npm install -D @sveltejs/adapter-vercel

After installing, change svelte.config.js to use that adapter.

For hosting without a dedicated adapter, adapter-node provides a Node server that can run on a VPS or in Docker. It's the most flexible option for your own infrastructure.

#Example: Cloudflare Pages

Cloudflare Pages uses a dedicated adapter because it runs code on the Cloudflare Workers runtime:

svelte.config.js for Cloudflare Pages

import adapter from "@sveltejs/adapter-cloudflare"
import { vitePreprocess } from "@sveltejs/vite-plugin-svelte"
 
const config = {
  preprocess: vitePreprocess(),
  kit: {
    adapter: adapter(),
  },
}
 
export default config

adapter-cloudflare produces static assets plus worker functions for server logic. Other platforms follow the same pattern: swap the adapter, adjust the config, and rebuild.

#Build Output and Production Optimization

#Standard Output Structure

SvelteKit writes build results to the build folder. Its contents depend on the adapter: static files for static hosting, or a combination of server functions and assets for serverless platforms. Always inspect the build output before changing settings.

The static folder is copied as-is to the output, while assets imported through Vite get a hash. Know the difference when setting up asset delivery.

#Optimization at the Configuration Level

Enable the relevant options: prerender static pages so they don't consume server runtime, and compress assets at the platform level. Vite settings like browser target and source maps also affect output size and speed.

Run builds regularly in CI so output size stays monitored. A single big regression is easier to catch than one spread across many releases.

#Caching and CDN Integration

#CDN Benefits

A CDN brings assets closer to users and absorbs excess load. Assets hashed by Vite — filenames containing a content hash — can be cached forever because their contents never change. HTML pages keep a short cache so changes ship quickly.

Platforms like Vercel and Cloudflare already use a global CDN by default. For your own infrastructure, consider a separate CDN in front of the origin server.

#Deliberate Cache Headers

Set headers on the hosting platform:

Cache-Control: public, max-age=31536000, immutable

This value applies to hashed files. HTML pages and APIs should use a short cache with revalidation. Caching strategy is a balance between data freshness and speed.

Test cache configuration in production by inspecting response headers in DevTools. Headers that don't appear mean the rules haven't reached the server handling the request.

#Conclusion

Key takeaways:

• Choose a platform based on server-side or static needs.
• The adapter determines the output shape and target runtime.
• Swap the adapter in svelte.config.js and rebuild when moving platforms.
• Use prerender for pages that don't need a server.
• Cache hashed assets long-term, HTML with a short cache.
• Use a CDN to bring assets closer to users.

Next, in episode 21 you'll learn server-side rendering & SvelteKit — the differences between SSG, SSR, and hybrid rendering, load functions and server data, islands architecture and partial hydration, and when to use SSR versus SSG. Your deployment decisions in this episode will influence your rendering strategy choices.