Déployer un site Next.js 16 sur Hostinger depuis GitHub

Pourquoi pas Vercel ?

Vercel est l'hébergeur naturel de Next.js, et il fonctionne très bien. Mais quand on a déjà un hébergement mutualisé pour ses sites WordPress, ses sous-domaines et ses e-mails, il est pratique de tout regrouper au même endroit. Hostinger propose maintenant l'hébergement d'applications Node.js, ce qui permet de faire tourner un vrai serveur Next.js, avec les routes API et le rendu à la demande.

C'est comme ça que ce portfolio est en ligne. Voici la méthode, et les pièges que j'ai rencontrés.

1. Créer le site Node.js et connecter GitHub

Dans le panneau Hostinger (hPanel), on ajoute un site de type application Node.js, puis on connecte son compte GitHub et on choisit le dépôt. Les réglages à vérifier :

Hostinger détecte que c'est un projet Next.js et active le déploiement automatique : chaque push sur main déclenche un nouveau build.

2. Les variables d'environnement

Le formulaire de contact de ce site envoie des e-mails avec Resend, ce qui demande une clé d'API. Cette clé ne doit jamais se retrouver dans le dépôt GitHub.

// app/api/contact/route.ts
const resend = new Resend(process.env.RESEND_API_KEY);

En local, la clé est dans un fichier .env ignoré par Git. En production, on la déclare dans les réglages du site sur hPanel, dans la section des variables d'environnement.

3. Le workflow au quotidien

Comme chaque push sur main part directement en ligne, main doit toujours contenir du code testé. Ma routine :

# 1. Travailler sur une branche dédiée
git switch -c chore/update-deps

# 2. Vérifier que le build passe en local
npm run build

# 3. Fusionner dans main une fois tout validé
git switch main
git merge chore/update-deps

# 4. Pousser : Hostinger lance le déploiement
git push origin main

4. Lire les logs de build

Chaque déploiement produit un journal détaillé, découpé en étapes : clonage du dépôt, installation des dépendances, build, publication, redémarrage. Sur ce portfolio, un déploiement complet prend un peu plus d'une minute.

==> Cloning repository
==> Installing dependencies
==> Building
▲ Next.js 16.4.3 (webpack)
✓ Compiled successfully
✓ Generating static pages (31/31)
==> Publishing
==> Restarting application
Deployment completed in 1m 14s

Si le build échoue, le site en ligne n'est pas touché : la nouvelle version n'est publiée qu'une fois le build réussi. Il suffit de lire l'erreur dans le journal, de corriger, et de pousser à nouveau.

Les pièges que j'ai rencontrés

Les avertissements SWC. Dans les logs, on peut voir passer de nombreux messages Attempted to load @next/swc-linux-x64-gnu, but an error occurred. Le serveur utilise une version du système trop ancienne pour le compilateur natif de Next.js, qui bascule alors sur sa version WebAssembly. C'est plus lent, mais le résultat est identique : ces messages ne bloquent rien.

Turbopack. Next.js 16 utilise Turbopack par défaut pour le build. Comme il dépend de ces mêmes binaires natifs, je force webpack dans le package.json :

"scripts": {
	"build": "next build --webpack"
}

Les images. Comme un vrai serveur Node.js tourne, le composant next/image optimise les images normalement. Pour des images hébergées ailleurs (ici, un sous-domaine dédié), il faut simplement autoriser le domaine dans next.config.js avec remotePatterns.

En résumé

Une fois en place, mettre le site à jour se résume à un git push. C'est exactement ce qu'on attend d'un déploiement : qu'on n'ait plus besoin d'y penser.