MailCrab logo

MailCrab

Lightweight Rust‑based email sandbox with web UI and API

MailCrab provides an accept‑all SMTP server and a browser‑based interface to capture, view, and download test emails, all packaged as a single 7.77 MB Docker image.

Overview

Overview

MailCrab is a Rust‑written email test server designed for developers who need a quick, reliable way to capture outgoing mail during development or CI runs. It runs as a single binary and is distributed as a 7.77 MB Docker image that works on both amd64 and arm64 platforms.

Capabilities & Deployment

The server accepts all SMTP traffic on a configurable port, stores messages in memory, and exposes a modern web UI where you can inspect formatted content, download attachments, view raw headers, or delete messages. Real‑time updates are pushed via WebSocket, and a simple REST API lets external tools query or manage messages. Configuration options include TLS generation, custom certificates, host/port overrides, path prefixes, retention periods, and queue sizing. Deploy with a one‑liner Docker command, a pre‑built binary, or via Helm for Kubernetes.

Ideal Use Cases

MailCrab shines in local development, automated test pipelines, and lightweight staging environments where persistent storage isn’t required, offering fast feedback without the overhead of a full mail server.

Highlights

Accept‑all SMTP server with configurable ports
Browser‑based UI for viewing, downloading, and inspecting messages
Single binary distribution; 7.77 MB Docker image for amd64/arm64
TLS support, path prefixing, retention period, and queue sizing

Pros

  • Fast Rust implementation with low resource footprint
  • Easy Docker/Kubernetes deployment
  • Real‑time WebSocket updates for instant feedback
  • Simple configuration via environment variables

Considerations

  • Messages stored only in memory; no built‑in persistence
  • High‑volume streams may exceed WebSocket throughput
  • Retention relies on process uptime or manual settings
  • TLS uses self‑signed certs unless custom keys are provided

Managed products teams compare with

When teams consider MailCrab, these hosted platforms usually appear on the same shortlist.

Mailinator logo

Mailinator

Disposable email testing inboxes with public and private domains

Mailosaur logo

Mailosaur

Email & SMS testing with disposable inboxes and phone numbers

MailReach logo

MailReach

Email warm-up and spam testing to boost inbox placement

Looking for a hosted option? These are the services engineering teams benchmark against before choosing open source.

Fit guide

Great for

  • Local development of email‑sending features
  • CI pipelines that need to capture and assert email content
  • Debugging HTML email rendering in a browser UI
  • Small teams requiring a quick, disposable mail sandbox

Not ideal when

  • Production email handling or delivery
  • Very high‑volume mail streams (>100 msgs/sec)
  • Long‑term archival or compliance‑driven storage
  • Complex authentication or enterprise‑grade TLS requirements

How teams use it

CI Test Suite Integration

Capture and assert email contents during automated builds without external services.

Frontend Email Template Debugging

Inspect rendered HTML emails and attachments directly in the browser UI.

Kubernetes Development Environment

Deploy via Helm chart to provide a shared email sandbox for the whole team.

TLS‑Enabled Integration Testing

Validate TLS handshake and basic authentication handling using generated or custom certificates.

Tech snapshot

Rust85%
SCSS12%
Smarty2%
HTML1%
Dockerfile1%

Frequently asked questions

Can I enable TLS for the SMTP server?

Set `ENABLE_TLS_AUTH=true` in the container environment; MailCrab will generate a self‑signed certificate or use mounted key/cert files.

Where are received emails stored?

Emails are kept in memory while the process runs; they are cleared on restart unless a retention period is configured.

Is there a way to persist messages to disk?

MailCrab does not include built‑in persistence; you would need to forward messages to external storage via the API or custom tooling.

What limits the throughput of incoming messages?

The WebSocket connection can become a bottleneck above ~100 messages per second; increasing `QUEUE_CAPACITY` helps mitigate loss.

Project at a glance

Active
Stars
931
Watchers
931
Forks
35
LicenseApache-2.0
Repo age3 years old
Last commit2 weeks ago
Primary languageRust

Last synced 3 hours ago