Comment héberger un site Astro : options statiques et SSR

Astro peut livrer votre site de deux façons très différentes, et celle que vous choisissez décide où et comment vous l'hébergez. Par défaut, Astro construit un dossier de simples fichiers HTML, CSS et JS — des fichiers que n'importe quel hébergeur statique peut servir. Mais Astro peut aussi tourner sur un serveur, rendant les pages à la demande (SSR) pour des choses comme l'authentification, les formulaires ou les données par requête. Ce guide explique les deux modes de sortie, les commandes de build qui les sous-tendent, comment les adaptateurs s'y intègrent, et comment choisir un hébergeur pour chacun.

Statique vs serveur : la décision centrale

Tout choix d'hébergement pour Astro découle d'une question : votre site a-t-il besoin d'un serveur en fonctionnement au moment de la requête ?

• Statique (le défaut). Les pages sont rendues une fois, au moment du build, en fichiers HTML. Il n'y a pas de processus serveur — vous téléversez le dossier construit sur un CDN ou un hébergeur statique et il sert les fichiers. Le plus rapide, le moins cher, le plus simple. Idéal pour les blogs, la documentation, les sites vitrines et la plupart des sites de contenu.
• Serveur / SSR. Les pages sont rendues à chaque requête par un processus Node (ou edge). Nécessaire quand le contenu dépend de la requête : utilisateurs connectés, traitement de formulaires, personnalisation à la volée, ou données qui doivent être fraîches à chaque chargement.

Vous pouvez aussi mélanger les deux : garder le site majoritairement statique et faire basculer certaines routes spécifiques en rendu à la demande. L'idée est de rendre statiquement partout où vous le pouvez, et de ne payer un serveur que là où vous en avez réellement besoin.

Les commandes de build

Quel que soit le mode, le flux de travail tient aux deux mêmes commandes — installer, puis construire :

# install dependencies
npm install

# produce the production build
npm run build

# preview the production build locally before deploying
npm run preview

Par défaut, npm run build écrit un site statique dans le dossier dist/. Ce dossier est l'intégralité de votre site déployable en mode statique — il n'y a rien d'autre à exécuter.

Configurer le mode de sortie

Vous contrôlez le mode dans astro.config.mjs. Le statique est le défaut, donc une configuration minimale n'a besoin de rien de particulier. Pour rendre côté serveur, vous ajoutez un adaptateur — un petit paquet qui apprend à Astro comment tourner sur une plateforme spécifique (Node, ou un runtime edge/serverless) :

// astro.config.mjs — server (SSR) output with the Node adapter
import { defineConfig } from 'astro/config';
import node from '@astrojs/node';

export default defineConfig({
  output: 'server',
  adapter: node({ mode: 'standalone' }),
});

Avec l'adaptateur Node standalone, npm run build produit un point d'entrée serveur que vous démarrez comme n'importe quelle application Node :

# after building with the Node adapter
node ./dist/server/entry.mjs

Si vous n'avez besoin que d'une poignée de routes dynamiques, gardez la sortie statique par défaut et sortez certaines pages individuelles du prérendu au lieu de basculer tout le site en mode serveur :

---
// src/pages/dashboard.astro — render this page per request
export const prerender = false;
---

Choisir un hébergeur selon le mode

Hébergement statique

Pour la sortie statique, il vous faut simplement un endroit pour servir le contenu de dist/ en HTTPS, idéalement depuis un CDN. Les réglages de build/publication sont simples :

Build command:    npm run build
Publish/output:   dist

De nombreuses plateformes le font — hébergeurs statiques managés, stockage objet derrière un CDN, ou un hébergeur polyvalent capable de servir un dossier. Comme il n'y a pas de serveur à maintenir en vie, l'hébergement statique est bon marché et sans effort à mettre à l'échelle. Héberger sur une infrastructure européenne est un bon choix ici lorsque votre audience ou vos besoins de résidence des données pointent dans cette direction.

Hébergement serveur (SSR)

Le SSR a besoin d'un runtime qui maintient un processus en vie. Deux grandes voies :

• Un hébergeur Node / VPS. Avec l'adaptateur Node, vous construisez un serveur standalone et le faites tourner comme n'importe quel service Node. Un VPS vous donne le contrôle total sur le processus, l'environnement et la mise à l'échelle — pratique si vous y faites déjà tourner d'autres services.
• Serverless / edge. Des adaptateurs spécifiques à chaque plateforme empaquettent votre application pour la faire tourner sous forme de fonctions. Moins à gérer, mais vous êtes lié au modèle de cette plateforme.

Une façon simple de faire tourner le build Node sur votre propre serveur est un gestionnaire de processus pour qu'il redémarre en cas de crash ou de redémarrage :

# example: keep the Astro Node server running with PM2
npm install -g pm2
pm2 start ./dist/server/entry.mjs --name astro-site
pm2 save

Référence rapide

Besoin	Mode	Quoi héberger
Blog, documentation, vitrine, contenu	Statique (défaut)	Le dossier dist/ sur un CDN/hébergeur statique
Majoritairement statique, quelques routes dynamiques	Statique + prerender = false par page	Un hébergeur/adaptateur prenant en charge les routes à la demande
Auth, formulaires, données par requête partout	Serveur (SSR)	Un runtime Node / VPS ou une plateforme serverless

Comment décider

Commencez en statique — c'est le défaut pour une raison : moins cher, plus rapide et plus simple à héberger. Ne recourez à l'adaptateur serveur que lorsqu'un vrai besoin (état connecté, traitement de formulaires, données toujours fraîches) impose un rendu par requête, et même là, envisagez de ne sortir que ces routes du prérendu plutôt que de faire tourner tout le site sur un serveur. Adaptez l'hébergeur au mode que vous obtenez au final : un hébergeur statique adossé à un CDN pour les fichiers construits, ou un VPS / plateforme serverless capable de Node lorsque vous avez réellement besoin d'un serveur.