Deployer Next.js 15 sur Vercel ou Coolify : tutoriel pas-a-pas

Une application Next.js 15 finie n’a pas grand intérêt tant qu’elle tourne sur localhost:3000. Le déploiement est l’étape qui transforme du code en service utilisable, et c’est là que les choix d’infra deviennent concrets. Deux options dominent largement aujourd’hui : Vercel, créateur du framework, qui propose une plateforme managée optimisée jusqu’à l’extrême pour Next.js ; et Coolify, plateforme open-source d’auto-hébergement qui passe en version 4.0 stable et offre une expérience proche du PaaS sur n’importe quel VPS.

Ce tutoriel monte le déploiement complet d’une même app Next.js 15 sur les deux plateformes, traite les variables d’environnement, le domaine personnalisé, l’observabilité, et les coûts. À la fin, vous saurez choisir entre les deux en connaissance de cause et reproduire le setup sur n’importe quel projet.

Prérequis

• Une application Next.js 15 fonctionnelle en local
• Un dépôt Git distant (GitHub, GitLab, ou Bitbucket)
• Pour Vercel : un compte sur vercel.com (gratuit)
• Pour Coolify : un VPS sous Ubuntu 24.04 LTS avec au moins 2 vCPU et 4 Go RAM (Hetzner CX22 à partir de 4,49 €/mois (HEL1) fait largement l’affaire)
• Niveau : intermédiaire
• Temps estimé : 60 minutes pour Vercel, 90 minutes pour Coolify (installation comprise)

Voie A — Vercel

Étape 1 — Connecter le dépôt

Sur vercel.com, cliquer Add New → Project, autoriser l’accès au compte GitHub, et sélectionner le dépôt. Vercel détecte automatiquement qu’il s’agit d’un projet Next.js et pré-remplit les commandes de build (next build) et le dossier de sortie (.next). Aucune configuration manuelle n’est nécessaire pour un projet standard.

L’écran suivant demande les variables d’environnement. C’est l’endroit où on colle DATABASE_URL, AUTH_SECRET, les clés Stripe ou Paystack, etc. On peut les ajouter par lot via copie depuis le .env local. Vercel sépare les environnements Production, Preview et Development — utile pour avoir une base de staging séparée sur les pull requests.

# Exemple .env de production
DATABASE_URL=postgres://user:pass@db.exemple.com/prod
AUTH_SECRET=K7HnY3pQ...
AUTH_GITHUB_ID=abc123
AUTH_GITHUB_SECRET=def456
NEXT_PUBLIC_API_URL=https://api.exemple.com

Cliquer Deploy. Vercel clone le dépôt, installe les dépendances, lance next build, et déploie sur son réseau Edge mondial. Le premier build prend deux à cinq minutes selon la taille du projet. À la fin, on obtient une URL en https://votre-projet.vercel.app immédiatement accessible.

Étape 2 — Domaine personnalisé et HTTPS

Dans Project → Settings → Domains, ajouter le domaine ou sous-domaine voulu, par exemple boutique.exemple.com. Vercel affiche les enregistrements DNS à configurer chez le registrar (généralement un CNAME pour les sous-domaines, un A pour les domaines apex). Une fois la propagation DNS effectuée (de quelques minutes à 48h selon le registrar), le certificat Let’s Encrypt est généré automatiquement. Aucune manipulation à faire — HTTPS fonctionne dès que le DNS pointe correctement.

Étape 3 — Preview deployments par pull request

C’est le gros confort qu’apporte Vercel. Chaque push sur une branche déclenche un déploiement séparé avec une URL unique en https://votre-projet-git-feature-username.vercel.app. Le bot Vercel commente automatiquement la PR avec le lien. Les designers, product managers et clients peuvent tester la branche en cours sans la merger. Cela accélère les revues et démocratise la validation visuelle.

Pour utiliser une base différente sur les previews, créer une copie de la base de prod (ou utiliser un service comme Neon avec branches automatiques) et configurer DATABASE_URL uniquement pour l’environnement Preview. Les variables sont disjointes par environnement.

Étape 4 — Logs, observabilité, et limites

L’onglet Logs du dashboard Vercel montre en temps réel les requêtes, leur statut, leur durée, et les erreurs. L’onglet Analytics donne les Core Web Vitals mesurés réellement chez les visiteurs. Pour creuser plus loin, l’intégration native avec Sentry, Logtail, ou Datadog se configure en un clic depuis Integrations.

Le plan Hobby (gratuit) couvre largement un projet personnel ou un MVP : 100 GB de bande passante (Fast Data Transfer), 1 million d’invocations de Server Functions et 4 heures CPU actives par mois, déploiements illimités. Au-delà, le plan Pro à 20 $/utilisateur/mois ajoute des limites professionnelles, le support prioritaire, et des fonctionnalités d’équipe. Important : le plan Hobby ne permet pas l’usage commercial — pour une vraie boutique, il faut passer en Pro.

Voie B — Coolify sur VPS

Étape 5 — Installer Coolify v4 sur Ubuntu 24.04

Coolify s’installe en une commande sur un Ubuntu fraîchement provisionné. Connecter le VPS en SSH puis exécuter le script officiel.

curl -fsSL https://cdn.coollabs.io/coolify/install.sh | sudo bash

Le script télécharge l’image Docker, configure le proxy Traefik (qui gère HTTPS automatiquement), et démarre l’interface d’administration sur le port 8000. Pour un VPS Hetzner standard, l’installation prend cinq à dix minutes. À la fin, le script affiche l’URL et les credentials initiaux d’admin.

Accéder à http://IP_DU_VPS:8000 et compléter le wizard d’initialisation. C’est aussi le moment d’ajouter un domaine pour Coolify lui-même (par exemple coolify.exemple.com) avec un CNAME chez le registrar. Une fois le domaine actif, Coolify le sert en HTTPS via Traefik.

Étape 6 — Connecter le dépôt et déployer

Dans Coolify, cliquer + New → Public Repository (pour un dépôt public) ou GitHub App (pour un dépôt privé avec OAuth). Coolify détecte automatiquement le buildpack Nixpacks pour Next.js, qui produit une image Docker optimisée sans Dockerfile à écrire.

Dans la section Build Pack, Nixpacks est sélectionné par défaut pour Node. Confirmer la version Node (20 LTS) et la commande de start (pnpm start par défaut). Ajouter les variables d’environnement dans l’onglet Environment Variables, exactement comme sur Vercel. Coolify gère aussi la séparation production / preview si on active les déploiements par PR.

Cliquer Deploy. Coolify clone le repo, lance le build dans un container, puis publie le résultat derrière Traefik. Premier build : 3 à 6 minutes. L’URL générée est en https://votre-app.coolify.exemple.com tant qu’on n’a pas configuré de domaine custom.

Étape 7 — Domaine et HTTPS sous Coolify

Dans Domains, ajouter boutique.exemple.com. Coolify configure automatiquement Traefik pour router ce domaine vers le container de l’app, et demande un certificat Let’s Encrypt. Une fois le DNS pointé (A record vers l’IP du VPS), le certificat est délivré en moins d’une minute.

Pour les apps multi-tenant ou les preview branches, Coolify supporte le wildcard DNS et les sous-domaines dynamiques — un cran moins poli que Vercel mais fonctionnel.

Étape 8 — Comparer concrètement les deux options

Approche pragmatique : commencer sur Vercel pour aller vite, mesurer les coûts au bout de trois mois, basculer sur Coolify si la facture devient lourde par rapport à la valeur générée. Migrer dans l’autre sens (Coolify → Vercel) est aussi simple — c’est juste le même code Next.js. C’est l’un des grands intérêts de la stack : aucune des deux options ne lock le code.

Étape 9 — Choisir l’hébergement de la base

Quel que soit le choix Vercel / Coolify, la base de données est un sujet à part. Quatre options pertinentes en 2026.

Neon propose Postgres serverless avec mise à l’échelle automatique, branches isolées pour les previews, et un plan gratuit (0,5 GB stockage, suffisant pour démarrer). S’intègre nativement avec Vercel via le marketplace.

Supabase propose Postgres + auth + storage + realtime en un seul service hébergé. Plan gratuit généreux (500 MB DB, 1 GB storage). Le SDK JS s’utilise très bien depuis les Server Components Next.js.

Railway permet de provisionner Postgres en un clic à côté de l’app si on déploie aussi l’app sur Railway. Tarification à l’usage, généralement entre 5 $ et 20 $ par mois pour une petite app.

Postgres auto-hébergé sur le même VPS Coolify est l’option la plus économique : Coolify peut déployer un container Postgres en quelques clics, avec sauvegardes automatiques vers S3. Pour un projet avec moins de 100 utilisateurs actifs, c’est largement suffisant et coûte 0 € supplémentaire (sauf le stockage des backups).

Étape 10 — Vérification finale et signaux à surveiller

Une fois déployé, plusieurs vérifications valent le coup d’œil dans la première semaine.

# Vérifier les en-têtes HTTP de production
curl -I https://boutique.exemple.com

# Tester la performance avec Lighthouse CLI
npx lighthouse https://boutique.exemple.com --output=html --output-path=./lh.html

# Charger une page protégée avec un cookie de session
curl -H "Cookie: session=..." https://boutique.exemple.com/compte

Surveiller particulièrement : le TTFB (Time To First Byte) qui doit rester sous 500 ms, le Largest Contentful Paint sous 2,5 s, et le ratio cache hit (visible dans les logs Vercel ou via les headers x-vercel-cache / cache-control). Si une route prétendument statique génère une fonction serverless à chaque visite, c’est qu’une API dynamique s’y est glissée — relancer la chasse via pnpm build en local et examiner la sortie.

Erreurs fréquentes

Étape 11 — Sauvegardes et reprise sur incident

Le sujet le moins glamour mais le plus critique. Une app en prod sans sauvegarde testée est une app en sursis. Les patterns à appliquer dès le jour du déploiement.

Sur Vercel, l’app elle-même est stateless — il n’y a rien à sauvegarder côté code (le repo Git est la source de vérité). Le travail porte uniquement sur la base : configurer les snapshots automatiques chez le fournisseur (Neon, Supabase, Railway font tous des snapshots quotidiens inclus dans leurs plans payants) et tester une restauration au moins une fois avant la mise en prod sérieuse. Si on utilise Neon, exploiter les branches pour cloner instantanément l’état actuel sur un environnement de test.

Sur Coolify, deux choses à sauvegarder : la base de données, et la configuration Coolify elle-même. Pour la base, Coolify offre une fonctionnalité native de backup vers S3 (ou un endpoint compatible comme Backblaze B2, Wasabi) — configurer la cible et la fréquence (quotidien minimum) depuis le menu Backups du service Postgres. Pour Coolify, exporter la configuration via le menu Settings → Backup Configuration avant chaque changement majeur. Les fichiers de config ne pèsent que quelques MB et permettent de remonter l’instance complète en cas de panne hardware.

Étape 12 — Quand passer à l’échelle, et comment

Trois signaux indiquent qu’il est temps de monter d’un cran l’infra. Premier : le TTFB en production dépasse régulièrement 1 seconde sur les requêtes dynamiques. Deuxième : le CPU du VPS (côté Coolify) ou la facture Vercel dépasse le seuil acceptable. Troisième : les visiteurs internationaux se plaignent de lenteur — signe qu’on a besoin d’un CDN ou d’une distribution multi-région.

Sur Vercel, le passage à l’échelle est transparent : payer plus, et le serverless absorbe la charge. C’est cher si la charge est constante, économique si elle est en pics. Sur Coolify, monter en VPS de gamme supérieure (CX32, CX42 chez Hetzner) prend cinq minutes et coûte le double mais reste très en dessous des plans Vercel équivalents. Pour la base, passer à un service managé (Neon, Supabase) si la charge devient sérieuse — un Postgres auto-hébergé sur 2 vCPU plafonne vers 200 requêtes/seconde, et déboguer un Postgres lent en production n’est pas un travail qu’on veut faire un dimanche.

Pour aller plus loin

Cet article fait partie d’une série sur React 19 et Next.js 15. Pour la vue d’ensemble et le parcours conseillé, consultez React 19 + Next.js 15 : architecture full-stack moderne.

Tutoriels frères :

• Auth.js et Clerk pour Next.js 15 — configurer les variables d’environnement de sécurité dans la plateforme choisie
• Data fetching et caching — surveiller le ratio cache hit en production
• App Router de Next.js 15 — comprendre pourquoi telle route apparaît dynamique dans la sortie de build

Ressources officielles :

• vercel.com/docs
• vercel.com — Environment Variables
• coolify.io/docs
• coolify.io — Deploying Next.js
• nextjs.org — Deploying Guide