Vercel a appris à exécuter n'importe quel Dockerfile sur la plateforme Fluid compute

Vercel a ajouté le support des conteneurs arbitraires à sa plateforme : les développeurs peuvent maintenant déployer n'importe quel service avec un Dockerfile — d'un service Go à une application Rails ou Spring Boot — en ajoutant simplement un fichier Dockerfile.vercel à la racine du projet, et la plateforme compilera l'image et la déploiera sur l'infrastructure Fluid compute.

Comment Ça Fonctionne

Le mécanisme est minimal : simplement le serveur et le fichier Dockerfile.vercel — et le projet est prêt à déployer. Vercel montre un exemple en Go : un serveur HTTP écoutant sur un port de la variable d'environnement $PORT (par défaut 80) est compilé via un Dockerfile en deux étapes — d'abord, l'image golang:1.24-alpine compile le binaire, puis il est copié dans une image minimale alpine:3.20, qui est celle qui s'exécute en production.

La commande `vercel deploy` de la CLI compile l'image, l'enregistre dans le registre du projet et la déploie sur Fluid compute, en retournant une URL de production. Chaque git push recompile automatiquement l'image et crée un déploiement d'aperçu séparé avec une URL immuable qui peut être ouverte, envoyée aux collègues ou utilisée pour revenir à une version antérieure.

• La seule exigence pour le serveur est d'écouter HTTP sur le port de la variable d'environnement $PORT
• L'exemple du blog est construit sur golang:1.24-alpine et alpine:3.20 dans une compilation en deux étapes
• Le déploiement est lancé avec une seule commande `vercel deploy` de la CLI, ou automatiquement en cas de git push
• Rails, Spring Boot, Express, Laravel, ASP.NET, FastAPI et les services derrière nginx sont pris en charge

Quels Langages et Frameworks Sont Pris en Charge

Vercel souligne que la pile spécifique n'a pas d'importance — tout service capable de parler HTTP et d'écouter un port fonctionne. Sont explicitement mentionnés Rails, Spring Boot, Express, Laravel, ASP.NET, FastAPI et les serveurs web derrière nginx, y compris Java et PHP — des plateformes qui étaient auparavant associées davantage à l'hébergement classique de serveurs qu'à l'infrastructure sans serveur de Vercel.

Ce que les Développeurs Obtiennent

Un conteneur sur Vercel devient un citoyen à part entière de la plateforme : il s'exécute sur la même infrastructure que le frontend et les autres services du projet. Chaque commit obtient son propre déploiement d'aperçu avec une URL séparée, et la mise à l'échelle se fait automatiquement dans les deux sens — lorsque le trafic augmente, la plateforme ajoute des instances ; lorsque le trafic diminue, elle les réduit, libérant l'équipe de la nécessité de calculer manuellement la taille de la flotte ou les limites de concurrence.

Le modèle de tarification est basé sur le CPU actif : Fluid compute facture uniquement le temps pendant lequel le code de service s'exécute réellement, et non la durée de vie entière de l'instance. Cela signifie qu'un serveur inactif bloqué sur une requête de base de données lente ne coûte pas plus à l'équipe qu'un serveur actif.

Ce Que Cela Signifie

La fonction Dockerfile.vercel brouille la ligne entre les plateformes sans serveur comme Vercel et les nuages de conteneurs classiques : maintenant, tout service s'exécutant sur Java, PHP ou Ruby peut être déployé sans configurer votre propre registre d'images, daemon ou cluster, tout en bénéficiant de la mise à l'échelle automatique et des déploiements d'aperçu par défaut.

Questions Fréquemment Posées

Quelles exigences un serveur doit-il satisfaire pour se déployer ?

La seule condition est que le serveur doit écouter HTTP sur le port de la variable d'environnement $PORT (par défaut 80). Si un service répond aux requêtes HTTP, il peut être enveloppé dans Dockerfile.vercel et déployé.

Que se passe-t-il à chaque commit ?

Chaque git push recompile l'image et crée une URL d'aperçu séparée qui peut être ouverte, envoyée à d'autres ou utilisée pour revenir à une version antérieure du projet.

Sur quels frameworks cela fonctionne-t-il ?

Rails, Spring Boot, Express, Laravel, ASP.NET, FastAPI et les services derrière nginx — l'exemple du blog Vercel utilise golang:1.24-alpine et alpine:3.20 dans une compilation en deux étapes.