# Plunk: transactional email, campaigns and workflows you host

> Plunk is an AGPL-3.0 open-source email platform in TypeScript combining transactional sending with templates, SMTP relay, marketing campaigns, workflow automation with triggers and conditional logic, segments, real-time analytics and inbound email processing, self-hosted through a single Docker image with nginx, Postgres, Redis and MinIO. Pitched as an alternative to SendGrid, Resend and Mailgun at a stated $0.001 per email with no contact limits, v0.15.0 shipped in September 2026.

**useplunk/plunk** — The Open-Source Email Platform

- Repository: https://github.com/useplunk/plunk
- Website: https://www.useplunk.com
- Stars: 5,485 · Forks: 404
- Language: TypeScript
- License: AGPL-3.0
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/useplunk-plunk

## One platform where others sell pieces

Plunk's introduction compresses its scope into one line, transactional emails, marketing campaigns, and workflow automation in one platform, self-hostable, at a stated $0.001 per email with no contact limits, and then names the incumbents it answers, SendGrid, Resend and Mailgun. The implied critique is structural, those services price per email or per contact and split transactional sending from marketing, while Plunk collapses both onto infrastructure you can own. The feature list carries the argument, API-driven transactional sending with template support and variable substitution sits beside campaign newsletters, workflow automations with triggers, delays and conditional logic, and contact management with custom fields and full activity history. The pricing claim belongs to the project's own positioning rather than an independent measurement, but the no-contact-limits clause is architectural, a self-hosted instance does not meter your audience.

## SMTP relay for the tools you already have

Beyond the API, Plunk operates as an SMTP relay, accept email from any existing tool or framework and delivering it through your deployment, the integration path that requires no code change in whatever already sends mail. The compose file pins the relay's surface, ports 465 and 587 on the smtp subdomain, with TLS handled two documented ways, Traefik's acme.json mounted to a certificates path or plain PEM files, and an explicit fallback, the server runs without TLS if no certificates are mounted, stated plainly so an operator notices rather than discovers. Inbound email completes the loop in the other direction, receiving and processing incoming messages with custom routing rules, which turns the platform from a sender into a two-way endpoint, the shape needed for reply-to workflows and support-adjacent automation without bolting on a separate receiver.

## Campaigns, segments and live analytics

The marketing half earns its place through audience mechanics. Segments organize contacts with dynamic filtering so a campaign targets the right subset rather than the whole list, and campaigns themselves send newsletters and product updates to large audiences, the bulk case that stresses both infrastructure and reputation. Analytics track opens, clicks, bounces and engagement metrics in real time, the feedback loop that decides whether a segment definition works, and the contact records behind it carry full activity history so the numbers attach to traceable events. Workflows bind the halves together, triggers responding to events, delays pacing the sequence, and conditional logic branching on behavior, the automation vocabulary that turns a contact list into a lifecycle. For a product team, the combination replaces the typical stack of a transactional API, a newsletter tool and a marketing automation service with one self-hosted system.

## A single image, a subdomain topology

The self-hosting design is a single Docker image containing all the applications, API, worker, web dashboard, landing page and documentation, with a SERVICE environment variable selecting which one a container runs, fronted by an nginx reverse proxy in the compose setup. Routing is subdomain-based and documented at the top of the file, api for the API server, app for the web dashboard, www for the landing page, docs for documentation, smtp for the relay, so one deployment reads as five services to the browser while remaining one image to operate. The backing infrastructure is the conventional trio, Postgres 16 with a healthcheck, Redis 7 running with append-only persistence, and MinIO for object storage, each with named volumes and restart policy. Setup is the documented three steps, copy the environment example, set the domain names, run docker compose up, and the complete deployment guide lives in the documentation.

## A turbo monorepo with an MCP app inside

The codebase is a Yarn-workspaces monorepo driven by Turbo, with the apps directory holding api, web, landing, wiki, smtp and an mcp application, the last being a Model Context Protocol server, the modern integration point that lets LLM hosts drive the platform, and the source of the repository's most detailed comment, a version pinning note explaining that the MCP app needs zod 4 while the rest of the monorepo runs zod 3, and the hoisting arrangement that keeps both resolvable. Shared packages cover db, ui, types, email and shared code. Testing runs on vitest with coverage and UI modes plus supertest for HTTP-level checks, development services come up through a dedicated compose file, and the root scripts are the standard turbo verbs, build, start, dev, lint, clean. Releases run through release-please with a committed manifest and changelog, and the repository carries a PRODUCT.md and CLAUDE.md alongside the usual contribution guide, the documented-product posture of a project with commercial intent around its open core.

## Deliverability claims and their context

The custom domains feature states its mechanism, verify your domains and send from them with DKIM and SPF support, the two DNS records that underwrite sender authenticity, and that is where any self-hosted email platform's real difficulty lives. Plunk provides the record support and the sending infrastructure, but deliverability at the mailbox provider depends on IP reputation, warm-up and sending hygiene, factors owned by the operator rather than the software, which is the honest trade against SendGrid and Mailgun whose managed infrastructure exists precisely to carry that burden. The per-email price claim, $0.001, makes sense in the hosted-service framing of the project, where it undercuts per-email API pricing, while a fully self-hosted deployment's cost is the hardware and the operational attention. Teams evaluating the platform should separate the three questions the README merges, feature coverage, which is demonstrably broad, pricing, which depends on deployment mode, and deliverability, which depends on them.

## Governance and cadence

The license is AGPL-3.0, the strong copyleft choice that requires source availability for network-offered derivatives, the standard posture for open-source platforms with hosted competition, and one that commercial embedders must read before shipping. The project is developed under the useplunk organization with sponsorship through GitHub Sponsors of the primary maintainer, and the README makes the ask directly, if you self-host, consider supporting. Community runs through documentation at docs.useplunk.com and a Discord server, contribution follows a committed guide, and the release cadence is steady and current, v0.13.0 and v0.14.0 in August 2026 and v0.15.0 on 2026-09-20, with the repository's last push the following day and the default branch named next. For a category where the open-source options have historically been thin, the maintenance signal here is among the strongest arguments for adoption.

## Conclusion

Use Plunk when email sending, marketing and automation should live on your own infrastructure with full activity history and no contact-based pricing, either through the official hosted service or the self-hosted Docker deployment. Keep SendGrid, Resend or Mailgun when you prefer managed deliverability infrastructure and their maturity at scale, since running your own SMTP reputation is real operational work. Verify first that your DNS can carry the DKIM and SPF records custom domains require, decide TLS strategy for the SMTP relay before deployment since it runs unencrypted without mounted certificates, and read the AGPL-3.0 terms before embedding it in a commercial offering.

## FAQ

### Plunk vs Resend, how do they differ?

Plunk is an open-source, self-hostable platform combining transactional email, campaigns and workflow automation, positioned as an alternative to Resend, SendGrid and Mailgun with a stated $0.001 per email and no contact limits. Resend is a hosted API service, so the core difference is where the infrastructure runs and how it is priced.

### How do you self-host Plunk?

Pull the plunk Docker image, or use the docker-compose setup that runs all services behind an nginx reverse proxy with subdomain routing for the API, dashboard, landing page, docs and SMTP relay, backed by Postgres, Redis and MinIO. Copy the environment example, set your domain names and run docker compose up, with the full guide in the documentation.

### Can Plunk receive inbound emails?

Yes, inbound emails can be received and processed with custom routing rules, complementing the outbound transactional API, SMTP relay and campaign sending. Custom domains verify with DKIM and SPF support for authenticated sending.

## Sources

- [License: AGPL-3.0](https://github.com/useplunk/plunk/blob/next/LICENSE)
- [Project website](https://www.useplunk.com)
- [README](https://github.com/useplunk/plunk/blob/next/README.md)
- [Releases](https://github.com/useplunk/plunk/releases)
- [useplunk/plunk on GitHub](https://github.com/useplunk/plunk)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/useplunk-plunk