Déployez Static sites and SPAs sur Nodion

Déployez Static sites and SPAs étape par étape

1. Commitez un lockfile et un script de build Commitez votre lockfile ; sans lui, le build échoue. Nodion exécute le script build et prend le dossier de sortie de votre framework : dist/ pour Vite, build/ pour Create React App, dist/<project>/browser pour Angular, public/ pour Gatsby et _site/ pour Eleventy. package.json

   "scripts": {
     "dev": "vite",
     "build": "vite build"
   }

2. Définissez les variables de build Votre bundler écrit les variables comme VITE_*, REACT_APP_* ou GATSBY_* dans les fichiers pendant le build : elles ont donc besoin de l'option Build dans l'onglet Environment. Tout leur contenu est public, n'y mettez donc jamais de secrets.
3. Indiquez les autres dossiers de sortie dans static.toml D'autres générateurs fonctionnent aussi : Nodion cherche un index.html dans dist, build, out, .output/public, public et _site. Si le vôtre écrit ailleurs, comme VitePress, ajoutez un static.toml à côté de package.json. Ce fichier amène aussi Nodion à traiter le dépôt comme un site statique là où il n'en détecterait pas. fallback indique le fichier servi pour les chemins qui n'existent pas. static.toml

   output-dir = "docs/.vitepress/dist"
   fallback = "index.html"

4. Le HTML pur n'a pas besoin de build Un dépôt avec un index.html à la racine et sans package.json est servi tel quel. Nodion exclut .git, les fichiers .env et certains fichiers de clés courants, mais considérez tout ce que vous commitez comme public et gardez les secrets hors du dépôt.
5. Créez l'app et poussez Dans le dashboard, créez une application depuis votre dépôt GitHub, GitLab, Bitbucket ou Gitea dans la région EU Central et choisissez la plus petite taille. Chaque push construit une nouvelle release, et le trafic bascule vers elle dès que / répond, ce dont se charge votre index.html.

Bon à savoir

• Le routage côté client fonctionneLes chemins qui ne correspondent à aucun fichier reçoivent votre index.html : les routes de React Router, Vue Router et Angular restent accessibles après un rechargement de la page. Le fallback ne peut pas être désactivé ; fallback dans static.toml change seulement le fichier.
• Pas de processus Procfile, pas de code serveurLes processus du Procfile n'ont aucun effet sur un site statique, et seul le dossier de sortie est publié. Une ligne release: s'exécuterait quand même, mais dans une image qui ne contient que les fichiers générés : laissez-la de côté. Si votre dépôt est un serveur Node.js avec un script de build, lisez le guide Node.js pour savoir comment Nodion distingue les deux cas.
• Angular SSRNodion construit les projets Angular comme des sites statiques, même avec @angular/ssr : le rendu côté serveur ne s'exécute donc pas. Pour le SSR, utilisez un Dockerfile.
• Hugo et JekyllNodion n'exécute pas les builds Hugo ou Jekyll. Construisez le site vous-même, commitez le dossier généré (public/ ou _site/) et indiquez-le comme Base directory de l'app : un dossier avec un index.html et sans package.json est servi tel quel. Ou construisez le site dans un Dockerfile.

Ce que Nodion gère pour vous

• Déploiements sans interruption Faites un push sur votre branche : Nodion construit une nouvelle release. Le trafic bascule lorsque les nouvelles instances réussissent leur health check ; si la release échoue, celle en cours reste active. Les apps avec un volume local redémarrent, car le disque appartient à une seule instance.
• Bases de données à côté de l'app PostgreSQL, pgvector, MySQL, Valkey et ClickHouse managés, dans la même région. Les bases de données rattachées arrivent sous forme de DATABASE_URL, REDIS_URL ou CLICKHOUSE_URL.
• Previews par pull request Activez les previews, et les pull requests de votre dépôt obtiennent leur propre app, avec sa propre URL et des bases de données neuves et vides, créées automatiquement ou à la main. Les pull requests issues de forks ou de bots sont ignorées.
• Workers, cron jobs et mise à l'échelle Exécutez les workers comme processus supplémentaires de la même app, planifiez des tâches dans l'onglet Cron et mettez chaque processus à l'échelle jusqu'à 16 instances.
• Étape de release Avec les buildpacks, une ligne release: du Procfile s'exécute à chaque nouveau build. Les apps Dockerfile, ainsi que les redéploiements ou les rollbacks vers une image antérieure, utilisent une commande de release définie sur l'app elle-même, qui prime aussi sur la ligne du Procfile. Sur les sites statiques, l'étape de release s'exécute dans une image qui ne contient que les fichiers générés par le build.
• Logs et métriques Logs de build, de release et d'exécution, ainsi que les métriques CPU, mémoire, disque et réseau de chaque instance, dans le dashboard.
• Domaines et HTTPS Un nom d'hôte par défaut avec HTTPS dès le premier déploiement, et des certificats automatiques pour vos propres domaines.

Pour aller plus loin

• Environnements de preview : une app par pull request Une copie de votre app en fonctionnement pour chaque pull request : à quoi servent les environnements de preview, où ils se compliquent et comment Nodion les gère.
• Les Cloud Native Buildpacks expliqués Les buildpacks transforment votre code source en image de conteneur sans Dockerfile. Ce qu'ils sont et comment ils fonctionnent.

Static sites and SPAs sur Nodion : questions et réponses