Деплой и адаптеры

Адаптеры превращают собранное приложение в готовый артефакт под конкретную платформу — Vercel, Node, статический хостинг.

«Один код — много платформ.» Адаптеры отделяют ваше приложение от деталей хостинга, так что деплой меняется сменой одной зависимости.

Вы написали приложение — пора его выкатить. Здесь вступают адаптеры: маленькие плагины, которые берут собранное SvelteKit-приложение и превращают его в формат, понятный конкретной платформе. adapter-vercel готовит serverless-функции для Vercel, adapter-node создаёт самостоятельный Node-сервер, adapter-static выдаёт чистые HTML/CSS/JS для статического хостинга, есть адаптеры для Netlify, Cloudflare и других.

По умолчанию новый проект использует adapter-auto — он сам определяет платформу при деплое на поддерживаемых хостингах и подтягивает нужный адаптер. Это удобно для старта, но для продакшена обычно ставят конкретный адаптер явно: так сборка предсказуема и можно настроить специфичные опции.

// svelte.config.js — выбор адаптера
import adapter from '@sveltejs/adapter-node';

export default {
  kit: {
    adapter: adapter() // соберёт самостоятельный Node-сервер
  }
};

Установка адаптера — это пара шагов: добавить пакет и указать его в конфиге.

# поставить адаптер под нужную платформу
npm install -D @sveltejs/adapter-node

# собрать приложение (адаптер подготовит артефакт деплоя)
npm run build

Связанный выбор — режим рендеринга. Для динамичных страниц с серверной логикой нужен серверный адаптер (Vercel, Node). Для целиком статичного сайта подойдёт adapter-static с пререндерингом — он выдаёт набор файлов, который можно положить на любой CDN. Можно даже комбинировать: пометить отдельные страницы как пререндеримые (export const prerender = true), а остальные оставить серверными. На Vercel доступна и инкрементальная статическая регенерация (ISR) для периодического обновления статики.

Как это работает под капотом

Адаптер — это функция, принимающая результат сборки и возвращающая артефакт под платформу. Логика приложения едина; меняется лишь «упаковка». Смоделируем выбор адаптера по платформе.

// Адаптер: одно приложение -> разная 'упаковка' под платформу
const builtApp = { html: '<h1>Привет</h1>', routes: ['/', '/blog'] };

const adapters = {
  static: (app) => ({ type: 'статические файлы', files: app.routes.map(r => r + '/index.html') }),
  node:   (app) => ({ type: 'Node-сервер', entry: 'server.js' }),
  vercel: (app) => ({ type: 'serverless-функции', fns: app.routes.length })
};

console.log(adapters.static(builtApp));
console.log(adapters.node(builtApp));
console.log(adapters.vercel(builtApp));

Попробуй сам ▶ — вставь код в консоль браузера (F12 → Console) и нажми Enter, чтобы увидеть вывод.

           npm run build
                |
                v
          собранное приложение
                |
        +-------+--------+----------+
        v       v        v          v
   adapter-   adapter-  adapter-  adapter-
   static     node      vercel    netlify
        |       |        |          |
      CDN    свой VPS   Vercel    Netlify

Частые ошибки

Оставлять adapter-auto на проде. Для контроля лучше явный адаптер под вашу платформу.
Брать adapter-static для динамичного приложения. Статика не выполнит серверную логику.
Забыть, что пререндеру нужен ssr = true. Пререндеринг строит HTML на сервере.

Best practices

Выбирайте адаптер под реальный хостинг и фиксируйте его явно в конфиге.
Пререндерите статичные страницы для скорости и дешевизны раздачи.
Комбинируйте режимы: статика для контента, SSR для динамики — на уровне маршрутов.

Выбор стратегии рендеринга

Выбор адаптера тесно связан с тем, как именно ваше приложение должно рендериться, и здесь стоит думать постранично, а не приложением целиком. Контентные страницы, которые меняются редко — статьи блога, документация, лендинги, — выгодно пререндерить в статические файлы: они отдаются мгновенно с любого CDN, дёшевы в раздаче и не нагружают сервер. Динамические страницы, зависящие от пользователя или свежих данных — личный кабинет, лента, корзина, — требуют серверного рендеринга, а значит, серверного адаптера. Прелесть SvelteKit в том, что эти режимы можно смешивать в одном приложении, помечая отдельные маршруты как пререндеримые, а остальные оставляя серверными. На платформах вроде Vercel доступна и инкрементальная статическая регенерация, которая обновляет статику по расписанию, давая компромисс между скоростью статики и свежестью динамики. Определитесь с хостингом и режимами заранее: это влияет и на выбор адаптера, и на архитектуру загрузки данных, поэтому решать такие вопросы постфактум дороже, чем спроектировать их с самого начала.

Итог: адаптеры готовят собранное приложение под конкретную платформу, не меняя его код. Выбирайте адаптер и режим рендеринга под задачу — от статики на CDN до серверного рендеринга на Node или Vercel.