listmonk: a single-binary newsletter manager that puts PostgreSQL at the center
High performance, self-hosted, newsletter and mailing list manager with a modern dashboard. Single binary app.
At a glance
- What is it?
- listmonk is a self-hosted, AGPL-3.0 newsletter and mailing list manager written in Go, with a Vue frontend and a PostgreSQL data store. The core judgement: it trades the convenience of a managed SaaS for full control over your subscriber data and delivery pipeline, at the cost of running your own database and mail infrastructure.
- Who is it for?
- Adopt listmonk if you want a self-hosted newsletter system with a modern dashboard, a single binary, and full control over your subscriber data and PostgreSQL schema. Skip it if you cannot run your own PostgreSQL instance or if you need a managed service with built-in email deliverability.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What listmonk actually solves
listmonk addresses a specific gap: self-hosted email marketing without a web service dependency. Most newsletter tools are SaaS products where your subscriber list lives on someone else's server. listmonk flips that. You run the binary, you point it at your own PostgreSQL database, and you own the entire stack. The README describes it as a standalone, self-hosted, newsletter and mailing list manager that is packed into a single binary. The target user is an engineer or a small team that already operates servers and wants to avoid per-subscriber fees or vendor lock-in. It is not for a non-technical marketer who expects a hosted dashboard and no infrastructure work. The phrase high performance in the repository description hints at the Go backend, but the README does not quantify any throughput numbers, so treat that as a claim, not a benchmark.
The architecture: one binary, one database, two frontends
The repository layout and README reveal a simple architecture. The backend is written in Go, which compiles to a single static binary. The frontend is Vue with Buefy for UI components. There is no separate API server or worker process mentioned in the material. The binary handles the web dashboard, the subscriber management, and presumably the sending logic, though the README does not detail the sending pipeline. The data store is exclusively PostgreSQL. That is a deliberate choice: it means you need a running PostgreSQL instance, but it also means your subscriber data, campaign lists, and settings live in a standard relational database you can query, back up, and migrate. The README does not mention Redis, queues, or any other external service. That keeps operations simple, but it also means the binary itself must manage any background jobs, which could become a bottleneck at very large subscriber counts. The documentation does not state how listmonk handles concurrent sending or rate limiting, so verify those details before promising high volume to your stakeholders.
Getting it running: two paths, same database step
The README gives two installation routes. The Docker route uses a sample docker-compose.yml. You download it with curl -LO https://github.com/knadh/listmonk/raw/master/docker-compose.yml, then run docker compose up -d. That brings up both listmonk and, presumably, a PostgreSQL container, though the README does not show the compose file contents. You then visit http://localhost:9000. The binary route is more explicit. Download the latest release, extract the listmonk binary, then run ./listmonk --new-config to generate config.toml. You edit that file to set your database connection and other settings. Then run ./listmonk --install to set up the PostgreSQL schema. For an existing installation, you run ./listmonk --upgrade. The README states that upgrades are idempotent and running them multiple times has no side effects. That is a useful property for automation, but it does not tell you what migrations a given upgrade performs. Both routes end with the same step: run the binary and open the dashboard on port 9000. The config file is TOML, not YAML or JSON, which is a small but real detail for people who prefer one format over another.
The AGPL license: a real constraint for some adopters
listmonk is licensed under AGPL-3.0. That is the Affero General Public License, which extends the GPL's copyleft to network services. If you modify listmonk and run it as a service, the license can require you to offer the modified source code to users who interact with the service over a network. The README states the license plainly: listmonk is licensed under the AGPL v3 license. For an internal tool, this may not matter. For a company that distributes a product that embeds listmonk, or offers a hosted newsletter service built on it, the license imposes obligations. This is not legal advice, but it is a fact you should check with your own counsel before adopting. The license also affects how you handle upgrades: if you patch the source, those patches may need to be released under AGPL when you distribute the result. The README does not mention any commercial license or dual licensing, so assume the AGPL applies to all uses unless the project adds other terms.
A genuine limitation: you own the deliverability problem
The README does not mention email deliverability, bounce handling, or SPF/DKIM configuration. That is a significant gap for a newsletter manager. A SaaS tool like Mailchimp handles domain authentication, bounce processing, and reputation monitoring for you. With listmonk, you are responsible for setting up your own SMTP server or integrating with a third-party sending service. The README gives no configuration keys for SMTP, sending limits, or bounce webhooks. The config.toml file you generate with --new-config will contain those settings, but the README does not document them. That means a new user may not know what to fill in. The wrong tool scenario is clear: if you need a plug-and-play email sender with high deliverability out of the box, listmonk is not that. It is a manager, not a sending infrastructure. You must bring your own mail server, or configure an external SMTP relay, and you must monitor your own sending reputation. The documentation does not state how listmonk handles bounces or unsubscribes, so verify those features before relying on them for compliance with anti-spam laws.
Alternatives: the managed route versus the self-hosted route
The obvious alternative is a managed SaaS like Mailchimp or Buttondown. Those services handle deliverability, list cleaning, and analytics for you, but they hold your subscriber data and charge per subscriber or per send. The architectural difference is that listmonk gives you a PostgreSQL table you can query directly, while a SaaS gives you an API and a web UI. Another self-hosted alternative is Mautic, which is a larger marketing automation suite written in PHP. Mautic includes lead scoring, campaigns, and more automation features, but it runs on a web server with PHP and a database, not as a single binary. listmonk's advantage is simplicity: one Go binary, one PostgreSQL database, no PHP runtime. The trade-off is that Mautic has a broader feature set, while listmonk appears focused on newsletters and mailing lists. The README does not mention A/B testing, RSS-to-email, or automation workflows, so if you need those, listmonk may be too lean. The choice comes down to whether you want a narrow, fast tool you can operate yourself or a broader platform with more moving parts and a heavier runtime.
Maintenance and upgrade cost
The maintenance cost for listmonk is moderate, but it is front-loaded. You must run a PostgreSQL server, which means backups, monitoring, and upgrades for that database. The listmonk binary itself is a single file, so upgrading the application is as simple as replacing the binary and running ./listmonk --upgrade. The README states that upgrades are idempotent, which reduces the risk of running the upgrade command twice, but it does not describe what the upgrade process does to your data. You should still back up your database before each upgrade. The nightly release channel exists, but the README does not explain its stability or whether it is suitable for production. The last stable release mentioned is v6.2.0 from June 2026, and v6.1.0 from March 2026, which suggests a roughly quarterly release cadence, but the README does not confirm that. The project is not archived, and the last push was in August 2026, so it is actively maintained. However, the README does not list a changelog or migration notes, so you may need to read release notes on the GitHub releases page to understand what changed between versions. That is a small but real cost: you cannot assume a version jump is backward compatible without checking.
Editorial conclusion
Adopt listmonk if you want a self-hosted newsletter system with a modern dashboard, a single binary, and full control over your subscriber data and PostgreSQL schema. Skip it if you cannot run your own PostgreSQL instance or if you need a managed service with built-in email deliverability. Before adopting, verify that your mail server can handle the sending volume and that you are comfortable with the AGPL-3.0 license, which may require you to release modifications if you distribute them. Also confirm that the upgrade path from your current version to the latest release is documented, since the README only says upgrades are idempotent, not what changed between versions.
Community notes