LARASEND : le dashboard email qu’AWS n’a jamais construit
📌 LARASEND est une plateforme d’emails transactionnels auto-hébergée pour Laravel qui permet d’envoyer via son propre compte AWS SES ou Cloudflare Email Service, en gardant le dashboard, les clés API, les logs de livraison et les webhooks sur son infrastructure.
Amazon SES est un service de messagerie transactionnel puissant et économique, mais il manque une interface de gestion visuelle. On configure SES dans la console AWS, on vérifie les domaines, on obtient des credentials, puis on branche l’API directement dans chaque application. Les logs de livraison, les suppressions, les métriques et le suivi d’activité restent dispersés ou nécessitent d’autres outils. Larasend comble cette lacune en ajoutant une couche de gestion complète au-dessus de SES et Cloudflare Email Service.
Le projet, développé par Savvy Agents avec 421 étoiles et 45 forks, se positionne comme le dashboard qu’AWS n’a jamais construit. C’est une application Laravel auto-hébergée avec Inertia, Vue, PostgreSQL et Redis, déployable via Docker Compose. L’architecture hybride est intéressante : le plan de contrôle (dashboard, API, logs) reste sur votre infrastructure, mais l’envoi réel passe par SES ou Cloudflare. Vous gardez la main sur les données, les logs et la configuration, tout en bénéficiant de l’infrastructure d’envoi de géants du cloud.
Larasend propose une API HTTP simple POST /api/emails avec authentification par clé API. Chaque clé API a des scopes, une date d’expiration, une rotation possible et des métadonnées de dernière utilisation. Pour les applications Laravel, un package permet de substituer directement le driver mail : MAIL_MAILER=larasend. L’interface gère les identités SES avec guidance pour les enregistrements DKIM, la vérification de domaine via DNS, et l’ingestion des événements SES (livraison, bounce, complaint, open, click). Cloudflare Email Service est supporté en alternative, avec un choix de provider par source.
Je trouve l’équipe inbox particulièrement pertinente pour les équipes support. Chaque projet dispose d’une boîte de réception partagée où les emails entrants et les sortants sont threadés en conversations (chaînes References/In-Reply-To, ou normalisation par sujet + participant partagé). La réponse sort comme l’adresse sur laquelle la conversation a été reçue, avec les headers de threading appropriés. On peut composer, transférer, joindre des fichiers jusqu’à 10 MB, utiliser du texte riche avec alternatives plain-text automatiques, snooze une conversation jusqu’à plus tard aujourd’hui, demain ou la semaine prochaine, ajouter des notes internes, et naviguer avec des raccourcis clavier (j/k, e, u, r, f, c, /).
L’interface de gestion est complète. Le dashboard d’activité propose des filtres par statut, une recherche, une timeline groupée, un aperçu dans l’inspecteur, les headers, les métriques et la possibilité de renvoyer. Les suppressions (hard bounces, spam complaints) sont suivies, et la santé des sources, la synchronisation des quotas provider et les garde-fous de livraison sont surveillés. Les membres de l’espace de travail et les permissions de projet permettent un contrôle d’accès fin. Le worker de queue envoie l’email brut via le provider de la source — Amazon SES (API HTTPS) ou Cloudflare Email Service (SMTP authentifié).
La sécurité est prise au sérieux. Les credentials AWS et les tokens API Cloudflare sont stockés chiffrés quand on choisit des credentials stockés. Pour la production sur AWS, on préfère un rôle d’instance ou de tâche plutôt que des clés d’accès à long terme. Les tokens API Cloudflare sont scopés à « Email Sending: Edit », « Zone: Read » et « DNS: Edit ». Les clés API ne sont affichées qu’une seule fois à la création. On utilise des scopes de projet et des dates d’expiration pour les clés API d’application. Le token webhook SES n’est pas exposé publiquement au-delà de l’URL webhook générée.
Le déploiement se fait via Docker Compose avec une production complète : l’app web (qui exécute les migrations automatiquement au démarrage), le worker de queue, le scheduler pour l’automatisation en arrière-plan (vérification DNS, rafraîchissement quota, synchro suppressions), PostgreSQL et Redis. Une commande de santé vérifie la clé d’application, la base de données, le worker de queue, le scheduler, les credentials provider et le DNS de domaine, et affiche le correctif à côté de chaque échec. Le développement local suit le workflow Laravel classique avec composer run dev qui lance le serveur, le worker, le scheduler, le tail de logs et Vite ensemble.
La distinction entre SES et Cloudflare Email Service est importante. SES publie des événements de livraison/bounce/complaint/open/click via webhook, ce qui permet un suivi détaillé. Cloudflare n’a pas de webhooks d’événements et pas de tracking open/click : l’état de livraison est enregistré à partir de la réponse SMTP au moment de l’envoi, et les suppressions syncent horaire depuis la liste au niveau compte Cloudflare. Pour l’email entrant, seul Cloudflare est supporté : activer « Receive email » sur un domaine déploie un Worker Cloudflare et pointe la règle de routing catch-all de la zone, donc le mail envoyé à n’importe quelle adresse sur l’apex de la zone atterrit dans la section Inbound et déclenche des webhooks inbound.received.
Le projet est jeune (v0.1.0, juillet 2026) mais déjà fonctionnel. La roadmap prévoit la publication Packagist pour le driver Laravel, plus de providers au-delà d’Amazon SES et Cloudflare Email Service, OAuth Cloudflare comme alternative aux tokens collés, le polling d’événements de livraison Cloudflare via l’API GraphQL Analytics, un lien de création rapide CloudFormation pour la configuration IAM SES, des rapports plus approfondis de santé et de délivrabilité par domaine, un workflow de déploiement de premier ordre pour mettre à jour les installations Docker auto-hébergées, et plus d’outils de création et de prévisualisation de modèles.
Larasend s’adresse aux équipes Laravel qui veulent contrôler leur infrastructure d’emails transactionnels sans sacrifier la commodité. C’est une alternative à Mailgun, SendGrid ou Postmark qui permet de conserver les données en interne tout en bénéficiant d’une interface de gestion complète. Pour les entreprises soumises à des contraintes de conformité, l’auto-hébergement est un atout majeur. Pour les développeurs Laravel, l’intégration drop-in et l’équipe inbox réduisent la friction par rapport à l’API directe SES.
La limite principale est l’investissement initial : configuration SES ou Cloudflare, déploiement Docker, maintenance de l’infrastructure. Mais pour une équipe avec plusieurs applications Laravel et des besoins de suivi détaillé, le ROI est évident. Les équipes support en particulier bénéficieront de la boîte de réception partagée et des outils de gestion de conversation.
Sources
