Pourquoi self-héberger Astro sur un VPS
Astro a une particularité : il peut produire soit un site 100 % statique (output: 'static'), soit une application avec rendu serveur à la demande (output: 'server' via @astrojs/node). Cette dualité rend le VPS très pertinent. En statique, vous servez directement des fichiers HTML depuis Nginx, sans aucun processus Node : performances maximales et empreinte minimale. En SSR, vous lancez un serveur Node qui rend les pages dynamiquement, utile pour des contenus personnalisés ou des endpoints API intégrés. Sur un VPS, vous choisissez votre stratégie sans être enfermé dans le modèle imposé par une plateforme de déploiement front. Vous contrôlez aussi le cache HTTP, les en-têtes de sécurité et la compression Brotli, là où les hébergements front gèrent ça en boîte noire.
Bénéfices concrets
- Liberté du mode de sortie : statique pur ou SSR Node, voire hybride par route
- En statique, Nginx sert les fichiers sans aucun processus Node : RAM quasi nulle, débit maximal
- Maîtrise totale du cache HTTP, des en-têtes de sécurité (CSP, HSTS) et de la compression Brotli
- Pas de limite de bande passante ni de quota de requêtes imposé par une plateforme front
- Endpoints API d'Astro hébergés sur le même domaine, sans fonction serverless tierce
- Déploiement reproductible via Docker : le même build local et en production
Prérequis matériels et logiciels
Un site Astro statique tient sur le plus petit VPS imaginable : 1 vCPU et 1 Go de RAM suffisent largement, car Nginx ne fait que servir des fichiers. En mode SSR, prévoyez 2 Go pour le processus Node et les pics de rendu. Installez Node.js 20 LTS pour builder (ou buildez en CI), Docker si vous conteneurisez, et Nginx comme frontal. Pointez mondomaine.ma et www.mondomaine.ma vers l'IP du VPS. Comptez 5 Go de disque ; le dossier dist/ d'un site statique pèse généralement quelques Mo.
Déploiement pas à pas
Choisir le mode de sortie
Dans astro.config.mjs, définissez output: 'static' pour un site de contenu, ou output: 'server' avec adapter: node({ mode: 'standalone' }) si vous avez besoin de SSR. Ce choix conditionne toute la suite du déploiement.
Builder l'application
Lancez npm run build. En statique, vous obtenez un dossier dist/ contenant le HTML, le CSS et le JS prêts à servir. En SSR, vous obtenez en plus un dist/server/entry.mjs à exécuter avec Node.
Servir le statique avec Nginx (mode statique)
Pointez la directive root de votre vhost vers /var/www/astro/dist et activez try_files $uri $uri/ /404.html;. Ajoutez gzip on; et des en-têtes Cache-Control longs sur les assets versionnés. Aucun conteneur n'est nécessaire.
Conteneuriser le serveur Node (mode SSR)
Pour le SSR, créez un Dockerfile basé sur node:20-alpine qui copie dist/ et lance node ./dist/server/entry.mjs. Exposez le port 4321 et démarrez avec docker compose up -d. Nginx fera ensuite un proxy_pass vers ce port.
Configurer le reverse proxy et la compression
Que vous soyez en statique ou en SSR derrière Node, déclarez le vhost Nginx avec www redirigé vers le domaine apex. Activez Brotli si le module est disponible pour des assets encore plus légers que gzip.
Activer le SSL
Exécutez certbot --nginx -d mondomaine.ma -d www.mondomaine.ma. Forcez la redirection vers HTTPS et ajoutez l'en-tête Strict-Transport-Security. Validez le déploiement avec un test Lighthouse depuis votre navigateur.
Même pour un site SSR, exploitez le rendu hybride d'Astro : marquez les pages statiques avec export const prerender = true pour qu'elles soient générées au build et servies directement par Nginx, en ne réservant le processus Node qu'aux routes réellement dynamiques. Vous réduisez ainsi drastiquement la charge serveur. Et placez un cache proxy_cache Nginx devant les pages SSR à faible fréquence de changement pour absorber les pics de trafic.
