Une fois votre site Astro construit, le déploiement est l’étape critique : il doit être rapide, automatisé via Git, sécurisé en HTTPS, et idéalement servi depuis un edge proche de vos visiteurs africains. Deux options dominent en 2026 (informations vérifiées en avril 2026, susceptibles d’évoluer) : Cloudflare Pages (managé, edge mondial, gratuit jusqu’à un seuil élevé) et Coolify (auto-hébergé sur VPS Hetzner). Voici comment configurer chacune.

Voir notre guide pratique Astro 5 et le guide Coolify.

Option A — Cloudflare Pages

Cloudflare Pages est l’option recommandée pour la majorité des sites Astro statiques visant l’Afrique. Avantages :

Gratuit : 500 builds/mois, 100k requêtes/jour, bandwidth illimitée
Edge mondial : datacenters Lagos, Casablanca, Le Caire pour latence Afrique < 50 ms
HTTPS automatique
Preview déploiements à chaque PR
Cache CDN intelligent + Workers à la demande

Étape 1 — Pousser sur GitHub

git init
git add .
git commit -m "init"
git remote add origin git@github.com:username/mon-site.git
git push -u origin main

Étape 2 — Connecter Cloudflare Pages

Cloudflare dashboard → Workers & Pages → Create → Pages → Connect to Git
Autoriser GitHub, choisir le repo
Build settings : framework preset « Astro », build command npm run build, output dir dist
Environment variables si besoin (NODE_VERSION=20, etc.)
Save and Deploy

Premier build en 1-3 minutes. URL your-project.pages.dev. Connectez votre domaine custom dans Custom domains.

Étape 3 — SSR/Server Islands

bun add @astrojs/cloudflare

// astro.config.mjs
import cloudflare from "@astrojs/cloudflare";
export default defineConfig({
  output: "server",
  adapter: cloudflare(),
});

Option B — Coolify sur Hetzner

Cloudflare Pages couvre 95 % des cas. Si vous voulez la souveraineté complète, du SSR custom, ou de la perf cumulée avec d’autres apps, Coolify sur Hetzner est l’option auto-hébergée. Voir notre guide Coolify.

Setup Coolify

Coolify → New Resource → Application → Public/Private Repository
Build pack : Nixpacks (auto-détecte Astro)
Build command : npm run build
Start command : node dist/server/entry.mjs (si SSR) ou serveur statique
Port : 4321 ou 8080 selon adapter
Domaine, HTTPS, déployer

Caddy pour servir le statique

Pour un site purement statique sur VPS, vous pouvez aussi le servir via Caddy directement, sans framework runtime :

# /etc/caddy/Caddyfile
exemple.sn {
  root * /var/www/mon-site/dist
  file_server
  encode gzip zstd
  
  # Cache assets longue durée
  @assets path *.js *.css *.woff2 *.png *.jpg *.svg
  header @assets Cache-Control "public, max-age=31536000, immutable"
}

Cloudflare devant Coolify

Combinaison gagnante pour l’Afrique : Coolify sur Hetzner Helsinki + Cloudflare Free devant. Vos visiteurs africains accèdent au cache edge Cloudflare proche, le serveur Hetzner reçoit moins de requêtes, et vous gardez le contrôle complet.

Domain → Cloudflare DNS
Activer « Proxied » (orange)
SSL/TLS mode : « Full (strict) » — Coolify a déjà un cert valide
Cache Rules : agressif sur les assets, normal sur les HTML

Comparaison rapide

Critère	Cloudflare Pages	Coolify Hetzner
Coût	Gratuit (jusqu’à seuil)	~5 €/mois fixe
Setup	5 min	30 min (Coolify déjà installé)
Latence Afrique	Excellente (edge Lagos)	Bonne avec Cloudflare devant
Souveraineté	Données chez Cloudflare	Totale
SSR/Server Islands	Workers (limites runtime)	Node/Bun complet
Custom backend	Workers	N’importe quel service

Recommandation

Site statique simple ou blog → Cloudflare Pages, point. Site avec backend custom, SaaS, e-commerce → Coolify + Cloudflare devant.

Erreurs fréquentes

Erreur	Cause	Solution
Build CF Pages timeout	Build > 20 min	Réduire pages générées, optimiser dépendances
SSR ne fonctionne pas	Pas d’adapter	Installer @astrojs/cloudflare ou node
Images cassées en prod	Path absolu vs relatif	Toujours import via src/assets/
Cache HTML trop long	Cloudflare cache HTML par défaut	Page Rules : Cache Level Bypass sur /*.html

Lectures complémentaires

Étape A — Choisir entre edge et VPS selon votre trafic

Avant d’écrire la moindre ligne de configuration, projetez votre trafic réel sur 12 mois. Une vitrine SaaS qui sert 10 000 visites par mois depuis Dakar, Abidjan et Lomé n’a pas du tout les mêmes besoins qu’un blog technique qui pousse 200 articles à 50 000 visites mensuelles. Cloudflare Pages exécute votre rendu Astro depuis 330+ POP edge, donc une page statique servie depuis Lagos prendra 25 à 40 ms en TTFB local. Coolify sur Hetzner Falkenstein servira la même page en 180 à 240 ms vers Dakar (sans CDN devant), à cause du trajet Europe — Afrique.

Règle pratique : si votre audience est >70 % ouest-africaine et que vos pages sont essentiellement statiques (Astro pur, MDX, blog), Cloudflare Pages gagne sans débat. Si vous avez besoin de Server Islands lourds, de WebSockets persistants, de cron jobs, d’un backend Node attaché ou d’un CMS headless self-hosté à côté, Coolify devient pertinent — la latence est compensée par la souveraineté.

Étape B — Préparer le projet Astro pour les deux cibles

Avant de pousser quoi que ce soit, vérifiez que votre astro.config.mjs est neutre vis-à-vis de l’adapter. Astro 5 vous laisse changer d’adapter sans réécrire vos pages, à condition d’avoir respecté la séparation pages statiques / pages serveur via export const prerender = true|false.

// astro.config.mjs
import { defineConfig } from 'astro/config';
const adapter = process.env.ADAPTER === 'cloudflare'
  ? (await import('@astrojs/cloudflare')).default()
  : (await import('@astrojs/node')).default({ mode: 'standalone' });

export default defineConfig({
  site: 'https://votre-domaine.io',
  output: 'hybrid',
  adapter,
});

Cette astuce vous permet de tester en local avec ADAPTER=node npm run build puis ADAPTER=cloudflare npm run build pour vérifier que rien ne casse. Une page qui appelle fs.readFileSync ou process.env.SECRET au runtime cassera sur Cloudflare Workers (pas de FS, env via context.locals.runtime.env) — autant le détecter avant de pousser.

Étape C — Variables d’environnement et secrets sans fuite

Sur Cloudflare Pages, allez dans Settings → Environment variables → Production. Ajoutez vos clés (STRIPE_SECRET_KEY, RESEND_API_KEY, etc.) en cochant Encrypt pour qu’elles n’apparaissent pas en clair dans l’UI. Côté code Astro, accédez-y via Astro.locals.runtime.env.STRIPE_SECRET_KEY — pas via import.meta.env qui ne contient que les variables au moment du build.

Sur Coolify, l’écran Environment Variables du service expose les mêmes valeurs au runtime Node via process.env. Pour les secrets sensibles (clés Wave, Mixx by Yas, Orange Money), cochez Build Variable et Is Build Time? selon que vous en avez besoin pendant npm run build ou seulement au runtime. Ne committez jamais ces valeurs dans .env.local versionné.

Étape D — Domaine, DNS et SSL pour les deux options

Pour Cloudflare Pages, le domaine doit être géré sur Cloudflare DNS. Allez dans le projet Pages → Custom domains → Set up a custom domain. Ajoutez www.votre-domaine.io, Cloudflare crée automatiquement un CNAME flatten vers votre-projet.pages.dev. Le certificat SSL Universal arrive en 60 à 120 secondes. Activez Always Use HTTPS dans SSL/TLS → Edge Certificates pour forcer la redirection.

Pour Coolify, créez d’abord un A record app.votre-domaine.io qui pointe vers l’IP publique de votre VPS Hetzner. Dans Coolify, ouvrez le service Astro → Domains → ajoutez https://app.votre-domaine.io. Coolify déclenche automatiquement Caddy pour générer un certificat Let’s Encrypt — vérifiez les logs Caddy via Coolify → Logs si le certificat n’arrive pas après 90 secondes (souvent un AAAA record IPv6 manquant ou un firewall qui bloque le port 80).

Étape E — Déployer en parallèle pour comparer

Pour décider sereinement, déployez réellement la même version sur les deux plateformes pendant 7 à 14 jours, puis mesurez. Sur Cloudflare Pages, branche main connectée. Sur Coolify, branche main aussi mais avec un sous-domaine distinct coolify.votre-domaine.io. Lancez un test synthétique depuis Dakar via WebPageTest (location Dakar disponible) ou via un VPS de test à Abidjan.

Les chiffres à noter : TTFB (target <200 ms), LCP (target <2,5 s), Speed Index (target <3,4 s), bytes transférés. Sortie attendue : Cloudflare bat Coolify sur TTFB de 60 à 120 ms en moyenne pour des pages statiques, mais Coolify peut rattraper sur des pages SSR Node lourdes si Cloudflare Workers cold-start sur une route peu visitée.

Étape F — CI/CD GitHub Actions commun aux deux cibles

Mutualisez votre pipeline pour ne pas dupliquer les builds. Voici un workflow GitHub qui build une fois et déploie aux deux plateformes :

name: Deploy Astro
on: { push: { branches: [main] } }
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 22 }
      - run: npm ci && npm run build
      - uses: cloudflare/pages-action@v1
        with:
          apiToken: ${{ secrets.CF_API_TOKEN }}
          accountId: ${{ secrets.CF_ACCOUNT_ID }}
          projectName: votre-projet
          directory: dist
      - name: Trigger Coolify webhook
        run: curl -X POST "${{ secrets.COOLIFY_WEBHOOK_URL }}"

Le webhook Coolify se trouve dans Service → Webhooks → Generate URL. Sortie attendue : un push sur main déclenche un build, puis pousse sur Cloudflare Pages et notifie Coolify de redéployer. Vous restez maître des deux environnements en parallèle.

Étape G — Mesurer le coût réel pour le marché ouest-africain

Cloudflare Pages : plan Free couvre 500 builds/mois et bande passante illimitée. Plan Pro à 20 USD/mois (≈ 13 120 FCFA) débloque 5000 builds et accès aux Web Analytics. Pour un blog technique qui publie 30 articles par mois, le Free suffit largement la première année.

Coolify sur Hetzner CX22 (2 vCPU, 4 Go RAM, 40 Go SSD, Falkenstein) : 4,90 EUR/mois soit environ 3 215 FCFA. Vous y faites tourner Astro + un PostgreSQL + un Plausible + un Umami pour le même prix. La rentabilité bascule dès que vous self-hostez 3+ services. Comparez aussi avec un VPS Contabo à Singapour (3,99 EUR/mois) si vous visez l’Asie en plus de l’Afrique.

Étape H — Plan de rollback en cas d’incident production

Sur Cloudflare Pages : Deployments → cliquez sur le dernier build sain → Rollback to this deployment. La bascule prend 15 secondes, pas besoin de rebuild. Sur Coolify : ouvrez le service → Deployments tab → cliquez sur le commit précédent → Redeploy. Comptez 60 à 180 secondes selon la taille du projet.

Préparez un runbook court (3 lignes) à coller dans le README : URL du dashboard Cloudflare, URL du dashboard Coolify, commande d’urgence pour basculer DNS de www vers le domaine Pages secondaire si Coolify tombe. Cette redondance vous coûte 0 FCFA de plus et vous épargne une nuit blanche. Voir aussi notre tutoriel sur déployer Plausible sur Hetzner avec Coolify et le guide CrowdSec pour protéger vos applications self-hosted.

Étape I — Observabilité et alerting sur les deux plateformes

Une fois en production, vous voulez savoir quand quelque chose casse avant que vos utilisateurs vous le disent sur WhatsApp. Sur Cloudflare Pages, activez Web Analytics (gratuit avec le plan Free) — vous obtenez les Core Web Vitals réels mesurés depuis les navigateurs des visiteurs, pas depuis Lighthouse. Ajoutez un Worker Cron qui ping votre URL toutes les 5 minutes et envoie une alerte sur WhatsApp Business via l’API Wave Notifier ou via une intégration Telegram bot si vous préférez. Le coût est nul jusqu’à 100 000 invocations par jour.

Sur Coolify, activez l’intégration Healthcheck du service : Settings → Healthcheck → URL /api/health → Interval 30s → Timeout 5s → Retries 3. Couplez avec un Uptime Kuma (One Click Coolify, ressources minimes) qui surveille en externe et envoie des notifications Telegram, Discord, ou email lorsqu’une route ne répond plus. Configurez aussi une alerte mémoire sur Hetzner Cloud Console (Alarms → CPU usage > 85 % pendant 10 min) pour anticiper les saturations avant que le swap ne ralentisse tout.

Étape J — Monitoring des Core Web Vitals depuis l’Afrique de l’Ouest

Lighthouse exécuté depuis votre laptop à Dakar ne reflète pas l’expérience d’un visiteur à Bamako sur un Tecno 4G. Utilisez plutôt CrUX Dashboard (Chrome User Experience Report) qui agrège les Web Vitals réels de millions de visiteurs Chrome dans le monde, segmentés par pays. Filtrez par Senegal, Côte d’Ivoire, Mali, Togo, Bénin et regardez le 75e percentile de LCP — c’est la métrique que Google utilise pour son ranking. Un LCP au-dessus de 2,5 s sur mobile vous coûte des positions SERP.

Plan d’optimisation classique : compressez vos images en AVIF (gain 40 % vs WebP), préchargez les fonts critiques avec <link rel="preload" as="font">, mettez en cache agressive (1 an avec hash dans le nom de fichier) sur les assets statiques. Astro génère déjà des hashs par défaut, profitez-en. Sur Cloudflare, activez Auto Minify et Rocket Loader si vos scripts tiers le supportent. Sur Coolify, ajoutez Caddy compression Gzip + Brotli dans le Caddyfile global.

FAQ courte

Astro est-il compatible avec Cloudflare R2 pour stocker des assets ? Oui. Configurez un binding R2 dans wrangler.toml, accédez via Astro.locals.runtime.env.MY_BUCKET.get('key'). Coût stockage 0,015 USD/Go/mois, sortie 0 USD jusqu’à 1 To/mois. Excellent pour héberger des PDFs catalogues sans payer la bande passante.

Combien de temps dure le cold start sur Cloudflare Workers pour un Astro SSR ? Entre 5 et 50 ms en V8 isolate, contre 800 ms à 2 s sur AWS Lambda. La différence est invisible pour l’utilisateur final.

Coolify supporte-t-il les déploiements bleu-vert ? Pas nativement en mai 2026 sur la version stable, mais vous pouvez le simuler en créant deux services (blue/green) et en basculant le domaine custom de l’un à l’autre via l’UI. Pour du vrai blue-green automatisé, restez sur Cloudflare Pages.