---
title: "Listmonk: The Self-Hosted Newsletter Engine That Kills the Per-Subscriber Tax"
date: 2026-10-16
excerpt: "Listmonk is a single Go binary backed by PostgreSQL that runs your newsletter, mailing lists, and transactional email on your own hardware. No per-subscriber pricing, no data leaving your jurisdiction — but deliverability is now your problem. A 5000-word deep dive on costs, limits, and data sovereignty."
cover: https://picsum.photos/seed/listmonk/800/450
tags:
- opensource
- newsletter
- email
- selfhosted
- privacy
- datasovereignty
- smtp
---
1. What Listmonk Actually Is
Listmonk describes itself as a "self-hosted newsletter and mailing list manager." That sentence undersells it. Under the hood it is a high-throughput, multi-tenant bulk email engine that happens to ship as a single static binary and asks for nothing more than a PostgreSQL database to function. It is maintained primarily by Kailash Nadh, the CTO of Zerodha (India's largest stockbroker), and Zerodha uses it in production to send enormous volumes of mail. That lineage matters: Listmonk was not built as a weekend hobby project, it was built to replace expensive vendor tooling inside a company that sends tens of millions of transactional and marketing messages.
The pitch is simple and aggressive. Mailchimp, ConvertKit, and most hosted ESPs (email service providers) charge you in proportion to the size of your list. The moment you cross 10,000, 50,000, or 100,000 subscribers, your monthly bill climbs steeply — often $100, $200, or $400 a month — even if you only email that list occasionally. Listmonk removes that tax entirely. You pay only for the server it runs on and the SMTP relay that delivers the messages. Your subscriber count is unlimited and free.
That economic argument is the reason most people install it. But the deeper reason, and the one that fits a self-hosting and data-sovereignty worldview, is control. When you run Listmonk, every email address, every tag, every campaign, and every open/click event lives in a PostgreSQL database that you own, on a machine you administer, in a jurisdiction you choose. No third party holds your audience. No vendor can change your pricing overnight. No analytics black box decides what you are allowed to know about your own readers.
2. The Architecture: One Binary, One Database
Listmonk's architecture is almost aggressively minimal. There are exactly two runtime components you must operate:
- The Listmonk application, a compiled Go binary (or its Docker image).
- A PostgreSQL database that stores everything.
There is no Redis requirement for basic operation, no message queue to tune, no separate worker fleet to keep alive. The binary itself contains a multi-threaded sending engine, a web dashboard, a REST API, and a templating renderer. When you start it, it listens on a single HTTP port (9000 by default) and talks to Postgres over a connection string you provide in
config.toml.
This is a deliberate design choice and it pays off. A production Listmonk instance sending a campaign of more than seven million emails was measured by the maintainers at a peak of roughly 57 MB of RAM and a fraction of a single CPU core. Those are staggering numbers for a bulk-mail system. The reason is that Listmonk does not render each email at send time in a heavy interpreted runtime; it compiles templates efficiently and streams personalized messages straight to SMTP.
The frontend is a Vue.js application (using Buefy for the component layer) bundled into the binary. You do not run a separate Node build. You point a browser at the server, log in, and you are looking at the dashboard. For most self-hosters this means the entire stack fits inside one
docker-compose.yml that launches the app container and a Postgres container side by side.
3. How It Works: Lists, Subscribers, Campaigns
The data model is small and easy to reason about, which is part of the appeal.
A subscriber is a person with at least an email address and optionally a set of arbitrary key/value attributes (name, plan, country, signup source, anything you like). Those attributes are stored as a JSON blob per subscriber and become the raw material for segmentation.
A list is a named grouping of subscribers. A subscriber can belong to many lists. Lists are the unit you target when you send. You can run single opt-in or double opt-in, and you can attach an arbitrary number of lists to a campaign.
A campaign is a single send: a subject, a template, a target set of lists, a schedule, and a status (draft, scheduled, running, finished). Campaigns can be one-shot broadcasts or recurring. Listmonk stores per-recipient render state so you can resume a campaign after a crash without duplicating mail.
A template is a reusable HTML (or plain text, or Markdown) email body that supports Go templating. Templates are the heart of Listmonk's flexibility: you can inject subscriber attributes, build conditional blocks, loop over data, and call more than a hundred helper functions. A single template can render radically different content for different segments.
The fourth concept is transactional messaging, which is simply campaigns addressed through the API to a specific subscriber with a specific template — password resets, order confirmations, alert digests. The same engine that blasts your newsletter also sends your receipts.
4. Installation: Docker Compose in Practice
The official quickstart is genuinely two commands:
``
mkdir listmonk && cd listmonk
curl -LO https://github.com/knadh/listmonk/raw/master/docker-compose.yml
docker compose up -d
`
On first boot the bundled Postgres container initializes, and Listmonk runs its schema migration automatically when you pass --install (the compose file is pre-wired to do this on the first run). You then open http://localhost:9000, create the admin user, and you are in.
Two changes are non-negotiable before this touches real traffic. First, bind port 9000 to 127.0.0.1 inside the compose file and put Listmonk behind a reverse proxy that terminates TLS. Exposing the raw dashboard to the internet is how people get their admin panel brute-forced. Second, change the Postgres password from the example value, because that database holds every subscriber's email address in plaintext-ish form. Treat the database credentials like the crown jewels they are.
A third, easy-to-miss step is the Root URL setting under Settings → General. Every unsubscribe link, tracking pixel, and archive link in your outgoing email is built from this value. Leave it on the localhost default and your first campaign ships with broken unsubscribe links — which is both a deliverability disaster and, under Gmail and Yahoo's 2024 bulk-sender rules, a compliance problem. Set it to your public HTTPS address, for example https://lists.example.com, before you send anything.
5. Configuration Essentials
Listmonk reads a single TOML file. The important knobs:
app.address — the bind address and port.
db.host, db.user, db.password, db.database — Postgres connection.
smtp — one or more SMTP server blocks. You can define several and, since version 6.2, pick one per sender domain.
root_url — discussed above.
auth — admin credentials, or, preferably, external SSO.
privacy — controls whether open and link tracking pixels are embedded by default.
Version 6 introduced a first-run web wizard that captures much of this, but the TOML remains the source of truth and the thing you back up. Environment variables can override individual keys, which is how most container deployments inject secrets without committing them to a file in the image.
One subtle but important point: Listmonk does not store your SMTP password in an encrypted vault beyond whatever your secret-management story is. It sits in config.toml or in an environment variable. If an attacker reads that file, they can send mail as you. This is why the dashboard, the config file, and the database all deserve tight filesystem permissions and, ideally, an external secrets manager.
6. Choosing an SMTP Provider — Where Your Mail Really Goes
This is the section most first-time self-hosters misunderstand, so it is worth stating flatly: Listmonk does not deliver email. It queues messages, personalizes them, and hands them to an SMTP server. The SMTP server is what actually talks to the world. If you point Listmonk at your own VPS's local mail agent, your mail will almost certainly land in spam, because most cloud providers block outbound port 25 and because a brand-new server IP has zero sending reputation.
You need a reputable relay. The common choices in late 2026:
- Amazon SES — about $0.10 per 1,000 emails after the free tier, the cheapest at volume, but more setup and a sandbox that initially only emails verified addresses.
- Postmark — around $15/month for 10,000 emails, excellent deliverability and reputation, easiest onboarding.
- Brevo (Sendinblue) — free tier of 300 emails/day, paid plans scale up.
- Mailgun — around $15/month entry, strong API and webhooks.
The economic picture is what makes self-hosting compelling. Sending 200,000 emails a month (roughly a 50,000-person list, four times a month) through SES costs about $20 in sending fees. Add a $5/month VPS and you are at $25/month total. The equivalent audience on a hosted platform routinely costs $200 to $400/month. The bigger your list, the wider the gap.
7. Deliverability: The Part Nobody Warns You About
Deliverability is the hidden tax of self-hosted email, and it is the single most common reason people give up and go back to a SaaS. Three things determine whether your newsletter reaches the inbox:
- Authentication (SPF, DKIM, DMARC). You must publish DNS records that prove you are allowed to send on behalf of your domain and that signatures are valid. Without DMARC alignment, Gmail and Yahoo will throttle or junk you.
- Reputation. A new sending domain and IP start with no history. You warm them up by sending small volumes of engaged mail and gradually increasing. Sudden spikes to a cold domain trigger spam filters.
- Engagement and list hygiene. Bouncing addresses, spam complaints, and dead lists destroy deliverability. Use double opt-in, honor unsubscribes instantly, and prune inactive subscribers.
Listmonk helps here: it processes bounce notifications (via a POP3 mailbox it polls or via webhooks from SES/Postmark/SendGrid), it tracks complaints when your provider forwards them, and it supports suppression lists so unsubscribed and bounced addresses are never mailed again. But the DNS and warm-up discipline is entirely on you. A self-hosted newsletter is a small operations project, not a fire-and-forget SaaS.
There is also a newer compliance layer: Gmail and Yahoo now require one-click unsubscribe headers (RFC 8058 List-Unsubscribe-Post) and a visible unsubscribe link for bulk senders. Listmonk emits these headers, but only if your Root URL is correct and your templates include the unsubscribe link. Get this wrong and the same providers that deliver your competitor's mail will silently drop yours.
8. Templates and the Go Templating Engine
Listmonk's templating is its secret weapon and its steepest learning curve. Templates are written in Go's text/template dialect extended with Sprig-style helper functions — more than a hundred of them. You can do real logic:
- Inject
{{ .Subscriber.Name }} or any custom attribute.
Branch with {{ if eq .Subscriber.Attributes.plan "pro" }} blocks.
Loop, format dates, transform strings, even generate conditional offers.
Compose subject lines dynamically per recipient.
The editor supports a visual drag-and-drop builder, a WYSIWYG mode, Markdown, raw syntax-highlighted HTML, and plain text. For most operators the drag-and-drop builder is enough; for power users the raw templating is the difference between a generic blast and a genuinely personalized message. One practical tip: always author a plain-text part alongside the HTML. Multipart messages with a real text alternative consistently outperform HTML-only mail on deliverability.
Media handling deserves a note. Inline images can be embedded, but at scale you should host images in an S3-compatible bucket (Listmonk's media library supports an S3 backend) and reference them by URL, because large base64 blobs bloat every message and trigger content filters. The same S3 bucket is where you might stash campaign assets.
9. Segmentation With Raw SQL
Most newsletter tools trap your segmentation logic inside a clumsy point-and-click builder. Listmonk does the opposite: you segment subscribers by writing SQL. Any query that returns a set of subscriber IDs can become a campaign's audience. Want everyone who signed up in the last 30 days, opened the last three campaigns, is on a paid plan, and lives in the EU? That is a SELECT id FROM subscribers WHERE ... joined against the campaign_views and lists tables, and you can save it as a template for reuse.
This is liberating if you know SQL and oppressive if you do not. It is the clearest expression of Listmonk's design philosophy: it is a tool for engineers and technically confident operators, not a toy for non-technical marketers. The upside is that you are never blocked by a missing feature in the UI — if Postgres can express it, you can mail it.
10. Analytics and Link Tracking
Listmonk ships built-in analytics: per-campaign open rates, click rates, top links, bounce counts, and a raw event table you can query. Opens are tracked via a 1×1 pixel; clicks are rewritten through a redirect that records the event before sending the reader to the destination. Both are toggleable per campaign and governed by a global privacy setting, which matters under GDPR and under Apple's Mail Privacy Protection (which inflates open rates by pre-fetching pixels — a fact every email marketer should internalize).
For serious analysis you will likely export events to your own warehouse or pair Listmonk with a self-hosted analytics tool (see the Related section). The event data is all in your Postgres, so there is no vendor lock-in on the metrics either — you can build whatever dashboard you want on top of the campaign_views and link_views tables.
11. Transactional Email and the API
Everything the dashboard does is also available through a JSON HTTP API with API users and granular tokens. This is how Listmonk earns its place beyond newsletters: you can wire your application's password-reset flow, order receipts, and alert digests through Listmonk templates and let the same engine and the same sending reputation handle them. The POST /api/tx endpoint takes a subscriber, a template, and a messenger (email, or, via webhooks, SMS/WhatsApp/FCM) and fires the message.
The messenger abstraction is broader than email. Listmonk can deliver through HTTP webhooks to SMS gateways, WhatsApp bridges, or any system you integrate, which makes it a lightweight notification hub, not just a mailing list. For a self-hoster running several services, having one authenticated, rate-limited, templated message bus is genuinely useful.
12. Authentication, OIDC SSO, and 2FA
Listmonk supports multiple system users with roles and per-list permissions. Since version 6 it added OpenID Connect single sign-on, so you can authenticate admins through an identity provider such as Authentik or Keycloak rather than managing yet another password. It also supports two-factor authentication via TOTP for the built-in accounts. Granular API tokens let you issue a key that can only send transactional mail, or only read analytics, without granting full admin.
This matters for security hygiene. The dashboard is a privileged surface: anyone who controls it controls your mail and can read your entire list. Putting it behind SSO with 2FA, and gating it behind a reverse proxy that also enforces its own auth, is the recommended posture. Do not expose the admin UI to the public internet unprotected.
13. The Real Cost of Self-Hosting Listmonk
Let's put concrete numbers on it. Assume a mid-size independent operator: a 50,000-subscriber list emailed four times a month (about 200,000 emails/month), plus some transactional mail.
Compute. Listmonk itself is trivially light. A Hetzner CAX11 (2 ARM vCPU, 4 GB RAM) at about €3.79/month (~$4) is comfortably enough; many run it on a Raspberry Pi at home for essentially zero recurring cost. If you want headroom and managed convenience, a CAX21 (4 vCPU, 8 GB) is about €7.69/month (~$8). Call compute $4–10/month.
Database. The bundled Postgres in the same compose costs nothing extra. If you prefer managed Postgres for backups and uptime, Hetzner's Managed PG starts around €6–13/month for a small instance. Call it $0–13/month.
SMTP relay. Through Amazon SES at $0.10/1,000, 200,000 emails is $20/month. Postmark at $15 for 10,000 would be ~$300 at that volume, so SES wins at scale; Postmark's $15/month tier is attractive below 10,000/month. Call sending $0–20/month depending on volume and provider.
Domain and TLS. A domain is ~$10–12/year; TLS certificates are free via Let's Encrypt through Caddy or your proxy. Effectively $1/month.
Total all-in: roughly $5–45/month, dominated by sending volume, with the software and compute nearly free. Compare that with a hosted ESP at the same list size, which typically runs $100–400/month once you clear the 50k-subscriber mark, and the savings are obvious and they scale in your favor as the list grows.
The honest counterweight: that $5–45/month buys you a system you must actually operate. Backups, Postgres upgrades, TLS renewal, DNS, and deliverability warm-up are line items of your time, not the vendor's. If your time is the scarce resource, the "free" software has a real carrying cost.
14. Where Your Data Lives: Data Sovereignty
This is the section that matters most for a self-hosting audience, so let's be precise.
When you run Listmonk, the subscriber database — email addresses, names, tags, custom attributes, campaign history, open and click events — resides in a PostgreSQL instance that you control. It runs on a server in a region you choose. There is no cloud control plane, no mandated SaaS layer, no telemetry that phones home to the maintainer. The project is a binary you download and run; nothing in the core requires communication with Kailash Nadh's infrastructure. Your audience data never transits a third party's analytics pipeline.
That has direct legal consequences. Under GDPR, the data controller (you) decides where personal data is stored and who can access it. Self-hosting Listmonk means you can keep EU subscribers' data in the EU, produce a data-export for any subject who asks, and permanently delete a record on request — all without filing a support ticket with a US-headquartered vendor that falls under the CLOUD Act. Contrast this with a typical hosted ESP, where your list lives in the vendor's infrastructure (often US-based) and your access to raw data is mediated by their export tools and their retention policy.
There are caveats. Data sovereignty is only as strong as your posture. PostgreSQL stores subscriber attributes in cleartext JSON unless you encrypt at the disk or column level yourself. The dashboard and API are only as safe as your reverse proxy and SSO. And your SMTP relay (SES, Postmark) does briefly handle the addresses you mail, so "sovereignty" stops at the edge of your sending provider — choose one whose jurisdiction and terms you trust. Listmonk maximizes your control; it does not magically encrypt everything for you.
15. Honest Limitations
No tool this lean is free of trade-offs, and the marketing copy will not tell you these:
- It is not an ESP. Listmonk queues and personalizes; it does not deliver. Deliverability, IP warming, and DNS authentication are your responsibility. If mail lands in spam, the fix is operational, not a setting.
- No visual automation journeys. Unlike Mautic or HubSpot, Listmonk has no drag-and-drop workflow builder for multi-step drip sequences with branching waits and conditions. You can approximate sequences with scheduled campaigns and SQL segments, but there is no native journey canvas.
- PostgreSQL operations are on you. Backups, major-version upgrades, and monitoring are your job. A corrupted or un-backed-up database means losing your entire list.
- Bus factor of one. The project is sustained primarily by a single maintainer. There is no foundation backing, no commercial SLA for the open-source core. Security patch coverage depends on one person's availability.
- AGPL network clause. If you modify Listmonk and expose that modified version over a network, you must publish your changes under AGPL-3.0. Internal use is unrestricted, but a modified hosted offering triggers copyleft.
- Bounce/complaint plumbing needs setup. You must configure a POP3 mailbox or webhooks so Listmonk learns about bounces and complaints; otherwise suppression goes stale and deliverability rots.
- No official hosted version. There is no vendor to call. Support is community forums and GitHub issues. For some organizations that is a deal-breaker.
- Images at scale need S3. The local media library is fine for small deployments; high-volume senders should wire an S3-compatible backend for assets.
16. Security Model and Hardening
Listmonk's security model is "you are the operator." Concrete hardening steps:
- Run the container unprivileged, with only the directory and database it needs mounted.
- Bind the app port to localhost and terminate TLS at a reverse proxy that also enforces its own authentication in front of the admin UI.
- Enable OIDC SSO and 2FA; disable or tightly scope local admin accounts.
- Store
config.toml and the database password outside the image; restrict file permissions.
Keep the server patched; the binary is small but it still parses untrusted input (subscriber attributes, template uploads).
Put Listmonk behind a WAF or at least rate limiting if it is internet-facing for signup forms, to blunt list-injection attacks where spammers try to subscribe victims' addresses en masse.
The maintainers have a HackerOne bug bounty and a security policy, which is a good sign for a project of this size. But the attack surface is your deployment, not theirs.
17. Backups and Disaster Recovery
Because everything lives in Postgres, backup discipline is the whole game. The recommended approach is a scheduled pg_dump to an offsite location (object storage via rclone or your proxy's bucket), tested with a periodic restore. Before every version upgrade, take a fresh dump — the schema migrations are robust, but a rollback is impossible without one. The official docs themselves tell you to back up before upgrading and show the restore-from-dump command; there is no bespoke backup button in the UI.
A reasonable cadence for a growing list: nightly dump, weekly offsite copy, and an immediate dump before any docker compose pull upgrade. Losing the database means losing every subscriber attribute and campaign history — the one catastrophe Listmonk cannot recover you from.
18. Scaling to Millions of Subscribers
Listmonk is unusually honest about scale: the maintainers cite a production send of 7M+ emails at 57 MB peak RAM. The engine is multi-threaded and can saturate a network link faster than PHP-based alternatives. Practical scaling levers:
- Run Postgres on decent storage (NVMe) because the
campaign_views and link_views tables grow fast at volume.
Use multiple SMTP servers and let version 6.2 route by sender domain to spread load and isolate reputation.
Consider a dedicated VPS for the app and a managed or tuned Postgres for the data, rather than the all-in-one compose, past a few hundred thousand subscribers.
Archive or prune old event data on a schedule to keep queries fast.
It will not, however, give you multi-node active-active failover out of the box; that is a Postgres story. For the vast majority of self-hosters — up to low millions — a single well-provisioned instance is plenty.
19. Listmonk vs the Alternatives
- Mailchimp / ConvertKit. Easiest onboarding, best deliverability reputation out of the box, but per-subscriber pricing and your data lives with them. Choose them if ops time is scarcer than money.
- SendGrid / Postmark. These are delivery APIs, not list managers. Listmonk is the management layer that routes through them; they are complementary, not competitors.
- Mautic. The full marketing-automation suite: journeys, scoring, the works. Heavier to run, PHP-based, more features you may never use. Listmonk is the surgical tool; Mautic is the Swiss Army knife.
- BillionMail and others. Emerging sovereign-delivery projects are appearing, but Listmonk's maturity, Zerodha production pedigree, and 23k+ stars make it the safe default today.
20. The License Reality: AGPL-3.0
Listmonk is AGPL-3.0. For internal self-hosting — running it to mail your own audience — the license is effectively permissive: do what you want, no obligations. The network clause only bites if you modify the source and then offer that modified version to others over a network (including as a paid SaaS). At that point you must publish your modifications under AGPL. Most operators never hit this; they run the upstream binary unmodified. But if your business model is "fork Listmonk, add features, sell hosted access," you must open those changes. Know this before you build a product on top of it.
21. Who Should and Shouldn't Self-Host It
Self-host Listmonk if: you have (or want) a technically owned audience and the list is large enough that SaaS pricing stings; you have basic Postgres and Linux comfort; you care about keeping subscriber data in your own jurisdiction; you send newsletters, transactional mail, or both and value unlimited subscribers at zero per-seat cost.
Look elsewhere if: you have no appetite for DNS, deliverability warm-up, and database backups; you need visual marketing-automation journeys; you require a vendor SLA and phone support; or your team lacks anyone who can run a Linux service. For those cases, a managed ESP or Mautic-with-support will cost more but cost you less sleep.
22. Running Listmonk at Home on Idle Hardware
One of Listmonk's underrated strengths is how little it demands. Because peak RAM in production was measured at ~57 MB and CPU usage is a fraction of a core, you do not need a cloud VPS at all. A Raspberry Pi 4 (or even a Pi 3 with an SSD rather than a fragile SD card), an old NUC in a closet, or a surplus mini-PC all run it comfortably. The compute cost there is the electricity — typically $1–3 per year for a Pi, a few dollars more for a small x86 box. The subscriber database lives on that same machine, so your audience data never leaves your home network except when it is handed to your SMTP relay for delivery.
The catch is connectivity. A residential ISP usually blocks outbound port 25 and often assigns a dynamic IP that changes, which makes a stable public endpoint awkward. The common pattern is to keep Listmonk at home for the database and dashboard, and to send through a cloud SMTP relay (SES or Postmark) for actual delivery, while exposing only the admin UI through a tunnel or reverse proxy with a fixed domain. Power users run the whole stack on a cheap always-on VPS and skip the home-network gymnastics. Either way, the point stands: the software's footprint is so small that the hardware decision is yours, not the vendor's, and that is the essence of data sovereignty done cheaply.
23. Common Operational Pitfalls
A short field guide to the mistakes that actually bite people:
- Forgetting Root URL. The classic first-timer error. Campaigns go out with
localhost unsubscribe links, breaking compliance and trust. Set Root URL before the first send.
Exposing the dashboard. Binding port 9000 to 0.0.0.0 without a proxy invites brute force. Bind to localhost, proxy with TLS, add SSO.
Skipping bounce handling. Without a POP3 mailbox or webhooks, Listmonk never learns about hard bounces, so it keeps mailing dead addresses, and your reputation craters.
No database backup. A single un-backed-up Postgres is a single point of total loss. Nightly dump offsite, tested restore.
Cold-IP bulk blasting. Pointing at a fresh VPS IP and sending 100k messages day one guarantees the spam folder. Warm up, authenticate DNS, start small.
Plaintext images in templates. Base64 blobs bloat messages and trip filters. Host images on S3 and link them.
Upgrading without a dump. Schema migrations are solid, but a pre-upgrade backup is your only rollback.
None of these are bugs in Listmonk; they are the ordinary responsibilities of running mail infrastructure. The operators who thrive with it are the ones who treat it like the production system it is.
24. A Practical First-Week Checklist
If you are spinning this up for the first time, a sensible sequence keeps the pain low:
- Day 1 — Stand up the stack.
docker compose up -d with Listmonk plus Postgres, bind the app port to localhost, and create the admin user. Do not expose anything yet.
Day 1 — Set Root URL. Under Settings → General, point it at your future public HTTPS address before you forget.
Day 2 — Proxy and TLS. Put Listmonk behind Nginx Proxy Manager or Traefik with a Let's Encrypt certificate, and enable SSO plus 2FA for the admin login.
Day 2 — Wire SMTP. Add one relay (SES or Postmark), verify a sending domain, and publish SPF, DKIM, and DMARC records.
Day 3 — Backups. Schedule a nightly pg_dump` to offsite storage and confirm you can restore it into a throwaway container.
Follow that order and the scary parts of self-hosted email — deliverability and data loss — are mostly neutralized before your first real campaign.
25. Related Articles
If you are building a self-hosted communication stack around Listmonk, these deep dives on this blog cover the adjacent pieces:
- Own your audience metrics too with self-hosted Umami analytics
- Front Listmonk's admin UI with Authentik for SSO and 2FA
- Terminate TLS safely with Nginx Proxy Manager
- Route Listmonk behind Traefik as your reverse proxy
- Use Supabase as the backend that feeds Listmonk your subscriber data
26. Bottom Line
Listmonk is the most pragmatic way to escape the per-subscriber tax without surrendering your audience's data to a vendor. A single Go binary plus PostgreSQL gives you unlimited subscribers, transactional messaging, SQL segmentation, and a real templating engine for a compute cost measured in single-digit dollars a month — and your sending bill is just the SMTP relay, not a percentage of your list size. The trade is operational: deliverability, DNS authentication, database backups, and the AGPL network clause are all squarely on you, and the project's bus factor is one maintainer. For engineers and technically confident operators who value data sovereignty, it is close to the ideal self-hosted newsletter engine. For everyone else, the "free" software has a carrying cost in time that a SaaS quietly absorbs. Know which camp you are in before you point your MX records at it.
Comments (0)
No comments yet. Be the first to comment!