rodolfo.gg
Go back

Comment déployer une application Svelte+SvelteKit sur Cloudflare Workers (free).

CC BY-NC-ND 4.0
Rodolfo González González
de en es fr
Comment déployer une application Svelte+SvelteKit sur Cloudflare Workers (free).

Introduction

Selon Wikipedia :

Cloudflare, Inc. est une entreprise américaine qui fournit un réseau de distribution de contenu, des services de sécurité Internet et des services de serveurs de noms de domaine distribués, placés entre le visiteur et le fournisseur d’hébergement de l’utilisateur de Cloudflare, agissant comme proxy inverse pour les sites web.

Workers est basé sur un moteur d’exécution léger basé sur Node.js (ce n’est pas Node.js directement). C’est beaucoup plus rapide et pratique que d’utiliser un FaaS sur Aliyun FC ou Amazon Lambda pour déployer des applications comme ce blog réalisé avec Astro, bien que chaque technologie ait ses avantages et ses inconvénients. Un avantage de Workers est la rapidité de son exécution. Un autre est son coût.

Ce guide montre comment déployer une application Svelte+SvelteKit sur Cloudflare Workers (free).

1) Quoi faire dans Cloudflare (dashboard)

  1. Créer/utiliser un compte Cloudflare (plan Free).
  2. Aller dans Développement -> Workers et Pages et activer Workers sur le compte.
  3. (Recommandé) Créer un API Token pour le déploiement depuis la CLI :
  4. Aller dans Gérer le compte -> Tokens API de compte.
  5. Sous Account Resources : sélectionner votre compte.
  6. Créer un token
  7. Utiliser le modèle Edit Cloudflare Workers (il possède les permissions minimales requises)
  8. Si vous utilisez un domaine personnalisé :
  1. Sélectionner les Ressources de zone selon les zones que le token couvrira.
  2. Cliquer sur Continue to summary → Create Token.

  1. Si vous utilisez un domaine personnalisé :

    • Avoir la zone (votredomaine.com) dans Cloudflare.
    • Sur le Worker déployé : Settings -> Domains & Routes -> Add Custom Domain

  2. Le nouveau token peut être testé :

Terminal window
curl "https://api.cloudflare.com/client/v4/accounts/xxx123/tokens/verify" \
-H "Authorization: Bearer cfat_ABCD_my_token"

2) Quoi configurer dans le projet

Le projet doit être aligné sur un Worker pur :

wrangler.toml
  - `main = "build/_worker.js"`
  - `[assets] directory = "build", binding = "ASSETS"`

Si vous n’avez pas l’account_id, ajoutez-le :

wrangler.toml
account_id = "votre_account_id"

L’account_id se trouve dans le tableau de bord Cloudflare, dans la barre latérale droite de votre domaine, ou avec :

bunx wrangler whoami

Il est, bien sûr, très important d’utiliser l’adapter-cloudflare :

svelte.config.js
import adapter from '@sveltejs/adapter-cloudflare';

Prérequis locaux

  1. Dépendances :
  1. Configurer le token dans votre environnement local
Terminal window
export CLOUDFLARE_API_TOKEN=cfat_ABCD_my_token

Ou de façon permanente dans ~/.bashrc, ~/.zshrc ou le fichier approprié pour votre shell :

Terminal window
echo 'export CLOUDFLARE_API_TOKEN=votre_token_ici' >> ~/.bashrc

Alternativement avec wrangler :

Terminal window
bunx wrangler login

Ceci ouvre un navigateur pour OAuth. Personnellement, je n’aime pas ça.

Si vous préférez un token direct :

Terminal window
bunx wrangler config

3) Variables et secrets (important)

Dans votre application actuelle

Si import.meta.env.VITE_* (build-time) est utilisé, cela signifie que :

Des exemples critiques pourraient être :

Secrets runtime (optionnel)

Si vous souhaitez ensuite ajouter des secrets à l’exécution :

Terminal window
bunx wrangler secret put NOM_VARIABLE

et les lire depuis env.NOM_VARIABLE.

4) Build + deploy (étape par étape)

Dans les étapes suivantes, vous pouvez remplacer npm par bun dans les commandes :

  1. Installer les dépendances :
Terminal window
npm ci
  1. Configurer le token :
Terminal window
export CLOUDFLARE_API_TOKEN=votre_token

  1. Préparer le .env de build (avec vos VITE_* correctes).

  2. Build :

Terminal window
make build
# npm run build
# bun run build
  1. Vérifier la sortie :
  1. Tester le Worker localement :
Terminal window
make preview
# bunx wrangler dev
  1. Déployer :
Terminal window
make deploy
# bunx wrangler deploy
  1. Tester le Worker, qui sera disponible à :

https://example-frontend.votre-sous-domaine.workers.dev

ou sur votre domaine personnalisé si vous le configurez dans le tableau de bord.

5) Configuration OIDC (Zitadel ou un autre fournisseur) pour la production

Si vous utilisez un fournisseur OIDC comme Zitadel, vous devez enregistrer les endpoints requis auprès du fournisseur :

  1. Redirect URI(s) (callback de connexion).
  2. Post-logout redirect URI(s).
  3. Web origins du frontend.

6) Vérifications post-déploiement

Pour voir les logs :

Terminal window
npx wrangler tail

7) Limites de Workers Free à considérer (vérifiées le 7 avril 2026)

Si vous dépassez ces limites, vous obtiendrez des erreurs de type 1027/quota.

8) Erreurs typiques

  1. Cannot read properties of undefined (reading 'fetch')
  1. Variables VITE_* vides en production
  1. Connexion Zitadel échoue en prod

9) Déploiement sur domaine personnalisé

Il y a 2 façons de le faire, en supposant que le domaine se trouve dans Cloudflare :

A. En utilisant wrangler.toml

Configurer les routes :

routes = [
  { pattern = "www.example.com/*", zone_name = "example.com" }
]

Puis effectuer le déploiement normal :

Terminal window
bunx wrangler deploy

B. Dans le tableau de bord Cloudflare

  1. Aller dans Workers & Pages → votre worker → Settings → Triggers
  2. Cliquer sur Add Custom Domain
  3. Saisir www.example.com
  4. Cloudflare crée automatiquement l’enregistrement DNS et le certificat TLS

Domaine hors de Cloudflare

Si le domaine n’est pas dans Cloudflare :

Vous devez d’abord ajouter le domaine à Cloudflare (ou au moins utiliser un enregistrement DNS externe) :

Dans le DNS de votre registrar, créez un enregistrement CNAME :

Dans tinydns, par exemple :

Terminal window
Cwww:votre-projet.votre-sous-domaine.workers.dev:86400

Ensuite dans Cloudflare, allez dans le worker et dans Triggers cliquez sur Add Custom Domain et ajoutez www.example.com.

Différence entre routes et custom_domain

Caractéristiqueroutescustom_domain
Nécessite zone dans CFOuiOui
Configurable dans tomlOuiOui
TLS automatiqueManuel (déjà existant)Automatique
Partagé avec d’autres workersOui (par motif)Non

Pour un sous-domaine dédié au worker, custom_domain est l’option la plus propre :

wrangler.toml
routes = [
  { pattern = "ssr.example.com/*", custom_domain = true, zone_name = "example.com" }
]

Ou la syntaxe alternative :

[[env.production.routes]]
pattern = "ssr.example.com/*"
zone_name = "example.com"

Bonus : Règles Makefile utiles

deploy:
  bunx wrangler deploy


preview:
  bunx wrangler dev


build:
  @echo "Building with $(DOTENV_FILE)"
  DOTENV_FILE=$(DOTENV_FILE) bun run build

Sources officielles utilisées

Share this post on:
Share this post via WhatsApp Share this post on Facebook Share this post on X Share this post via Telegram Share this post on Pinterest Share this post via email
Previous Post
Comment installer caveman dans Visual Studio Code pour Claude Code.
Next Post
Comment obtenir des tokens d'autorisation sur HuggingFace.