Déploiement edge

Déployez des applications EmberKit sur des runtimes edge ou des serveurs Node classiques. La sortie statique pré-rendue fonctionne sur tout CDN ; les routes dynamiques utilisent le bundle SSR depuis dist/server/entry-server.js.

Plateformes prises en charge

Plateforme	Runtime	Configuration type
CDN statique	—	`mode: 'static'` ou pré-rendu hybride → envoyer `dist/`
Node.js 18+	Node	`emberkit serve` après `emberkit build`
Cloudflare Workers	Isolats V8	Adaptateur `@emberkit/edge` + Wrangler
Deno Deploy	Deno	Adaptateur Deno `@emberkit/edge`
Bun	Bun	Exécuter l’entrée SSR ou `dist/` statique

Serveur de production Node

Après un build en mode ssr ou hybrid :

pnpm build
pnpm exec emberkit serve

serve lit dist/ssr-manifest.json, sert le HTML pré-rendu et bascule sur dist/server/entry-server.js pour les routes dynamiques.

Pour une vérification locale plus légère :

pnpm preview   # emberkit preview

Cloudflare Workers

pnpm add -D wrangler @cloudflare/workers-types @emberkit/edge

// wrangler.jsonc — modèle de production (site Orange Ember)
{
  "name": "my-app",
  "main": "worker.ts",
  "compatibility_date": "2026-04-03",
  "compatibility_flags": ["global_fetch_strictly_public", "nodejs_compat"],
  "assets": {
    "directory": "./dist",
    "binding": "ASSETS",
    "not_found_handling": "single-page-application"
  },
  "observability": { "enabled": true }
}

Ou définissez les mêmes valeurs par défaut en TypeScript :

import { defineWranglerConfig } from '@emberkit/edge';

export default defineWranglerConfig({
  name: 'my-app',
  main: 'worker.ts',
});

Point d’entrée worker (API partagée + dist/ statique) :

import { createCloudflareWorker } from '@emberkit/edge';
import { handleApiRequest } from './src/server/api-router';

export default createCloudflareWorker({
  handleApi: handleApiRequest,
  injectPublicEnv: true, // expose PUBLIC_* sur window.__CF_ENV__
});

Scripts : pnpm build && wrangler deploy, pnpm build && wrangler dev pour l’aperçu, wrangler types pour les bindings Env.

Utilisez sqlRawPlugin / import sql from './schema.sql' seul (via emberkitVitePlugin) pour empaqueter les migrations SQL sans système de fichiers au runtime.

Deno Deploy

Utilisez l’adaptateur Deno de @emberkit/edge avec une sortie dist/ buildée, ou servez uniquement des fichiers statiques pré-rendus :

deployctl deploy --project=my-app ./dist

Utilitaires de taille de bundle

@emberkit/edge inclut des utilitaires pour contrôler les bundles edge :

import { analyzeBundle, minifyHTML, StaticPage } from '@emberkit/edge';

const stats = analyzeBundle(workerCode);
// stats.size, stats.warnings, stats.errors (limite stricte 8 Ko)

const html = minifyHTML('<div>  <p>  Hello  </p>  </div>');

const page = new StaticPage('<html>...</html>');
page.addStyle('/styles/main.css');
page.addScript('/app.js');
const output = page.toHTML();

Constantes : EDGE_BUNDLE_SIZE_WARNING (1 Ko), MAX_BUNDLE_SIZE (8 Ko).

Modèles de déploiement

Type d’app	Config	Hébergeur
Marketing / docs	`static` ou `hybrid`	Netlify, Cloudflare Pages, S3
Statique + dynamique	`hybrid`	CDN pour le statique + Node/Worker pour le SSR
App authentifiée	`spa` ou `ssr`	Tout hébergeur statique + API

Objectifs de performance

La vitesse est le premier principe d’EmberKit. Les déploiements edge-friendly combinent :

HTML pré-rendu pour les routes statiques — TTFB faible et First Contentful Paint rapide au CDN
SSR à l’edge uniquement là où les routes ont besoin de données par requête
Hydratation sélective — petits bundles client via data-ek-bind et JS minimal sur les pages de contenu

Étapes suivantes

SSR et SSG — Modes de rendu et sortie de build
Hydratation — Liaisons côté client
SEO et meta — Balises meta et JSON-LD