// the find
knadh/listmonk
High performance, self-hosted, newsletter and mailing list manager with a modern dashboard. Single binary app.
listmonk is a self-hosted newsletter and mailing list manager that ships as a single Go binary backed by PostgreSQL. It handles campaigns, transactional email, subscriber segmentation, bounce tracking, and click analytics out of the box. The target is anyone who wants Mailchimp-level features without the per-subscriber pricing or the data leaving their infrastructure.
- Single binary + Postgres is a genuinely good deployment model. No Redis, no message queue, no sidecars. You can run this on a $5 VPS with one docker-compose file and it stays running.
- Subscriber segmentation via raw SQL queries is the right call — operators who know their data can express arbitrary conditions without waiting for a UI checkbox to appear. The query-based approach is more honest about what it is than a fake drag-and-drop segment builder.
- The feature surface is unusually complete for a self-hosted tool: OIDC, role-based access, bounce handling (including SES/Mailgun/Postmark webhooks), media library, archive pages, transactional emails, and a REST API with Swagger docs. Most competitors in this space are missing three or four of these.
- 21k stars and a commit yesterday. The project is not abandoned, the issue tracker is active, and it ships releases with GoReleaser for every major platform including Windows and BSD.
- The frontend is Vue 2 with Buefy, and the visual email builder is a completely separate React/TypeScript app sitting alongside it. Two frameworks in one frontend repo is a maintenance smell — someone made a pragmatic decision to embed the email builder rather than port it, and now the project carries both build pipelines indefinitely.
- AGPLv3 means any modification you ship over a network requires open-sourcing your changes. For a tool you're running internally this is fine, but if you're building a product on top of listmonk, the license is a hard blocker.
- Raw SQL subscriber queries are powerful but the surface area for operator error is large — a slow query on a table with millions of rows will block a campaign send with no safeguards. There's no query timeout or row estimate warning visible in the UI from what's documented.
- No horizontal scaling story. The single binary model is a feature at small scale and a constraint at large scale. If you outgrow one instance, you're on your own — there's no guidance on running multiple workers or partitioning the send queue.