MailCatcher a bien servi Rails.
Et tout le reste ?
MailCatcher a été construit pour les développeurs Rails qui avaient besoin d'un moyen rapide de capturer des emails localement. C'est une gem Ruby, elle s'exécute sur votre machine, et c'est un outil fiable depuis des années. Mais quand votre stack dépasse Rails—ou votre équipe dépasse une personne—les outils locaux atteignent leurs limites.
Sendpit est un sandbox SMTP hébergé qui fonctionne avec n'importe quel langage. Toute votre équipe voit la même boîte, les emails persistent entre les déploiements, et vous n'avez pas besoin de Ruby installé.
Key Facts
- SendPit Basic: $5/mo for 3 mailboxes, 1,000 emails/month
- MailCatcher Gem Ruby auto-hébergée
- Pricing and features last verified: 2026-03-18
Ce que MailCatcher fait bien
MailCatcher became a staple in Rails development for good reasons. For a Rails developer, the setup is about as frictionless as it gets: run `gem install mailcatcher`, then `mailcatcher`, and you have an SMTP server on localhost:1025 with a web UI on localhost:1080. Add `config.action_mailer.delivery_method = :smtp` and point it at the right port. That's all there is to it.
The web interface is straightforward and effective. You get three tabs—HTML, Source, and Plain—that let you inspect exactly what your application sent. For Rails developers working alone on a single project, that workflow is hard to beat. No accounts, no configuration files, no internet connection required. It's the kind of tool that does one thing and does it simply.
MailCatcher earned its place in the Rails ecosystem. If you've been using it for years, you know why. It stays out of your way and lets you focus on building your application.
The Ruby installation tax
If your team already works in Ruby, installing MailCatcher is trivial. But for teams that write Python, Go, Java, PHP, or Node.js, the story is different. Installing MailCatcher means installing Ruby first—and Ruby version management is its own ecosystem of complexity.
You need a Ruby version manager like rbenv or rvm, or you rely on your system Ruby—which on macOS is either outdated or no longer included. Each approach has gotchas. rbenv requires Homebrew and shell initialization changes. rvm modifies your shell profile and can conflict with other tools. System Ruby, when available, often lacks permissions to install gems globally without sudo.
Even after Ruby is installed, MailCatcher depends on gems like `thin` and `eventmachine` that compile native C extensions during installation. On macOS Sonoma and Sequoia, this frequently fails. Missing Xcode command line tools, architecture mismatches between Apple Silicon and x86 dependencies, and incompatible OpenSSL versions all create errors that require investigation and workarounds. A new team member on a fresh MacBook can easily spend thirty minutes resolving these issues before catching a single email.
Some teams sidestep this by running MailCatcher inside Docker. That eliminates the Ruby dependency on the host machine, but introduces a different kind of overhead: now you're managing a container, mapping ports, and potentially adding a Docker Compose service just for an email testing tool. It works, but it defeats the simplicity that made MailCatcher appealing in the first place.
There's an irony here. MailCatcher is meant to be a simple, no-fuss tool. But for teams that don't already have Ruby in their toolchain, the installation process can become a yak-shaving exercise—thirty minutes of debugging native extensions and version managers before you can test a password reset email.
Single-threaded by design
Under the hood, MailCatcher relies on EventMachine, a Ruby event loop library that handles both the SMTP server and the web interface. EventMachine itself is largely unmaintained—its last meaningful update was years ago—and it enforces a single-threaded architecture. The SMTP server processes one connection at a time. For a single developer sending occasional test emails, this is invisible. But when multiple services or CI jobs send emails simultaneously, connections queue up or time out.
The web UI runs on `thin`, another aging Ruby web server. It serves static assets from memory, which keeps things lightweight but means no WebSocket support. To see new emails arrive, you have to manually refresh the browser. There's no live-updating inbox, no push notifications, and no way to know an email has landed without checking.
These aren't deal-breakers for local development with light usage. But they become noticeable as usage scales—when your test suite sends dozens of emails per run, when multiple developers share an instance, or when CI pipelines fire concurrent SMTP connections at the same endpoint. The single-threaded model was a reasonable choice for a simple local tool, but it imposes a ceiling on how the tool can be used.
Quand les outils locaux deviennent un goulot d'étranglement
"Nous avons ajouté un service Node"
MailCatcher est une gem Ruby. Votre microservice Go ou worker Python ne partage pas la même toolchain.
"La QA ne peut pas voir ce que je vois"
Votre MailCatcher s'exécute sur votre laptop. L'environnement staging de la QA envoie des emails dans le vide.
"CI a besoin d'un endpoint SMTP"
Faire tourner MailCatcher en CI est possible mais maladroit. Les conteneurs éphémères ne persistent pas les emails entre les jobs.
"Est-ce encore maintenu ?"
La fréquence de mise à jour de MailCatcher a ralenti. Pour certaines équipes, c'est un risque de dépendance.
Dès que votre stack inclut des services hors Ruby—ou votre équipe inclut des gens qui ont besoin de voir les emails depuis staging—le modèle de MailCatcher commence à montrer des lacunes. Il a été construit pour une époque plus simple où un développeur faisait tourner une app Rails.
Un sandbox SMTP hébergé vous donne le même workflow de capture et inspection, mais sans la dépendance Ruby, sans la limitation local-seulement, et sans vous soucier de l'activité du projet.
The Mailpit question
If you're considering alternatives to MailCatcher, you've probably come across Mailpit. It's worth addressing directly: Mailpit solves many of the problems described above. It's a single Go binary with no runtime dependencies—no Ruby, no native extensions, no version manager. The web UI is modern, with full-text search, real-time updates, and responsive previews. It's actively maintained and has become the default in frameworks like Laravel Sail and DDEV.
So why would you consider a hosted service like Sendpit over Mailpit? It comes down to what you need beyond local development. If your team needs shared access to test emails without setting up VPN tunnels or exposing ports, a hosted service handles that out of the box. If you manage multiple projects and want per-project mailbox isolation with separate credentials, that requires running multiple Mailpit instances yourself. If you need user accounts with role-based access controls so contractors see only their project's emails, Mailpit doesn't have that layer.
It doesn't have to be either-or. "Mailpit for local development, Sendpit for shared environments" is a perfectly valid pattern. Many teams use a local tool for the fast feedback loop during development and a hosted service for CI, staging, and team collaboration. The SMTP configuration is the same—just different credentials per environment.
For a deeper comparison of Mailpit and Sendpit, including a feature-by-feature breakdown, see our dedicated Mailpit comparison page.
Gem Ruby vs. service hébergé
Designed for its specific use case.
Hosted SMTP sandbox for teams.
Les deux capturent les emails. La différence est où vit la boîte, quels langages elle supporte et qui peut la voir.
Fonctionne avec n'importe quel framework
La boucle centrale est la même : configurer SMTP, envoyer des emails, inspecter ce qui arrive. Mais Sendpit se moque du langage dans lequel votre app est écrite. Rails, Laravel, Django, Express, Go—tout ce qui parle SMTP fonctionne.
Vous pouvez inspecter le HTML, voir les en-têtes, vérifier les liens et télécharger les pièces jointes. Les emails persistent selon vos paramètres de rétention. Pas d'installation Ruby, pas de gestion de processus, pas d'emails perdus quand vous fermez votre laptop.
Une config SMTP fonctionne à travers le dev local, CI et staging. Tout le monde dans l'équipe voit ce qui est envoyé, peu importe le framework avec lequel ils travaillent.
Les emails sont stockés temporairement, chiffrés et automatiquement supprimés selon vos paramètres de rétention.
What changes when you switch
Switching from MailCatcher to Sendpit is a credential change in your framework's mail configuration. Here's what that looks like in practice, depending on your stack.
config.action_mailer.smtp_settings = {
address: "your-smtp-host.sendpit.io",
port: 587,
user_name: "your_mailbox_username",
password: "your_mailbox_password",
authentication: :plain
}EMAIL_HOST = "your-smtp-host.sendpit.io"
EMAIL_PORT = 587
EMAIL_HOST_USER = "your_mailbox_username"
EMAIL_HOST_PASSWORD = "your_mailbox_password"
EMAIL_USE_TLS = TrueMAIL_MAILER=smtp
MAIL_HOST=your-smtp-host.sendpit.io
MAIL_PORT=587
MAIL_USERNAME=your_mailbox_username
MAIL_PASSWORD=your_mailbox_password
MAIL_ENCRYPTION=tlsconst transport = nodemailer.createTransport({
host: "your-smtp-host.sendpit.io",
port: 587,
auth: {
user: "your_mailbox_username",
pass: "your_mailbox_password"
}
});What you can remove
- × `gem 'mailcatcher'` from your Gemfile, or the Docker service definition if you containerized it
- × Ruby installation on machines that don't otherwise need it
- × The MailCatcher process that needs to be running before you can test emails
What you gain
- + Persistent emails that survive laptop restarts, container rebuilds, and deploys
- + Team visibility—everyone sees the same inbox without sharing a machine
- + CI and staging support with the same credentials used in local development
- + No Ruby dependency—works with any language or framework that speaks SMTP
Comparaison des fonctionnalités
| Fonctionnalité | MailCatcher | Sendpit |
|---|---|---|
| Capture SMTP | ✓ | ✓ |
| Hébergé dans le cloud | — | ✓ |
| Multi-boîtes mail | — | ✓ |
| Comptes d'équipe | — | ✓ |
| Contrôle d'accès par boîte mail | — | ✓ |
| Webhooks | — | ✓ |
| REST API | — | ✓ |
| Chiffrement TLS | — | ✓ |
| Aperçu responsive | — | ✓ |
| Score de spam | — | ✓ |
| Aperçu des pièces jointes | ✓ | ✓ |
| Tarifs | Gratuit (gem Ruby) | Plan gratuit + payant |
Choosing the right tool
MailCatcher a du sens si...
-
Vous travaillez seul sur un projet Rails.
-
Tout votre stack est Ruby et va probablement le rester.
-
Vous préférez les outils offline-first, local-seulement.
-
Vous n'avez pas besoin que les emails persistent ou soient partagés.
-
You value simplicity over features and are comfortable with minimal email volume.
-
You're a solo Rails developer who wants offline-first simplicity without any external dependencies.
Sendpit a du sens si...
-
Votre stack inclut des services non-Ruby.
-
Vous avez besoin que les coéquipiers ou la QA voient les mêmes emails.
-
Votre pipeline CI ou serveur staging envoie des emails.
-
Vous voulez que les emails persistent et soient récupérables.
-
You manage multiple projects and want separate mailboxes with isolated credentials.
-
You want to stop managing Ruby installations, native extension compilations, and process lifecycles for a dev tool.
Many Rails teams use both. MailCatcher for quick local debugging when you're deep in development, Sendpit for shared environments where the whole team needs visibility. MailCatcher remains a reasonable choice for solo Rails developers who want offline-first simplicity—but for polyglot teams, a language-agnostic hosted service removes an entire category of friction.
Vous cherchez d'autres comparaisons ?
Frequently asked questions
MailCatcher est-il encore maintenu ?
MailCatcher reçoit des mises à jour occasionnelles mais le développement a considérablement ralenti. Il reste fonctionnel pour la capture SMTP basique dans les environnements Ruby. Si vous avez besoin d'une solution activement maintenue avec des fonctionnalités modernes, Sendpit ou Mailpit sont de meilleures options.
MailCatcher fonctionne-t-il en dehors de Ruby et Rails ?
Oui, MailCatcher capture tout trafic SMTP quel que soit le langage d'envoi. Cependant, il est construit avec Ruby et son installation nécessite un environnement Ruby. Si vous n'avez pas déjà Ruby dans votre stack de développement, la mise en place ajoute de la complexité. Sendpit fonctionne avec n'importe quel langage via SMTP standard et ne nécessite aucune installation locale.
Puis-je migrer de MailCatcher vers Sendpit ?
Oui. Mettez à jour l'hôte et le port SMTP depuis le localhost:1025 de MailCatcher vers les identifiants SMTP de Sendpit. Ajoutez le nom d'utilisateur et le mot de passe Sendpit à votre configuration. Le changement est le même que vous utilisiez Rails, Laravel, Django ou tout autre framework — il suffit de mettre à jour les paramètres de transport SMTP.
Comment Sendpit se compare-t-il à MailCatcher pour les équipes ?
MailCatcher est un outil local mono-utilisateur — il tourne sur la machine d'un seul développeur et les e-mails capturés ne sont visibles que sur celle-ci. Sendpit est conçu pour les équipes avec des boîtes aux lettres partagées, un contrôle d'accès basé sur les rôles et la gestion d'organisation. Toute votre équipe peut consulter les mêmes e-mails de test capturés depuis n'importe quel appareil.
Sendpit dispose-t-il d'une API comme MailCatcher ?
MailCatcher possède une API HTTP basique pour lister et récupérer les messages. Sendpit propose une REST API avec authentification, pagination, recherche et pièces jointes (à partir du forfait Basic), ainsi que des webhooks pour les notifications en temps réel (Pro+). Si vous avez besoin d'un accès programmatique aux e-mails capturés dans les pipelines CI/CD, l'API de Sendpit est plus complète — mais nécessite un forfait payant.
Sendpit est-il gratuit comme MailCatcher ?
MailCatcher est entièrement gratuit et open source. Sendpit dispose d'un forfait gratuit permanent qui couvre les besoins de la plupart des petites équipes sans carte bancaire. La différence est que MailCatcher nécessite Ruby et une infrastructure locale, tandis que Sendpit est un service hébergé sans aucune configuration. Les forfaits payants ajoutent plus de capacité et des fonctionnalités comme les webhooks et l'accès API.
Try Sendpit free
Sendpit a un niveau gratuit qui couvre la plupart des besoins des petites équipes. La configuration est la même que tout outil SMTP—mettez à jour vos identifiants et commencez à capturer. Pas de Ruby requis.
Si vous avez dépassé le modèle local-seulement de MailCatcher, le moyen le plus rapide de savoir si Sendpit convient est de l'essayer.
Pas de carte de crédit requise. Niveau gratuit disponible.