Alternative à Vercel : déployer une app Next.js sans gérer de serveur

Vercel a rendu le déploiement d'une app Next.js presque trivial : on pousse sur Git, le site est en ligne. Beaucoup d'équipes s'en contentent, et c'est très bien. D'autres se posent un jour la question d'une alternative, pour des raisons qui n'ont rien de dramatique : une facture qui suit l'usage et devient difficile à prévoir, l'envie d'avoir l'application et sa base de données au même endroit, un besoin de processus qui tournent en continu, ou simplement l'envie de comparer. Cet article décrit ce que change le passage à une plateforme qui fait tourner votre app dans un conteneur, sans serveur à administrer, et comment s'y prendre pour un projet Next.js.

Deux modèles d'hébergement, pas deux niveaux de qualité

Un hébergeur serverless découpe votre application en fonctions qui démarrent à la demande, à la périphérie du réseau ou dans une région. Chaque requête peut tomber sur une instance différente, l'état ne persiste pas d'un appel à l'autre, et la facturation suit généralement ce qui est consommé.

Une plateforme à conteneurs fait tourner votre application comme un processus Node qui reste allumé. Le même serveur Next.js reçoit toutes les requêtes, garde ses caches en mémoire, peut ouvrir des connexions durables à une base de données et exécuter des tâches de fond. La facturation suit alors plutôt un plan avec des ressources réservées.

Aucun des deux n'est meilleur dans l'absolu. Le premier excelle pour du trafic très irrégulier et du contenu à distribuer partout dans le monde. Le second est plus simple à raisonner quand l'application parle à une base de données, tient des connexions ouvertes ou a besoin de prévisibilité, aussi bien techniquement que sur la facture.

Ce que Pierrr fait, concrètement

Pierrr est une plateforme d'hébergement applicatif. Vous connectez un dépôt GitHub ou GitLab, Pierrr détecte le framework, construit l'application et la met en ligne dans un conteneur avec un certificat HTTPS. Pour un projet Next.js, il n'y a pas de Dockerfile à écrire : le modèle Next.js de la plateforme s'en charge, avec ou sans output: 'standalone'. Si vous préférez garder la main, un Dockerfile à la racine du projet est utilisé tel quel.

Autour de l'application, la plateforme fournit ce qu'on monte d'habitude soi-même :

• un déploiement à chaque push sur la branche choisie, avec un journal de construction lisible ;
• une base Postgres par projet, isolée des autres, dont les variables de connexion sont injectées dans l'application ;
• des sauvegardes de la base, restaurables depuis le tableau de bord ;
• des domaines personnalisés avec certificat HTTPS géré pour vous ;
• des variables d'environnement et des secrets stockés chiffrés ;
• des alertes de santé, des journaux et des métriques de CPU et de mémoire ;
• des rôles par organisation pour les équipes.

Les offres vont du plan Free aux plans Starter, Pro et Business. Chaque nouvel espace dispose de 14 jours d'essai sur Starter ou Pro. Le plan Free convient pour tester ou héberger un petit projet, avec une contrepartie à connaître : un projet Free se met en veille la nuit et s'arrête après 30 jours sans activité, alors que les plans payants restent allumés en permanence.

Ce que vous retrouvez, ce que vous perdez

Soyons précis, parce qu'une migration réussie commence par une liste honnête des écarts.

Vous retrouvez le déploiement depuis Git, un site Next.js complet avec rendu côté serveur, les routes d'API, les variables d'environnement, les domaines personnalisés et le HTTPS.

Vous gagnez une base Postgres hébergée avec l'application, donc un service tiers de moins à brancher, des processus qui restent en vie, et un plan dont les ressources sont connues à l'avance.

Vous perdez, ou devez remplacer :

• les déploiements de prévisualisation par branche, qui n'existent pas sur Pierrr ;
• les cron jobs de Vercel, à remplacer par un autre mécanisme de planification ;
• les fonctions serverless et le runtime edge : votre application tourne comme un seul serveur, pas comme des fonctions réparties dans le monde ;
• les variables fournies par la plateforme d'origine, comme VERCEL_URL : si votre code s'en sert, il faut les remplacer par vos propres variables ;
• la distribution mondiale à la périphérie du réseau : si vos visiteurs sont partout et que la latence mondiale est critique, placez un CDN devant l'application.

Si l'une de ces lignes est un point bloquant pour votre projet, mieux vaut le savoir avant de commencer. Pour beaucoup d'applications, ce sont des fonctionnalités que l'on n'utilise pas.

Migrer un projet Next.js depuis Vercel

Pierrr propose un assistant de migration pour Vercel, ouvert à toutes les organisations, actuellement en bêta. L'ordre recommandé est pensé pour que Vercel continue de servir votre site jusqu'au dernier moment.

1. Connecter Vercel avec un token. Vous créez vous-même un token dans les réglages de votre compte Vercel, limité à l'équipe concernée et avec une expiration d'un jour. Pierrr s'en sert pour lire le projet, il est conservé chiffré 24 heures au plus et effacé à la fin de la migration.
2. Analyser le projet. L'assistant liste ce qui sera importé : le dépôt, le framework, les commandes de build, le nombre de variables de production, les domaines et la base Postgres détectée. Il affiche aussi les avertissements, par exemple ce qui n'a pas d'équivalent sur Pierrr. Un projet sans dépôt Git, un fournisseur de code non pris en charge ou un dépôt inaccessible depuis votre organisation bloquent l'import tant que la cause n'est pas corrigée.
3. Importer. Pierrr crée le projet, importe les variables de production et lance le premier déploiement. Les variables marquées sensibles chez Vercel ne sont jamais restituées : l'assistant vous demande de les ressaisir.
4. Vérifier sur l'adresse Pierrr. Avant de toucher au moindre domaine, ouvrez l'application sur son adresse fournie et passez-la en revue : pages, connexion, appels à la base, envoi d'e-mails.
5. Copier la base. Si vous utilisez la base Pierrr du projet, l'assistant y recopie le contenu de votre base Postgres actuelle, en une seule transaction : en cas d'interruption, la base du projet reste telle qu'elle était. La copie est un instantané. Pour une application qui écrit beaucoup, faites-la juste avant la bascule des domaines.
6. Basculer les domaines. Pierrr affiche l'enregistrement DNS à poser pour chaque adresse, vérifie toutes les 20 secondes et met l'adresse en ligne, certificat compris, dès que le DNS pointe vers Pierrr. Si votre domaine utilise les DNS de Vercel, une bascule automatique est proposée, avec un retour au DNS précédent possible pendant 24 heures. Cette bascule automatique est la partie la moins éprouvée du parcours : si votre domaine est critique, la bascule manuelle chez votre registrar reste le choix le plus prudent.
7. Terminer. Quand tout fonctionne, vous terminez la migration, ce qui efface le token. Votre projet Vercel reste en place : vous le supprimez quand vous le souhaitez.

Tout le déroulé est détaillé dans la documentation de migration depuis Vercel.

Un projet qui n'utilise pas Next.js ?

L'assistant reconnaît aussi les applications monopages (Vite, Create React App, Vue, Preact), les générateurs de sites statiques (Astro, Gatsby, Docusaurus, Eleventy, VitePress), les serveurs Node (Express, NestJS, Fastify, Hono, Koa), Nuxt, SvelteKit, Remix, Bun et FastAPI. Un framework absent de cette liste passe tant que le dépôt contient un Dockerfile.

Pour qui c'est un bon choix, pour qui ça ne l'est pas

Cette approche convient bien à une équipe qui veut une application et sa base de données au même endroit, avec une facture qui se prévoit, sans devenir administrateur système. Elle convient aussi à une app Next.js qui parle beaucoup à Postgres, garde des connexions ouvertes ou fait tourner des tâches de fond.

Elle convient moins si votre application dépend des fonctions edge, des previews par branche à chaque pull request, ou d'une distribution mondiale native. Dans ce cas, un hébergeur serverless reste le bon outil, et il n'y a aucune honte à le garder.

Le plus simple : essayer sur un projet de test

La meilleure façon de trancher n'est pas de lire un comparatif, c'est de migrer un projet secondaire. Créez un espace, lancez l'assistant sur une application de test et regardez ce que ça donne : la migration n'écrit rien chez Vercel (sauf si vous demandez vous-même la bascule automatique du DNS), et votre projet d'origine continue de tourner pendant toute l'opération.

Pour démarrer, la prise en main vous mène de l'inscription à une première application en ligne, et la page des tarifs détaille les plans et leurs limites.