MailCatcher served Rails well.
What about everything else?
MailCatcher was built for Rails developers who needed a quick way to catch emails locally. It's a Ruby gem, it runs on your machine, and it's been a reliable tool for years. But when your stack grows beyond Rails—or your team grows beyond one—local tools hit their limits.
Sendpit is a hosted SMTP sandbox that works with any language. Your whole team sees the same inbox, emails persist between deploys, and you don't need Ruby installed.
Key Facts
- SendPit Basic: $5/mo for 3 mailboxes, 1,000 emails/month
- MailCatcher Self-hosted Ruby gem
- Pricing and features last verified: 2026-03-18
What MailCatcher does well
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.
When local tooling becomes a bottleneck
"We added a Node service"
MailCatcher is a Ruby gem. Your Go microservice or Python worker doesn't share the same toolchain.
"QA can't see what I see"
Your MailCatcher runs on your laptop. QA's staging environment sends emails into the void.
"CI needs an SMTP endpoint"
Running MailCatcher in CI is possible but awkward. Ephemeral containers don't persist emails between jobs.
"Is this still maintained?"
MailCatcher's update frequency has slowed. For some teams, that's a dependency risk.
The moment your stack includes services outside Ruby—or your team includes people who need to see emails from staging—MailCatcher's model starts showing gaps. It was built for a simpler time when one developer ran one Rails app.
A hosted SMTP sandbox gives you the same capture-and-inspect workflow, but without the Ruby dependency, without the local-only limitation, and without worrying about project activity.
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.
Ruby gem vs. hosted service
Designed for its specific use case.
Hosted SMTP sandbox for teams.
Both capture emails. The difference is where the inbox lives, what languages it supports, and who can see it.
Works with any framework
The core loop is the same: configure SMTP, send emails, inspect what arrives. But Sendpit doesn't care what language your app is written in. Rails, Laravel, Django, Express, Go—anything that speaks SMTP works.
You can inspect HTML, view headers, check links, and download attachments. Emails persist based on your retention settings. No Ruby installation, no process management, no lost emails when you close your laptop.
One SMTP config works across local dev, CI, and staging. Everyone on the team sees what's being sent, regardless of what framework they're working with.
Emails are stored temporarily, encrypted, and automatically deleted based on your retention settings.
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
Feature comparison
| Feature | MailCatcher | Sendpit |
|---|---|---|
| SMTP capture | ✓ | ✓ |
| Cloud hosted | — | ✓ |
| Multi-mailbox | — | ✓ |
| Team user accounts | — | ✓ |
| Per-mailbox access control | — | ✓ |
| Webhooks | — | ✓ |
| REST API | — | ✓ |
| TLS encryption | — | ✓ |
| Responsive preview | — | ✓ |
| Spam scoring | — | ✓ |
| Attachment preview | ✓ | ✓ |
| Pricing | Free (Ruby gem) | Free tier + paid |
Choosing the right tool
MailCatcher makes sense if...
-
You're working alone on a Rails project.
-
Your entire stack is Ruby and likely to stay that way.
-
You prefer offline-first, local-only tools.
-
You don't need emails to persist or be shared.
-
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 makes sense if...
-
Your stack includes non-Ruby services.
-
You need teammates or QA to see the same emails.
-
Your CI pipeline or staging server sends emails.
-
You want emails to persist and be retrievable.
-
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.
Looking for other comparisons?
Frequently asked questions
Is MailCatcher still maintained?
MailCatcher receives occasional updates but development has slowed significantly. It remains functional for basic SMTP capture in Ruby environments. If you need an actively maintained solution with modern features, Sendpit or Mailpit are better options.
Does MailCatcher work outside of Ruby and Rails?
Yes, MailCatcher captures any SMTP traffic regardless of the sending language. However, it is built with Ruby and its installation requires a Ruby runtime. If you do not already have Ruby in your development stack, the setup adds overhead. Sendpit works with any language via standard SMTP and requires no local installation.
Can I migrate from MailCatcher to Sendpit?
Yes. Update your SMTP host and port from MailCatcher's localhost:1025 to Sendpit's SMTP credentials. Add the Sendpit username and password to your configuration. The change is the same whether you use Rails, Laravel, Django, or any other framework—just update the SMTP transport settings.
How does Sendpit compare to MailCatcher for teams?
MailCatcher is a single-user local tool—it runs on one developer's machine and captured emails are only visible there. Sendpit is designed for teams with shared mailboxes, role-based access control, and organization management. Your whole team can view the same captured test emails from any device.
Does Sendpit have an API like MailCatcher?
MailCatcher has a basic HTTP API for listing and retrieving messages. Sendpit provides a REST API with authentication, pagination, search, and attachments (Basic plans and above), plus webhooks for real-time notifications (Pro+). If you need programmatic access to captured emails in CI/CD pipelines, Sendpit's API is more capable—but requires a paid plan.
Is Sendpit free like MailCatcher?
MailCatcher is completely free and open source. Sendpit has a permanent free tier that covers most small team needs without a credit card. The difference is that MailCatcher requires Ruby and local infrastructure, while Sendpit is a hosted service with zero setup. Paid plans add more capacity and features like webhooks and API access.
Try Sendpit free
Sendpit has a free tier that covers most small team needs. Setup is the same as any SMTP tool—update your credentials and start capturing. No Ruby required.
If you've outgrown MailCatcher's local-only model, the fastest way to know if Sendpit fits is to try it.
No credit card required. Free tier available.