Cloudflare Worker Previews : ce qui est gratuit, ce qui ne l’est pas

Cloudflare Worker Previews est-il gratuit ? Oui : Workers Free comprend 100 Previews par Worker et 100 déploiements par Preview. Ce quota ne rend toutefois pas les tests de branche illimités : l’exécution dynamique, les minutes de build, le stockage, l’inférence IA et Containers conservent leurs propres limites ou tarifs.

Cloudflare Worker Previews fournit à chaque branche Git un environnement proche de la production, rattaché au même Worker. La bonne réponse ne se résume donc pas à « $0 ». L’objet Preview est disponible avec l’offre Free, puis la branche utilise les mêmes produits de la plateforme que ceux qu’il faut déjà intégrer au budget.

Cloudflare Worker Previews : est-ce gratuit ?

Oui, ce droit est gratuit. La page actuelle de Cloudflare consacrée aux limites des Previews indique 100 Previews par Worker avec l’offre Free, 500 avec les offres payantes et 100 déploiements dans chaque Preview, quelle que soit l’offre.

Cette réponse a une limite précise. Une Preview est un objet d’environnement, pas un forfait incluant gratuitement l’exécution, le stockage, les builds ou les appels de modèles. La page en ligne sur la tarification de Workers accorde toujours aux comptes Free 100,000 requêtes Worker dynamiques par jour, avec une limite de 10 millisecondes de CPU par invocation. Workers Paid démarre toujours à $5 par compte et par mois, inclut 10 millions de requêtes et 30 millions de millisecondes CPU par mois, puis applique les tarifs de dépassement publiés.

Les pages en ligne sur les Previews et la tarification ont été vérifiées le 28 septembre 2026. Aucune ne publie de frais propres aux Previews, mais aucune n’affirme non plus que leur exécution est illimitée ou bénéficie d’un quota d’usage distinct. Le budget prudent est donc le suivant : droit aux Previews gratuit, compteurs habituels des produits.

Ce qui a réellement changé le 22 septembre 2026

Cloudflare a lancé Worker Previews le 22 septembre 2026 afin d’attribuer à chaque branche son propre environnement actif, avec une URL de Preview stable, sa configuration, son observabilité et son état. La commande npx wrangler preview crée ou met à jour la Preview associée à la branche courante.

Pour l’entreprise, le cycle de validation se raccourcit. Un agent de code peut déployer une branche, lui envoyer des requêtes, examiner les logs et les traces, corriger le code, puis mettre à jour la même URL de Preview partageable avant toute fusion en production. Plusieurs agents ou ingénieurs peuvent ainsi avancer en parallèle sans se relayer sur un unique Worker de staging.

Chaque branche reçoit deux types d’URL utiles. L’URL de Preview suit toujours le dernier déploiement de la branche. Une URL de Deployment reste attachée à un déploiement précis, ce qui permet de reproduire un commentaire de revue ou une comparaison de régression.

L’isolation est réelle. Cloudflare attribue automatiquement à chaque Preview son propre namespace et son propre stockage Durable Objects. La plateforme peut également provisionner une application de conteneur et des instances séparées. Les variables, les secrets et les bindings peuvent différer de la production, tandis que les logs et les traces restent limités à la branche.

Le workflow est plus solide que l’ancien modèle des Version URLs, sans pour autant constituer une copie complète de la production. Plusieurs bindings et triggers continuent d’accéder à des systèmes partagés ou de production. Cette limite, plus que la commodité de l’URL de Preview, doit déterminer le niveau d’autonomie accordé à un agent.

Cloudflare Workers gratuit : ce que comprend l’offre Free

L’offre Free suffit largement à un workflow de branche classique. Un Worker peut contenir 100 environnements Preview, et chaque Preview peut conserver 100 déploiements. L’offre Paid porte le nombre d’environnements à 500, mais n’augmente pas l’historique de déploiement par Preview.

Ces dimensions sont indépendantes. Déployer plusieurs fois une même branche n’occupe toujours qu’un emplacement Preview, même si son historique de déploiement s’allonge. Plusieurs branches ayant chacune une Preview active utilisent plusieurs emplacements Preview, même sans recevoir de trafic.

Comparer l’ancien et le nouveau calcul d’objets est instructif. Pour faire correspondre cinq branches avec les environnements Wrangler, il fallait gérer cinq Workers distincts. Worker Previews regroupe ces mêmes branches sous un Worker, sous la forme de cinq objets Preview. Avec Free, l’occupation du compte passe de 5% de la limite de 100 Workers à 1% de cette limite, auquel s’ajoutent 5% du quota de Previews de ce Worker. Dans les deux configurations, le prix de base documenté peut rester à $0 tant que l’usage tient dans les limites. Le bénéfice vient d’une isolation plus simple et d’une moindre prolifération des environnements, pas d’une exécution moins chère.

Worker Previews exige Wrangler 4.135.0 ou une version ultérieure. C’est la version locale au projet qui compte, car les commandes du projet ne remplacent pas discrètement une installation globale plus récente. Dans un dépôt ancien, ce détail peut faire croire à tort que la fonctionnalité n’est pas disponible.

La frontière de configuration est tout aussi importante. Les Previews n’héritent pas des réglages de production. La branche reçoit ce qui est déclaré dans le bloc previews, ainsi que les ressources que Cloudflare isole automatiquement. Un bloc vide ou incomplet peut produire une Preview correctement déployée, mais incapable d’accéder à la ressource attendue par le code.

Limites de Cloudflare Worker Previews : quel élément disparaît en premier ?

Cloudflare effectue un nettoyage automatique dès que l’une des limites d’objets est atteinte. Au niveau du Worker, la Preview dont le dernier déploiement est le plus ancien est supprimée. Dans une Preview, c’est le déploiement le plus ancien qui disparaît.

Le 101e déploiement dans une même Preview déclenche donc la rétention : le plus ancien est retiré pour laisser la place au nouveau. Cela ne signifie pas que les 100 premiers builds étaient gratuits. Workers Builds comptabilise séparément les minutes de build, que ces builds aient produit des déploiements de production ou de Preview.

Pour un agent qui révise souvent une branche, l’URL de Preview stable reste précieuse puisqu’elle pointe toujours vers le dernier déploiement. Le risque concerne l’historique d’investigation. Si une équipe doit reproduire un incident ancien, elle doit conserver l’URL de déploiement et les logs utiles avant que ce déploiement ne devienne l’élément le plus ancien.

La suppression automatique des objets ne remplace pas non plus une politique complète de nettoyage des ressources. Supprimer une Preview retire son enregistrement Preview et son namespace Durable Objects, mais Cloudflare avertit qu’une application de conteneur générée peut rester visible. À la fermeture d’une branche, l’automatisation doit supprimer la Preview, puis vérifier les applications Container si des conteneurs ont été utilisés.

Prix Cloudflare Workers : les quatre couches des Previews

La tarification de Cloudflare Worker Previews ne comporte aucun poste publié par Preview. En pratique, la facture reste composée de quatre couches : l’exécution du Worker, les builds, les ressources liées et les produits optionnels de calcul ou de modèles.

1. Exécution du Worker

Workers Free autorise 100,000 requêtes par compte et par jour, avec un plafond de 10 millisecondes de CPU par invocation. Les requêtes de ressources statiques sont gratuites et illimitées ; le quota de requêtes s’applique à celles qui exécutent du code Worker. Un test de branche qui ne charge que des fichiers statiques peut donc sembler peu coûteux, alors qu’un test riche en appels API entame le quota dynamique.

Workers Paid démarre à $5 par compte et par mois. L’offre inclut chaque mois 10 millions de requêtes et 30 millions de millisecondes CPU, puis facture $0.30 par million de requêtes supplémentaire et $0.02 par million de millisecondes CPU supplémentaire. Paid applique par défaut une limite CPU de 30 secondes à une invocation HTTP, configurable jusqu’à 5 minutes.

La limite de 10 millisecondes de Free est souvent le premier obstacle. Le volume de requêtes ne peut pas la compenser. Une suite de tests qui n’envoie que quelques requêtes échoue tout de même si une seule invocation dynamique demande régulièrement plus de 10 millisecondes de CPU.

Pour replacer ce choix dans l’ensemble de la plateforme, l’analyse de Cloudflare distingue l’offre de compte Workers à $5 des offres applicatives par domaine de Cloudflare et des autres compteurs de produits.

2. Workers Builds

La page des limites et tarifs de Workers Builds accorde aux comptes Free 3,000 minutes de build par mois, un build simultané et un délai maximal de 20 minutes. Paid inclut 6,000 minutes, puis facture $0.005 par minute supplémentaire, avec six builds simultanés et le même délai maximal. Les branches créées par des agents peuvent buter sur la concurrence ou les minutes disponibles alors même que leur nombre d’objets Preview reste faible.

Voilà pourquoi « 100 déploiements par Preview » ne signifie pas « 100 builds inclus ». Le premier nombre désigne l’historique de déploiement conservé ; le second relèverait du calcul CI.

3. Stockage et ressources liées

KV, D1, R2, Queues, Vectorize, Hyperdrive et les autres bindings utilisent leurs propres identifiants de ressources et leurs propres compteurs. Deux Previews reliées à la même base D1 ou au même bucket R2 partagent ces données. L’isolation exige une ressource distincte, qui reste soumise à la tarification de son produit.

À titre d’échelle, R2 inclut 10 GB-month, 1 million d’opérations de classe A et 10 millions d’opérations de classe B par mois. Au-delà, le stockage Standard coûte $0.015 par GB-month, la classe A $4.50 par million et la classe B $0.36 par million. D1 Free inclut 5 millions de lignes lues et 100,000 lignes écrites par jour, ainsi que 5 GB de stockage total. L’analyse des limites gratuites de D1 explique pourquoi une base de staging partagée peut devenir une limite de disponibilité alors même que des objets Preview restent disponibles.

KV dispose encore d’une enveloppe quotidienne distincte : 100,000 lectures, 1,000 écritures, 1,000 suppressions et 1,000 requêtes de liste avec Free, ainsi que 1 GB stocké. Un test qui alimente ou vide un namespace peut épuiser cette enveloppe beaucoup plus vite qu’un simple test de bon fonctionnement en lecture seule.

4. Inférence IA et Containers

La tarification de Workers AI accorde aux comptes Free comme Paid 10,000 Neurons par jour sans frais. Avec Paid, l’usage au-delà de cette allocation coûte $0.011 par tranche de 1,000 Neurons. Un test de branche qui appelle un modèle doit donc budgéter deux activités : la requête Worker et l’inférence qu’elle déclenche. L’abonnement à un agent de code externe ou l’API d’un modèle relève de la facture d’un autre fournisseur et n’est pas inclus dans le droit aux Previews.

La tarification des Containers ne prévoit aucune allocation Container avec Free. Workers Paid inclut 25 GiB-hours de mémoire, 375 vCPU-minutes et 200 GB-hours de disque par mois, avec des tarifs de dépassement séparés. Le trafic des conteneurs utilise aussi Workers et Durable Objects : un conteneur Preview isolé automatiquement ne se résume donc pas à un seul compteur.

Coût de Worker Previews pour cinq branches actives

La bonne feuille de calcul commence par la charge, pas par le nom de l’offre. Prenons cinq branches actives, recevant chacune 200 requêtes de test dynamiques par jour. Cela représente 1,000 requêtes quotidiennes réparties entre cinq objets Preview.

Avec Free, le nombre de Previews reste confortable et le trafic modélisé est faible. Il reste 99,000 requêtes dynamiques par jour au compte uniquement si rien d’autre ne consomme ce quota. Le trafic de production, les autres Workers et les cinq environnements de branche doivent tous figurer dans la feuille de calcul opérationnelle.

Une nuance de preuve est essentielle. Cloudflare qualifie les 100,000 requêtes quotidiennes de limite liée à l’offre du compte, et une Preview exécute une véritable version du Worker. La documentation des Previews ne dit toutefois pas explicitement que leur trafic est débité du même compteur. Appliquer le compteur du compte aux requêtes Preview reste donc une hypothèse budgétaire prudente, tant qu’une observation de l’usage du compte ou une déclaration explicite de Cloudflare ne l’a pas confirmée.

Cette vérification ne disposait d’aucun identifiant de compte Cloudflare, d’aucun projet Worker ni d’aucune installation locale de Wrangler au projet. Aucune Preview jetable n’a été déployée et aucune variation d’usage n’a été mesurée. La réponse sur le droit d’usage est vérifiée par les sources ; cette feuille de calcul est un modèle.

Avec Paid, cette charge de branches ne génère à elle seule aucun dépassement de requêtes, mais le compte paie tout de même le minimum mensuel de $5. Le CPU et les produits associés peuvent changer ce constat. À la même densité de test, les 100 emplacements Preview de Free produiraient 20,000 requêtes par jour, soit 20% du quota quotidien modélisé. Les 500 emplacements de Paid produiraient 3 millions de requêtes sur un mois de 30 jours, soit 30% des requêtes mensuelles incluses. Dans ces deux exemples en environnement vierge, la limite d’objets Preview est atteinte avant le quota de requêtes. Le trafic de production peut inverser cet ordre.

Ce que cela change pour les développeurs, les opérateurs et les acheteurs

Les développeurs obtiennent une preuve d’exécution parallèle, pas la sécurité automatique des ressources

Un développeur peut attribuer à chaque branche active une URL stable et un état Durable Objects isolé. Cela supprime les collisions du staging partagé, où le déploiement d’un ingénieur invalide la revue d’un autre. Un agent de code dispose aussi d’une cible concrète pour curl, les vérifications dans le navigateur, les logs et les traces.

La limite vient de la configuration. D1, KV et R2 ne s’isolent pas simplement parce que le code l’est. Si deux Previews utilisent le même identifiant, elles partagent la ressource. Le choix prudent par défaut est une ressource hors production dédiée, ou une ressource de staging volontairement partagée avec des données jetables.

Les opérateurs gèrent le budget partagé et le nettoyage

Un opérateur doit suivre séparément quatre nombres : les objets Preview actifs, les déploiements conservés par Preview, l’usage dynamique de Workers et l’usage des produits associés. Un total unique dans un dashboard ne peut pas expliquer ces quatre dimensions.

Le nettoyage doit faire partie de l’automatisation des pull requests. Supprimez une Preview à la fermeture de sa branche. Si des Containers ont été utilisés, recherchez l’application de conteneur générée. Conservez toute URL de déploiement ou trace nécessaire à un incident avant sa disparition de l’historique.

Les acheteurs doivent passer à l’offre supérieure pour une limite précise

N’achetez pas Paid simplement parce que le mot « Preview » semble désigner une fonction premium. Choisissez cette offre lorsqu’une exigence identifiée dépasse Free : plus de 100 Previews simultanées sur un Worker, un trafic dynamique cumulé à la production qui approche 100,000 requêtes par jour, une invocation nécessitant plus de 10 millisecondes de CPU ou n’importe quel besoin en Containers.

Paid peut aussi représenter un choix rationnel de maîtrise du risque avant que le volume ne l’impose. Une équipe dont le service est exposé aux clients peut préférer une allocation mensuelle et une facture de dépassement à la limite quotidienne de Free, même si les tests de cinq branches ne consomment que 1% de cette enveloppe quotidienne modélisée.

Ce qu’il faut faire autrement

Agissez maintenant si plusieurs ingénieurs ou agents se relaient sur un unique Worker de staging modifiable. Déplacez la validation des branches vers les Previews, définissez une politique de ressources hors production et intégrez le nettoyage à la fermeture des branches dans la CI. Cette évolution supprime directement un frein à la coordination.

Attendez si l’application dépend de bindings de service entre plusieurs Workers, de consommateurs Queue, de Cron Triggers, de routes de production ou de Workflows isolés automatiquement. Aujourd’hui, ces parcours ne restent pas entièrement dans une Preview. Celle-ci peut toujours tester la partie exposée en HTTP, mais elle ne prouve pas que l’ensemble du système est isolé.

Vous êtes peu concerné si le projet dispose déjà ailleurs d’un environnement stable par branche, ou si le Worker est statique et que les modifications sont entièrement couvertes par des contrôles locaux et des vérifications de versions déployées. Le nouvel objet ne crée pas de valeur par sa seule existence.

La règle de décision est simple : restez sur Free tant que le nombre d’objets, le CPU par invocation, le trafic modélisé du compte et les besoins liés aux produits restent tous dans les limites. Passez à Paid dès que l’une de ces frontières devient importante pour l’exploitation. Le nombre de requêtes n’est pas le seul seuil de bascule.

Ce qui est survendu

L’annonce est la plus juste lorsqu’elle décrit un Worker de branche isolé. Elle devient excessive si on l’interprète comme la copie isolée d’une application Cloudflare complète.

• Depuis une Preview, un service binding appelle le déploiement de production de l’autre Worker. Les parcours de requêtes impliquant plusieurs Workers ne sont pas automatiquement appariés branche par branche.
• Un binding Workflow utilise un Workflow déjà déployé. Cloudflare ne crée pas de Workflow propre à la Preview pour la branche.
• Une Preview peut envoyer des messages dans une Queue, mais ne peut pas en être le consommateur. Si elle pointe vers une Queue de production, celle-ci peut consommer ses messages de test.
• Les Cron Triggers et les routes de production ciblent toujours la production.
• KV, D1, R2 et plusieurs autres ressources ne sont isolés que si un identifiant de ressource différent leur est associé.
• Les URL de Preview sont publiques par défaut. La forme workers.dev comporte X-Robots-Tag: noindex, mais une Preview sur un domaine personnalisé doit être protégée avec Cloudflare Access si le travail non publié doit rester privé.
• La prise en charge de Container est partielle, et une suppression peut laisser l’application générée visible jusqu’à son nettoyage séparé.

Pour un agent, il ne s’agit pas de cas marginaux. Ils séparent « l’agent peut tester sa branche » de « l’agent ne peut pas toucher à la production ». La matrice actuelle d’isolation des ressources doit être considérée comme un document d’autorisation, pas comme une lecture de configuration facultative.

L’autre exagération est financière : 100 Previews avec Free ne représentent pas 100 stacks de staging entièrement gratuites. Cela signifie que Cloudflare autorise un Worker à contenir autant d’objets Preview. Le budget dépend des ressources placées derrière eux.

Vérifiez le droit d’usage, puis suivez le guide de configuration

Quatre questions suffisent pour vérifier le droit d’usage :

1. Le compte utilise-t-il Workers Free ou Paid ?
2. Combien de Previews actives ce Worker contient-il déjà ?
3. Quelle part du budget de requêtes et de CPU du compte la production et les autres Workers consomment-ils déjà ?
4. Le projet épingle-t-il Wrangler 4.135.0 ou une version ultérieure ?

Si les réponses restent dans les limites, suivez le guide officiel de configuration de Worker Previews pour configurer et déployer. Traitez séparément l’examen des coûts : répertoriez chaque ressource liée, chaque parcours de build, chaque appel de modèle et chaque Container avant qu’un agent ne commence à créer des branches.

FAQ Cloudflare Worker Previews

Peut-on utiliser Cloudflare Workers gratuitement ?

Oui. Workers Free coûte $0, inclut 100,000 requêtes Worker dynamiques par jour et accepte jusqu’à 100 Previews par Worker. Chaque invocation reste limitée à 10 millisecondes de CPU, et les produits associés conservent leurs propres allocations.

Combien coûte un Cloudflare Worker ?

Workers Free coûte $0. Workers Paid démarre à $5 par compte et par mois, inclut 10 millions de requêtes et 30 millions de millisecondes CPU, puis facture les dépassements aux tarifs publiés. Une Preview n’a pas de tarif de base distinct publié.

Combien de Cloudflare Workers peut-on avoir gratuitement ?

Workers Free autorise 100 Workers par compte. Cette limite est distincte de celle de Worker Previews, qui autorise 100 Previews sous chaque Worker avec Free.

Combien coûte Cloudflare Workers AI ?

Workers AI inclut 10,000 Neurons par jour sans frais. Avec Workers Paid, l’usage au-delà de cette allocation quotidienne coûte $0.011 par tranche de 1,000 Neurons.

Cloudflare Workers AI est-il gratuit ?

Workers AI propose une allocation quotidienne gratuite de 10,000 Neurons avec Workers Free comme avec Workers Paid. Les comptes Free s’arrêtent à cette allocation ; les comptes Paid peuvent continuer à $0.011 par tranche de 1,000 Neurons au-delà.

Quel est le principal concurrent de Cloudflare ?

Il n’existe pas de concurrent unique couvrant à la fois les produits réseau, sécurité, calcul, stockage et développement de Cloudflare. Comparez la couche précise que vous souhaitez remplacer au lieu de considérer l’entreprise entière comme un seul produit.

Pourquoi Cloudflare baisse-t-il ?

La question est ambiguë et dépend du moment : elle peut viser le cours de l’action, l’état du service, le trafic ou une autre mesure. Aucune de ces interprétations ne modifie les limites de Worker Previews vérifiées dans la documentation en ligne de Cloudflare le 28 septembre 2026.

Cloudflare est-il une entreprise russe ?

Non. La présentation de l’entreprise Cloudflare situe son siège à San Francisco et indique que Cloudflare, Inc. est cotée à la Bourse de New York sous le symbole NET.

Pourquoi le FBI utilise-t-il Cloudflare ?

Cet article n’établit pas que le FBI utilise Cloudflare et ne formule aucune affirmation sur les fournisseurs d’une agence. La question n’a aucun rapport avec le droit d’usage et les limites documentés de Worker Previews.

L’action du lundi

Commencez avec cinq branches, plafonnez chacune à 200 requêtes de test dynamiques par jour et identifiez les 1,000 requêtes quotidiennes obtenues comme une hypothèse de compteur partagé dans le budget. Lorsque vous aurez accès à la facturation, relevez l’usage des requêtes du compte avant et après le pilote. Si l’écart confirme le modèle, conservez la feuille de calcul ; sinon, remplacez l’hypothèse par l’observation.

En parallèle, inventoriez chaque binding du bloc previews. Classez-le comme isolation automatique, ressource de test dédiée, partage intentionnel ou accès à la production. N’autorisez aucun déploiement d’agent tant que chaque ligne accédant à la production n’a pas de justification explicite.

Vous voulez transformer la prochaine nouveauté d’infrastructure en décision budgétaire et opérationnelle ? Inscrivez-vous à la newsletter.