Open Source Resend Alternatives

Plunk puts transactional email, marketing campaigns and workflow automation in one self-hosted platform, so a product team stops paying for and stitching together a separate sender, newsletter tool and automation service. It positions itself against SendGrid, Resend and Mailgun.

Mail leaves through the API with template support and variable substitution, or through Plunk acting as an SMTP relay, which lets any existing tool or framework send through it without code changes.

Beyond sending, the platform manages the audience and the reporting.

• Campaigns: send newsletters and product updates to large audiences.
• Workflows: build automations with triggers, delays and conditional logic.
• Segments: filter contacts dynamically to reach the right audience.
• Contact management: keep custom fields and a full activity history per contact.
• Analytics: track opens, clicks, bounces and engagement in real time.
• Inbound email: receive incoming messages and route them with custom rules.

Custom domains are verified with DKIM and SPF so mail goes out under your own name. The easiest deployment is the official Docker image, with a full guide in the documentation, and the code is licensed AGPL-3.0. The project advertises a cost of $0.001 per email and no contact limits, which suits teams mailing long lists.

useSend is sending infrastructure you host yourself. Like most email products it uses Amazon SES underneath, and adds the dashboard, contact management and subscription handling that SES alone leaves you to build.

The stack is Next.js with Prisma, Tailwind and shadcn/ui, authentication through NextAuth.js, tRPC for the internal API and Hono for the public one, and Redis for the sending queue. The email editor is built on tiptap, converts its output to HTML with jsx-email, and takes its cues from maily.to.

The current release covers transactional and marketing sending alike.

• Domains: add and verify the domains you send from.
• Transactional mail: a REST API plus SMTP support for applications that already speak it.
• Marketing email: bulk sends such as newsletters and product updates, with subscriptions handled for you.
• Scheduling and webhooks: a schedule API for future sends, and webhooks for delivery events.
• Dashboard: delivered, opened, clicked and bounced figures in one view.

Inbound email and bring-your-own AWS credentials are listed but not yet built, and the project describes itself as being in beta while it opens up for public testing. Docker images are published on Docker Hub and the GitHub Container Registry, needing environment variables for the database, Redis and AWS, and a Railway template is the quickest way to stand an instance up.

Amazon SES is cheap, reliable and almost silent about what happens after you press send. That silence is why so many teams end up paying a transactional email provider that is largely an SES wrapper with a nicer interface. Sessy is the open source version of that interface, sitting on top of raw SES.

It is a Rails application, most easily run as a Docker image with a secret key base and a storage volume, with deployment docs for Kamal and Dokku if you want to run a fork. Background work goes through Solid Queue, and a dashboard at the jobs path lets you watch queues, retry failures and inspect recurring tasks.

What you get beyond the send itself is visibility and programmatic access.

• Delivery events: deliveries, bounces, complaints, opens and clicks presented in one interface.
• MCP server: a read-only endpoint lets coding agents search events, inspect a message timeline with bounce diagnostics and pull aggregate stats.
• API keys: created in the web UI, and the MCP endpoint authenticates with those keys only, ignoring HTTP basic auth entirely.
• CDN caveat: Cloudflare bot protection blocks MCP clients unless you exempt that path.
• Hosted code in the open: the managed version's engine lives in this repository, and the test suite verifies the open source build behaves identically without it.

Guides cover configuring SES itself and hardening an install for security and deliverability. The license is O'Saasy, except where a subdirectory says otherwise.

Building an email-heavy application on SES means two chores before you see a single bounce: wiring up the SES to SNS to SQS pipeline, which is a headache for anyone not fluent in AWS, and then finding somewhere to actually read the results. DoubleZero, published as 00, removes both.

An SST configuration step sets up the pipeline for you. Set the sending domain or address in an environment variable, run the deploy command, and SST does the rest; a wiki guide covers the manual AWS route for people who prefer to click through it. The app itself is a published Docker image on port 4000, backed by SQLite and configured with AWS credentials, the queue address, a system email, a secret and the public host.

Once it is up, it does the sending as well as the watching.

• Send over HTTP: POST a JSON body to the emails endpoint with a bearer token and the message is queued.
• Flexible payloads: markdown or HTML bodies, plus subject, cc, reply-to, custom headers, provider options and attachments.
• Multi-recipient tracking: a message record is created per recipient, so status is tracked individually.
• Search: query across emails and messages and view the body of any of them.
• Log tracking: requests and queue activity are logged for when something goes missing.

After the AWS side is configured you still verify your domain by publishing three DKIM records, which AWS says may take up to 72 hours. SST does not yet deploy the container itself.

Running a small product usually means paying for a deployment platform, an error tracker, an analytics service, an uptime monitor, an email sender, and a sandbox provider, then stitching six dashboards together. Temps collapses that into one self-hosted install deployed with a single shell command.

Git push builds and deploys any language it auto-detects, or your own Dockerfile, with preview links and zero-downtime rollouts, and it provisions Postgres, Redis, MinIO, and MongoDB alongside your apps. The proxy runs on Cloudflare's Pingora engine with automatic TLS from Let's Encrypt. If you already run Coolify, Dokploy, CapRover, or Portainer, an import wizard carries over apps, databases with their data, domains, and variables.

Observability and the AI surfaces are built in rather than bolted on.

• Error tracking: point the official Sentry SDK at a Temps DSN for error groups, stack traces, and alerts without per-event pricing.
• Analytics: visitor tracking, funnels, and rrweb session replay, with nothing leaving your servers.
• OpenTelemetry: any OTLP exporter feeds traces, metrics, and structured logs into one place, with no Grafana, Prometheus, Jaeger, or Loki to run.
• AI gateway: bring your own keys for OpenAI, Anthropic, Google, and xAI behind one OpenAI-compatible endpoint with per-request cost attribution.
• Sandboxes: Firecracker microVMs or Docker isolate agent-generated code, with password-protected preview links.
• Agent control: more than 440 CLI operations across 69 groups, plus skills that teach Claude Code, Codex, or OpenCode to drive them.

Uptime monitors and alerting round it out, and the built-in chat answers from your own telemetry, read-only unless you opt into writes.

Wraps sets up email infrastructure inside your own AWS account with one CLI command, then hands you a TypeScript SDK to send through it. The middleman disappears: you pay AWS directly for sending, and if the project vanished tomorrow the pipeline it built would keep working.

A single init run provisions the whole stack, namespaced under a common prefix and tagged as managed by the CLI, so it stays obvious what belongs to Wraps. Sending afterwards is a few lines of typed code, with visual templates, analytics and a dashboard on top.

That one command creates the pieces an email pipeline needs.

• SES: domain verification with DKIM, SPF and DMARC records handled for you.
• EventBridge and SQS: bounces, opens, clicks and deliveries arrive as real-time events.
• DynamoDB: email event history is retained for a configurable window.
• Lambda: event processing and webhook handling run as functions in your account.
• IAM: least-privilege roles with OIDC support for Vercel and AWS native workloads.

SMS has its own CLI and SDK, and CDK and Pulumi packages cover infrastructure as code. Node 20 or newer plus configured AWS credentials are the only prerequisites. The code is AGPL-3.0 with enterprise features under a commercial license, and the project publishes an agent-readable documentation bundle for people working through Claude Code or Cursor.