Déploiement en solo : Cloudflare, Vercel ou Railway ?

Le tableau de déploiement contient quatre services : blog, tool-api, dashboard et worker-daily-report. Les deux premiers tournent chez Cloudflare, le troisième chez Vercel, tandis que le dernier hésite entre Railway et Workers. Chacun bute sur une limite différente : builds, CPU Workers, facture Vercel ou durée d’une tâche en conteneur plutôt qu’en fonction.

Un produit géré en solo combine souvent site de contenu, outil, dashboard SaaS et tâche planifiée. La bonne question n’est donc pas quel fournisseur gagne, mais quel runtime convient à chaque service et où se situent les seuils de coût et de maintenance.

1. Quatre services, quatre contraintes différentes

blog est un site Astro statique sur Cloudflare Pages. Chaque modification de contenu, de style ou de configuration déclenche un build et rapproche le projet des 500 builds mensuels du plan Free. La limite de 20 000 fichiers reste lointaine, mais les commentaires et la recherche via Pages Functions consomment déjà les quotas Workers.

tool-api est une petite API Workers pour la connexion et la persistance. Avec la croissance, 100 000 requêtes par jour peuvent ne plus suffire et les requêtes gourmandes peuvent dépasser 10 ms de CPU. Workers Paid commence à 5 dollars par mois, avec une facturation distincte de l’hébergement statique.

dashboard est une application Next.js full-stack sur Vercel. Les previews sont pratiques, mais la page d’usage sépare Functions, Images, Builds, Analytics et d’autres produits. Chaque siège payant supplémentaire coûte 20 dollars par mois. Hobby inclut 4 heures d’Active CPU, 360 GB-hours de mémoire provisionnée et 1 million d’invocations.

worker-daily-report génère puis envoie un rapport chaque jour. Workers accepte du code planifié, mais une tâche longue ou intensive peut dépasser ses limites CPU et mémoire. Railway exécute un processus Node, au prix d’un suivi de la RAM, du CPU, de l’egress et des volumes. Hobby coûte 5 dollars et inclut 5 dollars d’usage.

La règle commune consiste à séparer les charges par runtime. Contenu statique, fonction légère, application complète et tâche longue n’ont pas à partager une plateforme.

2. Les contraintes principales des quatre plateformes

2.1 Cloudflare Pages : assets statiques gratuits, fonctions dans Workers

Cloudflare Pages sert principalement à héberger et distribuer des assets statiques. Les limites Free actuelles comprennent :

• 500 builds par mois ; les push Git et builds manuels consomment le quota.
• 20 000 fichiers par site ; surveillez les sites riches en images ou pages générées.
• 25 MiB maximum par asset ; placez vidéos et gros fichiers dans un object storage.
• 100 custom domains par projet avec Free.
• Un timeout de build de 20 minutes.

Les requêtes et le CPU de Pages Functions comptent dans Workers, pas dans le quota statique Pages :

• Les assets statiques sont servis dans les limites Pages.
• Les commentaires, la recherche et les proxys API utilisent quotas et tarifs Workers.
• Astro et Hugo conviennent naturellement ; pour Next.js, vérifiez l’adapter et le runtime actuels.

Pages constitue un bon départ pour un site de contenu ou un outil statique. Les requêtes dynamiques nombreuses et calculs complexes doivent être estimés comme une charge Workers distincte.

2.2 Cloudflare Workers : fonctions légères limitées en requêtes et CPU

Workers est le runtime Cloudflare pour API légères, logique edge et backends d’outils. Les limites actuelles incluent :

• 100 000 requêtes par jour avec Free.
• 10 ms de CPU par requête HTTP avec Free ; l’attente réseau ne compte pas comme CPU.
• Un abonnement Workers Paid de 5 dollars par mois.
• 10 millions de requêtes incluses par mois en Standard.
• 30 millions de millisecondes CPU incluses par mois.
• 128 MB de mémoire par isolate en Free et Paid.

Usages adaptés :

Railway - Plateforme de déploiement moderne, sans opérations complexes, en ligne en quelques minutes

Commencer →Pub

• API légères pour authentification, lecture et logique métier simple.
• Pages Functions pour commentaires et recherche.
• Proxys API avec cache, routage et autorisation.

Usages inadaptés :

• Rapports longs et traitements batch.
• Calcul lourd, gros volumes en mémoire ou inférence ML.
• Pools de connexions classiques incompatibles avec un runtime isolate.

Workers convient au backend d’un petit outil. Anticipez cependant la croissance en requêtes et CPU ; les processus persistants et tâches lourdes demandent un autre runtime.

2.3 Vercel : excellent pour Next.js, mais la facture dépasse le siège

Vercel intègre étroitement Next.js et les preview deployments. Hobby inclut des ressources de fonction, tandis que d’autres usages restent distincts :

• 4 heures d’Active CPU.
• 360 GB-hours de Provisioned Memory.
• 1 million d’invocations de Functions.
• 0,0035 dollar par minute CPU de build avec on-demand concurrency ou Elastic build machines.
• 20 dollars par mois pour chaque siège payant supplémentaire.
• 100 deployments par jour en Free et 6 000 en Pro.
• 5 000 uploads par jour en Free et 40 000 en Pro.

La facture peut contenir plusieurs catégories :

• Functions : CPU, mémoire et invocations.
• Images : transformations, cache reads et cache writes.
• Builds : CPU avec les configurations de build facturées.
• Analytics : Web Analytics et Speed Insights.
• Observability : monitoring à l’événement et options associées.

Points d’alerte :

• Beaucoup de previews augmentent les builds et deployments ; machines ou concurrence facturées ajoutent un coût.
• Image Optimization possède ses propres quotas et tarifs à la demande.
• Analytics et Observability sont aussi des postes séparés.

Vercel reste un bon choix initial pour un produit Next.js full-stack. Le prix du plan, chaque catégorie d’usage et les sièges doivent toutefois être suivis indépendamment.

2.4 Railway : runtime de conteneur facturé aux ressources

Railway est un PaaS pour services, workers et bases. Abonnement et ressources sont facturés séparément :

• Hobby coûte 5 dollars et Pro 20 dollars par mois.
• Hobby inclut 5 dollars d’usage de ressources.
• Pro inclut 20 dollars d’usage de ressources.
• La RAM coûte 10 dollars par GB-mois.
• Le CPU coûte 20 dollars par vCPU-mois.
• L’egress réseau coûte 0,05 dollar par GB.
• Le stockage volume coûte 0,15 dollar par GB-mois.
• Free autorise par défaut 0,5 GB de RAM, 1 vCPU et un volume de 0,5 GB par service.

Des décisions d’exploitation restent nécessaires :

• Surveiller la RAM, le CPU, l’egress et les volumes.
• Configurer des alertes de ressources et de logs.
• Connaître la fenêtre d’image retention pour rollback et rebuild.
• Définir health checks, redémarrages et sauvegardes.

Seuils de coût :

• L’usage au-delà des crédits de 5 ou 20 dollars est facturé en différence.
• Un service actif continue de consommer RAM, CPU et stockage.
• L’egress et les volumes persistants augmentent séparément.

Railway convient aux services Node, tâches de fond et bases. Il réduit le travail d’infrastructure sans supprimer la responsabilité du service.

3. Tableau de décision par type de charge

3.1 Sites de contenu et documentation

Un site de contenu se compose surtout d’assets statiques avec quelques fonctions dynamiques.

Pour Astro ou Hugo, Pages offre une distribution mondiale avec des limites souvent suffisantes au départ. Consultez le guide Cloudflare Pages et les limites Cloudflare Free.

Pour Next.js SSG, vérifiez le support actuel au lieu de répéter une ancienne affirmation. Vercel offre le workflow natif ; Cloudflare reste pertinent pour une sortie surtout statique.

Les commentaires et la recherche peuvent utiliser Pages Functions, mais leurs requêtes et CPU appartiennent à Workers. Séparez livraison statique et exécution dynamique.

3.2 Outils statiques et dynamiques

Un générateur ou convertisseur peut fonctionner dans le navigateur ; connexion et données persistantes en font un produit dynamique.

Un outil côté navigateur convient à Pages. Une petite API convient à Workers si les requêtes restent légères et compatibles avec un isolate.

Un outil Next.js full-stack profite de Vercel, mais previews, images, runtime de fonction et monitoring doivent être budgétés séparément.

3.3 Dashboards SaaS

Un dashboard SaaS demande logique applicative, autorisation, données et souvent collaboration.

Alibaba Cloud - Choix n°1 des développeurs, 15 % de réduction exclusive sur Lighthouse

Obtenir -15 % →Pub

Vercel est le départ direct pour Next.js. Vérifiez Functions, Images, preview Builds, Analytics, Observability et sièges au lieu de considérer Pro comme tout compris. Le comparatif des tarifs Cloudflare apporte du contexte.

Pour d’autres frameworks, comparez adapters et fonctions runtime actuels. Workers favorise la logique edge ; Vercel les frameworks serverless pris en charge.

La base de données reste une décision distincte. Supabase, Postgres géré, D1 et Railway Volumes ont leurs propres limites de coût et de fiabilité.

3.4 Tâches longues et services conteneurisés

Rapports, fichiers, consumers de queue et API persistantes demandent un autre runtime qu’une courte fonction.

Railway exécute un processus Node persistant dans un runtime complet. Il faut en retour gérer limites, logs, health checks, redémarrages et sauvegardes.

Un Railway Volume conserve les données, mais son prix ne suffit pas à définir une stratégie de base. Sauvegardes et tests de restauration sont indispensables.

Pour une tâche planifiée, définissez une alerte et un profil maximal de ressources. Un worker permanent ou gourmand peut dépasser le crédit Hobby.

4. Modèles de coût et seuils d’alerte

4.1 Modèle Cloudflare

Cloudflare sépare la livraison statique Pages de l’exécution Workers.

Assets statiques Pages :

• Les assets statiques sont distribués sans coût de transfert à l’usage dans les limites Pages.
• Près de 500 builds mensuels, réduisez les déploiements inutiles.
• Près de 20 000 fichiers, déplacez les gros assets vers un object storage.
• Pages Functions utilise Workers plutôt qu’un quota dynamique illimité séparé.

Exécution Workers :

• Free inclut 100 000 requêtes/jour et 10 ms CPU par requête HTTP.
• Workers Paid commence par un abonnement mensuel de 5 dollars.
• Standard inclut 10 millions de requêtes par mois.
• Standard inclut 30 millions de millisecondes CPU par mois.

Seuils :

• Les limites Pages peuvent bloquer de nouveaux builds.
• La croissance des requêtes ou du CPU impose Workers Paid.
• Pages statique gratuit ne signifie pas Pages Functions illimité.

Une première architecture courante combine Pages et Workers Free. Définissez le passage à Paid avant que le trafic ou le CPU ne l’impose.

4.2 Modèle Vercel

Vercel sépare plusieurs ressources d’infrastructure et d’expérience développeur.

Ressources Function Hobby :

• 4 heures d’Active CPU.
• 360 GB-hours de Provisioned Memory.
• 1 million d’invocations.
• 0,0035 dollar par minute CPU avec on-demand concurrency ou Elastic build machines.

Catégories d’usage :

• Functions : Active CPU, mémoire provisionnée et invocations.
• Images : transformations, cache reads et cache writes.
• Builds : previews et production avec configuration facturée.
• Analytics : Web Analytics et Speed Insights.
• Observability : événements et monitoring.

Sièges :

KiloClaw - OpenClaw managé pour l’entreprise : orchestration d’agents IA et routage intelligent

Commencer →Pub

• Chaque siège payant supplémentaire coûte 20 dollars par mois.
• Le siège n’absorbe pas les dépassements d’infrastructure ou d’options.

Seuils :

• Les previews fréquentes augmentent l’usage de build et les deployments.
• Les images ont leurs propres inclusions et tarifs.
• Analytics et Observability se vérifient séparément.
• CPU, mémoire et invocations des Functions sont à comparer au plan actuel.

Lisez la page d’usage catégorie par catégorie. Le gain de temps Next.js peut coexister avec une facture en plusieurs lignes.

4.3 Modèle Railway

Railway combine abonnement et ressources mesurées.

Plans et usage inclus :

• Hobby coûte 5 dollars avec 5 dollars d’usage inclus.
• Pro coûte 20 dollars avec 20 dollars d’usage inclus.
• Free fournit jusqu’à 0,5 GB de RAM, 1 vCPU, un volume de 0,5 GB et un petit crédit mensuel.

Tarifs des ressources :

• RAM : 10 dollars par GB-mois.
• CPU : 20 dollars par vCPU-mois.
• Egress réseau : 0,05 dollar par GB.
• Volume : 0,15 dollar par GB-mois.
• Les images supprimées restent accessibles uniquement pendant la retention du plan.

Seuils :

• L’usage au-delà du crédit est facturé en différence.
• Un service non arrêté continue de consommer RAM, CPU et stockage.
• Egress et volumes peuvent croître indépendamment de l’abonnement.

Railway évite une partie de la configuration VPS, pas le suivi des ressources. Configurez les alertes et connaissez la fenêtre de rollback avant la production.

5. Maintenance : fréquence, logs, rollback et collaboration

Les quotas de build et de deployment comptent pour les projets modifiés souvent. La collaboration ajoute sièges et permissions.

Fréquence des deployments et builds

• Cloudflare Pages Free autorise 500 builds par mois et un build simultané ; les preview builds Git consomment ce quota.
• Vercel autorise 100 deployments/jour en Free et 6 000 en Pro ; les previews augmentent aussi l’usage de build.
• Railway ne publie pas ici le même compteur, mais les images supprimées ne restent disponibles que pendant la fenêtre de rollback du plan.

Surveillez builds Pages et deployments Vercel avant qu’ils ne bloquent l’itération. Vérifiez aussi si la machine ou concurrence Vercel choisie est facturée.

Logs, rollback et accès de l’équipe

• Cloudflare Pages fournit logs de build, historique et rollback ; vérifiez les conditions actuelles de compte et de permissions.
• Vercel fournit previews, historique, logs, Analytics et sièges payants ; chaque siège supplémentaire coûte 20 dollars par mois.
• Railway fournit logs et métriques ; health checks, redémarrages, sauvegardes et collaboration doivent être configurés explicitement.

Choisissez le workflow qui supprime le plus de travail répétitif sur le service principal. Les previews comptent pour Next.js ; des builds statiques prévisibles comptent pour un site de contenu.

6. Ensuite : bases de données, stockage et CI/CD

La plateforme de déploiement n’est qu’une couche. Base de données, stockage, CI/CD, monitoring et alertes exigent des choix séparés. Le prochain article compare Supabase, Postgres, Railway Volumes et l’object storage.

L’objectif n’est pas de minimiser le nombre de fournisseurs, mais de placer chaque charge dans un runtime dont les limites, la facture et la responsabilité restent compréhensibles avant la croissance.