Strapi Headless CMS auto-hébergé sur AWS : notre stack sans compromis
Un client formule la demande la plus légitime qui soit : pouvoir modifier son site lui-même, sans appeler un développeur à chaque retouche de texte. Simple en apparence. Structurant dans les choix techniques qui suivent.
On aurait pu aller vite avec un CMS tout-en-un. On a choisi d'aller juste.
Le problème avec les CMS SaaS "clé en main"
Les plateformes comme Contentful, Sanity ou Prismic résolvent le problème à court terme. Mais elles introduisent une dépendance structurelle : hébergement imposé, tarification à l'usage qui s'envole dès que le projet prend de l'ampleur, peu de flexibilité sur la modélisation du contenu.
Pour un client qui veut une solution durable — pas un abonnement de plus à gérer — ce n'est pas la bonne réponse.
Notre choix : Strapi headless, auto-hébergé sur AWS
Strapi est un CMS headless open source. Il expose le contenu via une API REST ou GraphQL, que le front consomme indépendamment. Le client a un backoffice pour gérer ses textes, images, articles — sans jamais ouvrir un fichier de code.
On l'héberge nous-mêmes, sur notre infrastructure AWS. Voici comment.
L'architecture en détail
La couche applicative : Docker Compose sur EC2
Tout le cœur applicatif tourne dans une EC2 au sein d'un VPC Amazon, orchestré par Docker Compose :
- Strapi — le CMS headless, avec son backoffice et son API de contenu
- PostgreSQL — la base de données, containerisée au même niveau
- API Lister — notre API custom, également containerisée
Les trois services communiquent entre eux en réseau Docker interne. Aucun port base de données n'est exposé à l'extérieur.
# docker-compose.yml (structure simplifiée)
services:
strapi:
image: strapi/strapi
depends_on:
- postgres
environment:
DATABASE_CLIENT: postgres
DATABASE_HOST: postgres
postgres:
image: postgres:15
volumes:
- pgdata:/var/lib/postgresql/data
api-lister:
build: ./api-lister
depends_on:
- strapi
Le reverse proxy : Nginx + SSL automatique
Devant l'EC2, une instance EC2 dédiée au reverse proxy fait tourner Nginx. Elle gère :
- La redirection HTTP → HTTPS
- Le routage vers les services internes
- La page d'attente (
WaitingPage.js) affichée si l'EC2 principale est en cours de démarrage
Le certificat SSL est fourni par Let's Encrypt via Certbot, avec renouvellement automatique tous les 90 jours. Le certificat est stocké dans un bucket S3 dédié pour la persistance entre redéploiements.
# Renouvellement automatique (cron ou systemd timer)
certbot renew --quiet --deploy-hook "nginx -s reload"
Le démarrage à la demande : API Gateway + Lambda
Pour éviter de laisser l'EC2 tourner 24h/24 inutilement, les requêtes entrantes passent par :
- Amazon API Gateway — reçoit la requête
- AWS Lambda — évalue si l'EC2 est active, la démarre si besoin (
StartInstances) - L'EC2 prend le relais une fois disponible
Ce pattern réduit les coûts d'infrastructure de manière significative pour des projets à trafic intermittent.
Les médias et le cache : externalisés sur S3
Les assets ne sont jamais servis directement depuis l'EC2 :
- S3 Media librairie — stocke les images et fichiers uploadés via Strapi
- S3 Cache — stocke les réponses API mises en cache par l'application
Les deux buckets sont servis via AWS Amplify, qui joue le rôle de CDN léger. L'EC2 pousse (Push Media, Push Cache), Amplify tire (get media, get cache).
Sécurité et observabilité
- AWS IAM Everywhere — chaque service n'a accès qu'aux ressources dont il a besoin (principe du moindre privilège)
- CloudWatch GetLogs — les logs de tous les containers remontent vers CloudWatch pour monitoring et alerting
Ce que ça change concrètement pour le client
| Avant | Après |
|---|---|
| Modification de contenu → ticket dev | Backoffice Strapi en autonomie |
| Abonnement SaaS à l'usage | Coût fixe, prévisible |
| Données chez un tiers US | Infra AWS eu-west, données souveraines |
| Dépendance à une plateforme | Stack 100% open source |
Ce qu'il faut retenir
Cette architecture ne convient pas à tous les projets. Pour un site vitrine simple, un CMS SaaS reste pertinent. Mais dès que le client a des besoins métier spécifiques, des volumes de contenu significatifs, ou une contrainte de souveraineté des données — l'auto-hébergement sur AWS avec Strapi devient la solution la plus robuste et la plus économique à moyen terme.
Le client reprend la main sur son contenu. KODY garde la main sur l'architecture. C'est ça, réduire les frictions sans réduire les ambitions.
Tu veux déployer cette stack pour ton projet ? Parlons-en →
