Vercel exécute désormais n'importe quel Dockerfile sur sa plateforme Fluid compute

Vercel ajoute à sa plateforme la prise en charge des conteneurs arbitraires. Les développeurs peuvent désormais déployer n'importe quel service doté d'un Dockerfile, d'un service en Go à une application Rails ou Spring Boot. Il leur suffit de placer un fichier Dockerfile.vercel à la racine du projet : la plateforme construit l'image et la déploie sur l'infrastructure Fluid compute.

Comment ça marche

Le mécanisme est minimal : le serveur lui-même et un fichier Dockerfile.vercel suffisent à rendre le projet déployable. Vercel donne l'exemple d'un serveur HTTP en Go qui écoute le port défini dans la variable $PORT (80 par défaut). Il est construit via un Dockerfile en deux étapes : l'image golang:1.24-alpine compile d'abord le binaire, qui est ensuite copié dans l'image minimale alpine:3.20, celle qui tourne en production.

Depuis la CLI, la commande `vercel deploy` construit l'image, la stocke dans le registre du projet, la déploie sur Fluid compute et renvoie une URL de production. Chaque git push reconstruit automatiquement l'image et crée un déploiement de preview distinct, avec une URL immuable que l'on peut ouvrir, partager avec ses collègues ou utiliser pour revenir à une version antérieure.

• La seule exigence côté serveur : écouter un port HTTP défini dans la variable $PORT
• L'exemple du blog repose sur le duo golang:1.24-alpine et alpine:3.20 dans un build en deux étapes
• Le déploiement se lance d'une seule commande `vercel deploy` depuis la CLI, ou automatiquement à chaque 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 insiste : la stack importe peu. Tout service capable de parler HTTP et d'écouter un port fonctionne. La liste cite explicitement Rails, Spring Boot, Express, Laravel, ASP.NET, FastAPI et les serveurs web derrière nginx, Java et PHP compris. Ces plateformes étaient jusqu'ici davantage associées à l'hébergement serveur classique qu'à l'infrastructure serverless de Vercel.

Ce que les développeurs y gagnent

Sur Vercel, le conteneur devient un citoyen à part entière de la plateforme : il tourne sur la même infrastructure que le frontend et les autres services du projet. Chaque commit obtient son propre déploiement de preview avec une URL dédiée. Le scaling s'opère automatiquement dans les deux sens : la plateforme ajoute des instances quand le trafic augmente et les retire quand il baisse. L'équipe n'a plus à dimensionner manuellement sa flotte ni à fixer une limite de concurrence.

La facturation repose sur le modèle Active CPU : Fluid compute ne facture que le temps pendant lequel le code du service s'exécute réellement, et non toute la durée de vie de l'instance. Concrètement, un serveur inactif, bloqué sur une requête lente vers la base de données, ne coûte pas plus cher à l'équipe qu'un serveur en pleine activité.

Ce que ça change

Dockerfile.vercel efface la frontière entre les plateformes serverless comme Vercel et les clouds de conteneurs classiques. N'importe quel service en Java, PHP ou Ruby peut désormais être déployé sans configurer son propre registre d'images, démon ou cluster, avec l'autoscaling et les déploiements de preview activés par défaut.

Questions fréquentes

Quelles sont les exigences pour déployer un serveur ?

Une seule condition : le serveur doit écouter en HTTP sur le port défini dans la variable d'environnement $PORT (80 par défaut). Si le service répond aux requêtes HTTP, on peut l'encapsuler dans un Dockerfile.vercel et le déployer.

Que se passe-t-il à chaque commit ?

Chaque git push reconstruit l'image et crée une URL de preview distincte, que l'on peut ouvrir, partager ou utiliser pour revenir à une version précédente du projet.

Avec quels frameworks cela fonctionne-t-il ?

Rails, Spring Boot, Express, Laravel, ASP.NET, FastAPI et les services derrière nginx. L'exemple du blog de Vercel s'appuie sur le duo golang:1.24-alpine et alpine:3.20 dans un build en deux étapes.