Vercel m'a longtemps convenu. Tu pousses ton code, trente secondes plus tard c'est en ligne avec un certificat valide, un CDN et des previews par branche. Pour démarrer un projet, je ne connais rien de plus confortable. Le problème arrive après, quand le projet vit. La facture grimpe avec le trafic et les fonctions serverless, certaines fonctionnalités propriétaires deviennent compliquées à reproduire ailleurs, et tu finis par ne plus vraiment savoir où ni comment ton app tourne. C'est un excellent point de départ, et un piège dès qu'on veut maîtriser son coût et son infra.
Pour ce portfolio comme pour plusieurs projets clients, j'ai pris le chemin inverse. Un VPS à quelques euros par mois, une image Docker, un reverse proxy, un pipeline maison. L'idée n'est pas de revenir à l'âge de pierre du déploiement par FTP : je garde le « git push et c'est en ligne », mais sur une machine que je contrôle de bout en bout. Voici comment c'est câblé, et les deux ou trois endroits où je me suis fait avoir.
L'image Docker : tout repose sur le mode standalone
La pièce qui change tout, c'est output: "standalone" dans next.config.ts. Au build, Next trace exactement les fichiers nécessaires au runtime et les recopie dans .next/standalone/. On passe d'une image d'environ 1 Go à environ 200 Mo. Sans ça, tu traînes tout node_modules dans ton conteneur de prod pour rien.
Le Dockerfile est multi-stage : une étape pour installer les dépendances, une pour builder, une dernière qui ne garde que le strict nécessaire.
# deps : installe les dépendances (cache Docker optimal)
FROM node:22-alpine AS deps
WORKDIR /app
COPY package.json yarn.lock .yarnrc.yml ./
RUN corepack enable && yarn install --immutable
# builder : build l'app
FROM node:22-alpine AS builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
RUN corepack enable && yarn build
# runner : image finale, non-root
FROM node:22-alpine AS runner
WORKDIR /app
ENV NODE_ENV=production
RUN addgroup -g 1001 nodejs && adduser -u 1001 -G nodejs -S nextjs
COPY --from=builder /app/public ./public
COPY --from=builder --chown=nextjs:nodejs /app/.next/standalone ./
COPY --from=builder --chown=nextjs:nodejs /app/.next/static ./.next/static
USER nextjs
EXPOSE 3000
CMD ["node", "server.js"]Deux choses méritent qu'on s'y arrête. L'image finale tourne en utilisateur non-root (nextjs:nodejs), parce qu'un conteneur web qui tourne en root, c'est une mauvaise habitude qu'on garde rarement gratuitement. Et il faut recopier public/ et .next/static/ à côté du server.js standalone à la main : Next ne le fait pas pour toi, et si tu oublies, ton app démarre mais sert tes pages sans CSS ni images.
Variables d'environnement : le build et le runtime ne jouent pas dans la même équipe
C'est le piège dans lequel tombe à peu près tout le monde une fois. Avec Next, les variables ne se comportent pas toutes pareil. Les NEXT_PUBLIC_* sont inlinées au moment du build : elles finissent en clair dans le bundle JavaScript envoyé au navigateur. Il faut donc les passer en ARG au docker build, sinon elles seront tout simplement vides côté client. Les secrets serveur, eux (la clé d'API d'envoi d'e-mails, le secret reCAPTCHA), sont lus au runtime et n'ont rien à faire dans l'image. Tu les injectes au lancement du conteneur via un env_file.
En pratique, mon docker-compose de prod référence un .env.production jamais committé pour les secrets, et reçoit les NEXT_PUBLIC_* en build.args. La règle que je garde en tête : si une valeur doit être visible dans le navigateur, elle est bakée au build ; si elle doit rester secrète, elle arrive au runtime. Confondre les deux, c'est soit une variable vide en prod, soit une clé secrète publiée dans ton bundle.
Le reverse proxy : du SSL automatique, sans toucher à un fichier de conf
Le conteneur écoute sur le port 3000, mais je ne l'expose pas sur l'hôte. À la place, il rejoint un réseau Docker partagé avec un reverse proxy qui se charge du HTTPS et du routage. Ici j'utilise Nginx Proxy Manager, et autant le dire tout de suite : c'est un choix parmi d'autres, pas une obligation. Caddy ou Traefik font le même travail très bien. Si je prends Nginx Proxy Manager pour cet article, c'est pour sa simplicité de démonstration : tout se pilote depuis une interface graphique. Tu crées un « Proxy Host », tu pointes sergent.dev vers le conteneur portfolio sur le port 3000, tu coches Let's Encrypt, et le certificat est émis puis renouvelé tout seul. Le routage et le SSL se gèrent au clic, sans jamais ouvrir un fichier de configuration.
C'est aussi sa limite. Caddy et Traefik sont plus dans la philosophie infra-as-code : la conf vit dans un fichier versionné, reproductible, qui part avec ton dépôt. Pour un serveur que tu montes une fois et que tu laisses tourner, l'interface graphique de NPM est imbattable en confort. Pour une infra que tu veux pouvoir recréer à l'identique sur commande, je regarderais plutôt du côté de Caddy. Les deux approches sont défendables ; je voulais surtout que tu saches que la brique est interchangeable.
Côté compose, le service ne publie aucun port sur l'hôte. Il rejoint juste le réseau du proxy.
# docker-compose.prod.yml (extrait)
services:
portfolio:
image: ghcr.io/<owner>/portfolio:latest
container_name: portfolio
env_file: .env.production
networks: [nginx-manager_default] # réseau partagé avec le proxy
restart: unless-stopped
networks:
nginx-manager_default:
external: trueAucun port applicatif n'est joignable directement depuis Internet. Le seul point d'entrée, c'est le proxy en 443. Plusieurs apps peuvent vivre derrière le même, chacune sur son sous-domaine.
Le pipeline : retrouver le « push et c'est en ligne »
Tout le reste ne sert à rien si déployer redevient une corvée manuelle. L'objectif, c'est de retrouver exactement le réflexe de Vercel : je pousse sur master, et l'app part en prod toute seule. Un workflow GitHub Actions s'en occupe.
push master
├─► lint
├─► scan sécurité (Trivy, bloquant sur CVE corrigeables)
└─► build → push image vers GHCR (registre privé GitHub)
└─► deploy : SSH sur le VPS → docker compose pull → up -d
L'image est stockée sur GHCR, le registre de conteneurs de GitHub. L'étape de déploiement se connecte en SSH au VPS, fait un docker compose pull puis un up -d : le nouveau conteneur remplace l'ancien sans coupure visible. J'ajoute un scan Trivy qui fait échouer le pipeline dès qu'une dépendance présente une faille critique avec un correctif disponible. La sécurité n'est pas une revue qu'on fait « plus tard », elle est dans le chemin du déploiement. Si une CVE corrigeable passe, rien ne part en prod.
Le bug qu'aucun build vert ne signale
Je garde le meilleur pour la fin, parce que c'est celui qui m'a coûté le plus de temps. Avec output: "standalone", la commande next start ne sert pas l'app correctement. Ce n'est pas un bug, c'est juste que ce n'est plus la bonne commande : il faut lancer node .next/standalone/server.js. Si tu gardes next start dans ton conteneur, tu peux passer un moment à te demander pourquoi ça ne répond pas.
Plus vicieux encore : un next build qui passe au vert ne garantit pas que toutes tes pages rendent. Une page qui appelle notFound(), ou une route statique sans paramètres générés, est prérendue en 404 sans la moindre erreur de build. Le pipeline est tout vert, l'image est poussée, déployée, et c'est en production que tu découvres ta page cassée.
La parade tient en une ligne et trente secondes. Avant chaque mise en prod, je lance node .next/standalone/server.js en local, avec .next/static et public recopiés à côté comme dans l'image réelle, et je vérifie au curl que mes pages clés répondent bien 200. C'est ce smoke test qui attrape les 404 silencieux avant qu'un visiteur ne les voie. Un build vert, ça ment parfois ; le serveur standalone qui tourne pour de vrai, jamais.
Self-héberger une app Next.js moderne ne m'a jamais semblé ni compliqué ni nostalgique. C'est quelques fichiers de conf, une bonne fois, et ensuite le même confort qu'une plateforme managée, sur une machine dont je connais le prix exact et le contenu. Pour un site vitrine, une app métier ou un SaaS qui démarre, c'est le compromis que je referais sans hésiter.
Si tu veux un coup de main pour héberger ou déployer ton app, parlons de ton projet.