vercel-hobby-plan-limits.html
< BACK Le bureau d'un développeur la nuit éclairé par la lueur de l'écran et une lampe chaude, avec une tasse de thé floue en avant-plan

Limites du Plan Hobby de Vercel (et quand vous les dépasserez)

C'était un jeudi soir et le site Next.js d'un client venait de tomber dans ce que je ne peux décrire que comme une spirale de timeout. Des fonctions serverless bloquées à 9,8 secondes, des utilisateurs voyant des écrans blancs, et moi qui vérifiais frénétiquement le tableau de bord de Vercel à minuit en essayant de déterminer si nous avions vraiment atteint une limite de plan ou si le code était juste terrible. (C'était les deux, honnêtement.) Ce projet était sur le plan Hobby. Il ne devrait probablement pas l'être.

J'ai déployé bien plus de 12 000 sites chez Seahawk Media au fil des années. Vercel fait constamment partie de notre stack, particulièrement pour le travail avec Next.js, rien d'autre ne s'en rapproche pour l'expérience développeur. Mais le plan Hobby a des angles tranchants qu'il est facile de rater jusqu'à ce qu'un projet vous morde. Donc voici ma véritable analyse sur où se trouvent ces angles et quand ils commencent à compter.

Ce que le Plan Hobby vous donne vraiment

Soyons précis. Depuis 2024, le plan Hobby de Vercel vous offre :Vercel's Hobby plan gives you:

  • 100 GB de bande passante par mois
  • 6 000 minutes de build par mois
  • Délai d'expiration de 10 secondes pour l'exécution des fonctions serverless10 seconds
  • 100 invocations de fonctions serverless par jour... attendez, non. Cette limite n'existe pas. Mais il y a un plafond de 100 Go-heures d'exécution de fonctions serverless par mois
  • 500 000 invocations de fonctions Edge par mois
  • 1 build concurrent à la fois
  • Les déploiements sont limités aux comptes personnels uniquement (pas d'équipes)personal accounts only (no teams)
  • Aucune utilisation commerciale autorisée selon les conditions de Vercel

Ce dernier point crée plus de confusion que n'importe quelle limite technique. Le plan Hobby est explicitement destiné aux projets personnels, non commerciaux. Si vous construisez quelque chose pour un client payant ou exploitez une activité quelconque dessus, vous violez déjà les conditions d'utilisation. J'ai vu des freelances le faire pendant des années et c'est un risque de responsabilité qui attend de se concrétiser.

Le délai d'expiration de 10 secondes pour les fonctions

C'est celui-ci qui pose problème. Dix secondes, ça semble beaucoup jusqu'à ce que vous fassiez un appel à une API tierce qui prend 4 secondes, que vous exécutiez une logique de base de données qui en ajoute 3, puis que vous fassiez quelque chose avec la réponse. Soudain vous êtes à 9,2 secondes sans aucune marge.

Sur le plan Pro, ce plafond monte à 60 secondes (et jusqu'à 900 secondes avec configuration sur Enterprise). Ce n'est pas une différence mineure. C'est la différence entre une intégration qui fonctionne et un produit fondamentalement cassé pour certains cas d'usage.

Build Minutes : Où Elles Disparaissent Plus Vite Que Tu Ne Le Penseras

6 000 build minutes par mois, ça semble généreux. Et pour un seul projet personnel, ça l'est probablement. Le problème, c'est que ce chiffre s'érode plus vite que prévu une fois que tu itères sérieusement.

En 2021, je maintenais un projet annexe, un agrégateur de contenu construit sur Next.js avec environ 400 pages statiques. J'avais ISR configuré mais je faisais aussi des reconstructions complètes fréquentes en expérimentant avec la couche de données. J'ai brûlé environ 4 200 build minutes en trois semaines. Pas parce que les builds étaient lents, mais parce que je les déclenchais constamment.

Chaque build sur un site Next.js de complexité moyenne peut facilement prendre 4 à 8 minutes. Si tu pushes sur main 15 fois par jour pendant le développement actif (ce qui est normal pour moi), ça représente 60 à 120 build minutes disparus en une seule journée. Fais ça pendant une semaine et tu auras consumé la moitié de ta allocation mensuelle.

Il n'y a pas de report. Les minutes ne se reportent pas d'un mois à l'autre. Et quand tu arrives à zéro, tes déploiements s'arrêtent. Point final.

Comment Ralentir la Consommation

Quelques trucs que je fais sur les projets Hobby plan pour préserver les build minutes :

  1. Pushes vers une branche non-production pour les changements expérimentaux. Merge sur main seulement quand quelque chose est vraiment prêt.
  2. Utilise vercel --prebuilt avec les sorties cachées où les artefacts de build n'ont pas changé significativement.vercel --prebuilt with cached outputs where the build artefacts haven't changed meaningfully.
  3. Configurez l'étape de build ignorée de Vercel pour ignorer les builds quand seuls certains fichiers changent (comme les mises à jour de readme ou les commits sans code).Vercel's ignored build step to skip builds when only certain files change (like readme updates or non-code commits).
  4. Regroupez les commits. Au lieu de pousser 6 petits correctifs séparément, indexez-les et poussez une seule fois.

Rien de tout cela n'est révolutionnaire. Mais en pratique, la plupart des devs sur les plans Hobby poussent librement et se demandent pourquoi ils n'ont plus de minutes le 20 du mois.

Bande passante : Généralement Correct, Occasionnellement Pas

100 GB de bande passante par mois, c'est là que le plan Hobby est vraiment assez raisonnable. Pour un projet personnel, un portfolio, un petit blog, même un modeste projet SaaS en parallèle avec quelques centaines d'utilisateurs, vous ne toucherez probablement pas ce plafond.

Où ça pose problème, c'est avec les sites gourmands en images sans couche CDN appropriée devant, ou les sites qui connaissent un pic soudain. J'ai eu un client, musicien, dont le site était sur mon compte Vercel personnel pendant une période de transition (je n'aurais pas dû, je le sais, utilisation commerciale et tout ça). L'une de ses morceaux a été repérée par une playlist de bonne taille et le site a reçu environ 40 000 visites en 48 heures. L'utilisation de la bande passante a grimpé. Heureusement, nous étions sous le plafond mais c'était assez serré pour que je les fasse migrer du Hobby immédiatement.

Si vous utilisez l'optimisation des images Next.js, sachez que les images optimisées servies via Vercel comptent dans votre bande passante. Et le plan Hobby a un plafond de 1 000 images source optimisées par mois. C'est une limite dont presque personne ne parle et elle vous rattrapera absolument si vous gérez un portfolio photographique ou n'importe quel site au contenu gourmand en images.Next.js Image Optimisation, be aware that optimised images served through Vercel count against your bandwidth. And the Hobby plan has a 1,000 source images cap on optimisation per month. That's a limit that almost nobody talks about and it will absolutely catch you if you're running a photography portfolio or any image-heavy content site.

La Question de l'Utilisation Commerciale Mérite Plus d'Attention

Je veux revenir sur ce point parce que je pense que c'est vraiment sous-estimé dans les cercles de freelance.

Les conditions de Vercel sont claires. Hobby est pour les projets personnels, non commerciaux. Du moment qu'un client vous paie pour construire quelque chose sur Hobby, ou du moment qu'un projet génère des revenus (publicités, abonnements, ventes), vous êtes en dehors des conditions. Ce n'est pas Vercel qui est agressif, c'est juste comment le plan est structuré.

J'ai parlé à des freelances qui déploient le travail client sur Hobby pour économiser. Certains l'ont fait pendant des années sans conséquence. Mais Vercel applique réellement cette règle. Ils peuvent et font contacter les comptes qui semblent avoir une activité commerciale. Faire retirer un site à cause d'une violation des conditions d'utilisation alors que l'activité d'un client en dépend n'est pas une conversation que tu veux avoir.

Le plan Pro coûte 20 $/mois par membre. Pour tout travail client réel, ce coût doit être intégré dans le budget de ton projet. C'est non-négociable.

Quand le Single Concurrent Build Devient Réellement un Problème

Un seul build concurrent n'a pas d'importance pour les projets personnels. Ça commence à avoir de l'importance quand tu travailles sur quelque chose de manière collaborative, même informelle. Deux personnes qui font des commits en rapide succession signifie que le second build attend derrière le premier.

Pour le travail solo, c'est sans objet. Mais si tu as un contributeur, un co-fondateur, un designer qui peut aussi faire des commits, tu remarqueras le temps d'attente. Sur Pro tu obtiens jusqu'à 12 builds concurrents. Le saut est substantiel.

Seahawk avait un petit projet d'outils internes plus tôt cette année où deux d'entre nous itérions rapidement sur la même base de code Next.js pendant un sprint. Nous étions sur Pro pour cela (pour la raison commerciale seule), et même ainsi, les builds qui se chevauchaient créaient occasionnellement des frictions. Sur Hobby ç'aurait été notablement pire.

Hobby vs Pro : L'Arbre de Décision Réel

Voici comment j'y réfléchis, concrètement :

  • Projet personnel, aucun revenu, développeur solo, moins de 50 pages : Hobby convient. Reste là. Hobby is fine. Stay there.
  • Projet annexe qui reçoit du vrai trafic (5 000+ visites mensuelles) : Commence à surveiller ta bande passante et tes heures d'exécution de fonction. Hobby fonctionne encore mais tu te rapproches des limites. Start watching your bandwidth and function execution hours. Hobby still works but you're closer to edges.
  • Tout travail client, quel qu'il soit : Pro. Point final. Pro. Full stop.
  • Application gourmande en API où les fonctions serverless approchent régulièrement 5+ secondes : Pro. Le délai d'expiration de 10 secondes n'est pas un plafond confortable à ce stade. Pro. The 10-second timeout is not a comfortable ceiling at that point.
  • Besoin de plusieurs membres d'équipe sur le compte : Pro. Hobby ne permet pas les comptes d'équipe. Pro. Hobby doesn't allow team accounts.
  • Gestion d'e-commerce, d'abonnements ou de tout flux transactionnel : Pro, et réfléchissez sérieusement à la question de savoir si le modèle serverless de Vercel convient à votre architecture. Pro, and probably think carefully about whether Vercel's serverless model suits your architecture anyway.

Pour tout ce qui dépasse même Pro, Vercel propose un tier Enterprise avec des limites personnalisées. Je n'ai touché à Enterprise que deux fois, tous les deux pour des clients avec des exigences SLA très spécifiques. Pour la plupart des gens qui lisent ceci, la décision Pro/Hobby est celle qui compte.

Alternatives à connaître

Si le budget est vraiment la contrainte, Vercel n'est pas votre seule option. Le tier gratuit de Netlify a une forme similaire à Vercel Hobby avec 300 minutes de build par mois (inférieur à Vercel, en fait) mais 100 Go de bande passante. Pour les sites statiques avec des besoins serverless minimes, Netlify est une comparaison raisonnable.Netlify's free tier has similar shape to Vercel Hobby with 300 build minutes per month (lower than Vercel, actually) but 100 GB bandwidth. For static sites with minimal serverless needs, Netlify is a reasonable comparison.

Cloudflare Pages mérite d'être considéré si votre cas d'usage convient aux Workers. Bande passante illimitée sur le tier gratuit, allocations de build généreuses, et la plateforme Pages a considérablement mûri. Je l'utilise pour les sites statiques où je n'ai pas besoin des fonctionnalités spécifiques de Next.js. is worth considering if your use case fits Workers. Unlimited bandwidth on the free tier, generous build allowances, and the Pages platform has matured significantly. I use it for static sites where I don't need Next.js-specific features.

Railway et Render sont bons pour les applications full-stack où vous voulez plus de contrôle qu'un modèle de déploiement serverless. Des compromis différents, pas exactement des concurrents directs de Vercel, mais qui valent la peine d'avoir dans votre arsenal.

FAQ

Le plan Vercel Hobby permet-il les domaines personnalisés ?

Oui. Vous pouvez ajouter des domaines personnalisés sur Hobby sans rien payer. Le SSL est inclus automatiquement via Let's Encrypt. C'est l'une des vraiment bonnes choses à propos de Hobby, il n'y a pas de limite artificielle sur les domaines personnalisés.

Que se passe-t-il quand vous atteignez la limite de bande passante du plan Hobby ?

Vercel ne retire pas immédiatement votre site. Ils vous notifieront et vous donneront la possibilité de passer à un plan supérieur. Mais vous êtes dans une zone grise une fois que vous avez dépassé la limite et Vercel peut ralentir ou suspendre si vous dépassez persistamment les limites sans passer à un plan supérieur.

Puis-je utiliser Vercel Hobby pour un projet client si je ne fais pas payer beaucoup ?

Le montant que vous facturez est sans importance aux yeux des conditions de Vercel. L'utilisation commerciale, c'est l'utilisation commerciale. Si quelqu'un vous paie, c'est commercial. Passez à Pro.

Le délai d'expiration de fonction de 10 secondes est-il une limite stricte ou flexible ?

Stricte. La fonction est arrêtée à 10 secondes sur Hobby. Vous verrez une erreur de délai d'expiration 504. Aucune configuration n'est disponible au niveau Hobby pour l'étendre.

Deux personnes peuvent-elles collaborer sur un projet Hobby ?

Pas via un compte d'équipe partagé. Hobby est réservé aux comptes personnels uniquement. Vous pouvez ajouter des collaborateurs à un projet spécifique (ils peuvent contribuer du code via Git), mais le compte Vercel et la facturation restent avec une seule personne. Pour de vrais workflows d'équipe, vous avez besoin de Pro.

---

Le plan Hobby est vraiment bon pour ce qu'il prétend être : des projets de loisir. Les limites sont raisonnables pour un usage personnel. Les gens se retrouvent en difficulté quand ils le traitent comme un tier Pro gratuit. Ce n'est pas le cas. Connaissez les plafonds, respectez les conditions d'utilisation commerciale, et quand un projet commence à générer des revenus ou à servir de vrais utilisateurs, payez les 20 $ par mois. Ce n'est pas worth le risque.

< BACK