Déployer une application Next.js sans compte Vercel

Next.js est conçu pour tourner sur Vercel, ce qui est un bon défaut jusqu’à ce que la facture commence à suivre les invocations de fonctions et les requêtes edge plutôt qu’un chiffre fixe et prévisible. Le framework lui-même ne l’exige pas — un next build suivi d’un next start est juste un processus Node, ce qui veut dire qu’il tourne de la même façon partout où un processus Node peut tourner, y compris sur un serveur que vous possédez.

Ce qui se passe réellement lors d’un push

Il n’y a aucune configuration spécifique à Next.js à écrire. Railyard lit package.json, détecte le script build, et pour une dépendance Next.js en particulier exécute next build avant de démarrer l’application avec next start — la même détection qui gère aussi Nuxt et SvelteKit, puisque le motif (le framework déclare une étape de build, le framework fournit sa propre commande de démarrage) est partagé entre les trois. Le gestionnaire de paquets — npm, pnpm, yarn ou bun — est détecté à partir du fichier de verrouillage déjà présent dans le dépôt, pas devinée.

railyard create my-app https://github.com/me/my-app

ou collez la même URL Git dans le tableau de bord une fois GitHub connecté. Dans les deux cas, chaque push suivant le premier reconstruit et redéploie automatiquement — le même flux git push que Vercel a popularisé, mais tournant sur une infrastructure qui n’est pas mesurée par requête.

La seule décision qui mérite d’être prise délibérément : statique ou serveur

Une application Next.js qui utilise output: "export" (ou qui ne touche jamais une fonctionnalité serveur — pas de routes API, pas d’actions serveur, pas d’ISR) produit une sortie purement statique. C’est une chose significativement différente, et moins coûteuse, à faire tourner, et Railyard la traite comme telle : une sortie statique est servie sans aucun processus Node derrière elle, tandis que tout ce qui utilise le rendu côté serveur, les routes API ou les actions serveur garde le processus next start complet en vie. Savoir quel genre d’application est réellement livré — avant de s’inquiéter du coût d’hébergement — est la question utile à poser d’abord, pas une réflexion après coup.

Les variables d’environnement fonctionnent comme en local

process.env.PEUIMPORTE lit ce qui est défini sous Variables, ou via railyard env:set my-app KEY=VALUE depuis la CLI — le même artefact de build tourne sans changement d’une branche de prévisualisation jusqu’à la production, donc un déploiement de staging ne fait jamais tourner un bundle différent de ce qui est livré. Un addon de base de données se résout en ${{postgres.RAILYARD_PRIVATE_URL}}, scopé par environnement automatiquement.

Le travail en arrière-plan n’a pas besoin d’une deuxième application

Si l’application a besoin d’un worker de file d’attente à côté du processus web — courriels, webhooks, tout ce qui ne devrait pas bloquer une requête — c’est un deuxième script dans le même package.json, pas un deuxième dépôt ou un deuxième déploiement : npm run worker est détecté comme son propre type de processus évolutif à côté de web, partageant un seul build.

Voir la référence complète de Node.js : Documentation Node.js, Déployer depuis un dépôt.