LetterFeed

Self-hosted newsletter-to-RSS bridge, honestly reviewed. No marketing fluff, just what you get when you run it yourself.

TL;DR

• What it is: A self-hosted application that monitors your existing email inbox via IMAP and converts newsletters from configured senders into RSS feeds [2].
• Who it’s for: RSS-first readers who want to consume newsletters in a feed reader without changing subscription addresses or trusting a third-party hosted service.
• Cost: Free (MIT license). A VPS to run it on costs $5–10/month; if you’re already running Docker somewhere, it adds essentially zero marginal cost.
• Key strength: Works with your existing inbox. Unlike Kill-the-Newsletter and similar tools, you don’t re-subscribe to newsletters with a new email address — LetterFeed reads the mailbox you already have [1].
• Key weakness: Very early-stage project. 184 stars, 6 releases, single developer. No third-party reviews exist at the time of writing, documentation is thin, and you’re mostly on your own if something breaks.

---

What is LetterFeed

LetterFeed is a small, focused tool that does exactly one thing: it periodically scans your email inbox via IMAP, finds new emails from senders you’ve configured, and adds them as entries to per-newsletter RSS feeds [2]. You run it alongside an RSS reader. The newsletters you already receive start showing up in your feed reader, in chronological order, without any algorithm deciding what to surface.

The project lives at https://github.com/LeonMusCoden/LetterFeed. At the time of this review: 184 stars, 10 forks, 6 releases (latest v0.5.0, September 2025), and 67 commits. The codebase is Python backend (51.4%) and TypeScript frontend (43.8%), deployed via Docker Compose. MIT license. It appears to be built and maintained by a single developer, LeonMusCoden.

The core problem it solves: you’ve subscribed to newsletters over years, your inbox contains them, and you’d rather read everything in a distraction-free RSS reader. Re-subscribing 30+ newsletters with a new address is painful. Some authors gate content behind the original subscriber address. Email clients are noisy. LetterFeed doesn’t ask you to change anything about your subscriptions — it connects to your existing inbox and does the work [2].

---

Why people choose it

Third-party reviews of LetterFeed are essentially nonexistent. What there is: a “Content Spotlight” mention in Self-Host Weekly in July 2025, which introduced the project to a broader audience for the first time [1]. That mention is brief but lands on the key differentiation: “Unlike existing alternatives like Kill-the-Newsletter, LetterFeed configures itself to scan existing e-mail accounts for new mail based on user-defined rules and provides a corresponding RSS feed for each configuration (a single feed can contain any number of e-mail senders)” [1].

That sentence contains the entire value proposition. Kill-the-Newsletter, the best-known hosted alternative, creates a special @kill-the-newsletter.com address per newsletter — you re-subscribe to each newsletter using that address, and the service converts incoming mail to RSS. It works, but you have to either re-subscribe to everything or set up per-sender forwarding rules in your current inbox. For someone with 20+ active newsletters, neither option is appealing.

LetterFeed’s IMAP-scan approach sidesteps the re-subscription problem entirely. You hand it your email credentials, tell it which senders to watch, and it finds the newsletters already arriving in your inbox [2]. No forwarding rules, no new addresses, no migration.

The trade-off embedded in this design: LetterFeed holds your email credentials. Your IMAP password (or app password) lives in a .env file on your server. For self-hosters who are already comfortable running services with access to sensitive accounts, this is a familiar risk model. For everyone else, it’s worth sitting with before deploying.

---

Features

Based on the README and repository structure [2]:

Core function:

• Connects to any standard IMAP-over-SSL mailbox (port 993) — Gmail, Fastmail, Proton Mail via Bridge, or any conventional provider
• Periodically scans the inbox for new emails from configured senders
• Generates one RSS feed per configured newsletter; a single configuration can aggregate multiple senders into one feed [1]
• Web UI for managing newsletter configurations
• Settings available via environment variables or UI; settings set in .env are locked in the UI (preventing accidental runtime overrides)

Deployment:

• Docker Compose, two containers: frontend and backend [2]
• Development Docker Compose file included (docker-compose.dev.yml) alongside the production one
• All IMAP credentials, processing settings, and auth are configured via environment variables [2]

What the documentation doesn’t cover:

• Polling interval / whether it’s configurable
• Whether HTML is preserved, stripped, or rendered in the RSS output
• Database technology behind feed storage
• Behavior under error conditions (credential expiry, IMAP rate limiting, large inbox backlogs)
• Resource requirements

For v0.5.0 with 67 commits, documentation gaps are expected. The README covers the install path clearly and not much else.

---

Pricing: SaaS vs self-hosted math

LetterFeed has no SaaS version. It’s self-hosted only, MIT license, no paid tiers. The cost is whatever your server costs.

The relevant comparison is against hosted alternatives that solve the same problem:

Kill-the-Newsletter — free, hosted, zero infrastructure. Creates a new email address per newsletter. Long-running, widely used. You don’t control the uptime or long-term availability — it’s a maintained side project, not a company-backed service.

Feedbin — $5/month. Paid RSS reader with email newsletter ingestion built in. You get a Feedbin-specific address, subscribe to newsletters with it, and read everything in Feedbin’s polished interface. Closed source, hosted, stable.

Inoreader — freemium, $7.99/month for Pro. Newsletter import at paid tiers. Hosted, closed source.

Self-hosting LetterFeed on a cheap VPS: $5–6/month on Hetzner, Contabo, or DigitalOcean for a server that will run the two Docker containers alongside other services you’re already running. If you’re already paying for a VPS, LetterFeed adds zero marginal cost.

The honest framing: if you want free and hosted with no server, Kill-the-Newsletter works and you don’t need to manage anything. If you want full control over your inbox data, self-hosting LetterFeed is the right call. If you want a polished integrated RSS experience with newsletter support, Feedbin at $5/month is substantially more mature than anything you’ll self-host today.

Over a year: Feedbin ≈ $60. Kill-the-Newsletter ≈ $0 but externally hosted. LetterFeed on a $6 VPS ≈ $72 (or $0 if you’re already paying for a VPS for other reasons).

---

Deployment reality check

The README’s install path is four steps: clone the repo, copy .env.example to .env, edit the file, run docker compose up -d [2]. That’s everything.

What you actually need:

• A Linux server or VPS with Docker and Docker Compose installed
• An IMAP-capable email account with SSL on port 993
• An app password if using Gmail (Google blocks direct password auth by default)
• A domain name and reverse proxy (Caddy or nginx) if you want HTTPS and external access to the web UI

What can go sideways:

The README doesn’t document what to do when IMAP credentials expire — a common scenario with app passwords that have rotation policies. It also doesn’t cover what happens if the backend container loses connectivity to the inbox mid-scan, or how to restore data from a backup.

The presence of .github/workflows (CI pipeline) and .pre-commit-config.yaml (linting/formatting checks) in the repository is a good signal: the developer is following reasonable software hygiene, not just throwing scripts on GitHub [2]. The GEMINI.md file in the root is unusual — it suggests AI-assisted development workflow, not a concern for users but worth noting as a data point about the project’s style.

There are no community tutorials for LetterFeed at this writing. No blog posts, no video walkthroughs. If you hit a problem, you’re reading the Python source or filing a GitHub issue.

Realistic time estimates:

• Technical user comfortable with Docker: 20–30 minutes to a working instance
• Non-technical user: not currently viable without a guide that doesn’t yet exist

---

Pros and cons

Pros

• Works with your existing inbox. The core differentiator. You don’t re-subscribe anywhere or set up forwarding rules. Newsletters you already receive become RSS entries [1][2].
• MIT license. Audit the code, fork it, modify it — no commercial restrictions [2].
• Zero marginal cost if you’re already running a VPS. Two lightweight Docker containers.
• Multi-sender feeds. Group multiple senders into one feed — useful for newsletters from the same author across different sending addresses [1].
• Two-tier config (env vars + UI). Settings locked via .env can’t be overridden through the UI, a sensible self-hosting guardrail [2].
• Active enough to matter. Six releases in a reasonable time window; the developer is iterating, not abandoning.

Cons

• Very young and small. 184 stars, 67 commits, solo developer. No ecosystem, no community forum, no tutorials [2]. This could be abandoned without warning.
• Requires handing over email credentials. Your IMAP password sits in a .env file on your server, accessible to the running container. No architecture eliminates this for IMAP-based approaches, but it deserves explicit acknowledgment before deploying.
• Documentation is thin. The README covers the happy path. Edge cases, error recovery, backup procedures, and resource guidance are absent [2].
• No third-party validation. One newsletter mention [1] and a GitHub page is the entire public record of this tool’s existence. You can’t cross-reference reviews or check user experiences in community forums.
• Unclear data persistence story. No documentation on what database stores feed entries, where data lives inside containers, or how to back it up.
• No hosted fallback. If you can’t run Docker, there’s nothing to try. Kill-the-Newsletter requires no setup at all.

---

Who should use this / who shouldn’t

Use LetterFeed if:

• You already have a self-hosted server running Docker and want to add newsletter-to-RSS without spinning up new infrastructure
• You want to pull from your existing inbox rather than manage new subscription addresses for dozens of newsletters
• You’re comfortable with MIT-licensed early-stage software and the trust model of IMAP credential storage
• You read primarily via RSS and email newsletters are cluttering your inbox

Skip it (use Kill-the-Newsletter instead) if:

• You don’t want to manage infrastructure at all
• You’re fine with a new email address per newsletter
• You want something with years of production use behind it

Skip it (use Feedbin instead) if:

• You want an integrated RSS reader plus newsletter ingestion in one product
• You’re willing to pay $5/month for something polished that works without server management
• You need reliability backed by a company

Skip it entirely if:

• You’re not technical and don’t have someone who can deploy Docker containers — there are no user-friendly guides for this tool yet, and the README will not carry you through a first Linux server setup

---

Alternatives worth considering

• Kill-the-Newsletter (https://kill-the-newsletter.com) — the direct comparison. Hosted, free, no infrastructure. Creates a new email address per newsletter. Has been running reliably for years. Source code is open [1].
• Feedbin — paid RSS reader ($5/mo) with newsletter ingestion built in. Polished, stable, hosted. Not self-hosted.
• Inoreader — freemium RSS reader with newsletter import at paid tiers. Hosted, closed source.
• FreshRSS (https://freshrss.org) — self-hosted RSS aggregator. Doesn’t do email-to-RSS natively, but would consume feeds produced by LetterFeed.
• Miniflux — minimal self-hosted RSS reader. Same relationship to LetterFeed as FreshRSS — consumes the feeds, doesn’t replace the email ingestion.
• RSS-Bridge (https://github.com/RSS-Bridge/rss-bridge) — generates RSS feeds from sites that don’t offer them. Adjacent use case; doesn’t do email newsletters.
• Huginn — more capable self-hosted agent platform that can be configured to do email-to-RSS among many other things. Much heavier to deploy and configure; overkill for this specific use case.

The practical short list is LetterFeed vs Kill-the-Newsletter: one requires a Docker server and your email credentials; the other requires a new subscription address per newsletter but zero infrastructure. Pick based on which constraint is harder for you to live with.

---

Bottom line

LetterFeed solves a specific, real problem with the right architecture: you have newsletters already arriving in your inbox, you want to read them in an RSS reader, and you don’t want to re-subscribe to forty things with a new address. Scanning via IMAP is the correct approach for that use case, and the tool is functional enough to deploy today.

The honest caveat is that this is an early-stage, solo-developer project at v0.5.0 with minimal documentation and no community around it yet. Kill-the-Newsletter has been running for years with a track record LetterFeed hasn’t had time to build. If you need something battle-tested with troubleshooting guides and a community forum, Kill-the-Newsletter or Feedbin are safer bets. If you’re comfortable with early open-source software, already running Docker on a VPS, and want full control over your inbox data pipeline, LetterFeed is worth a twenty-minute setup.

---

Sources

1. Ethan Sholly, Self-Host Weekly — “Self-Host Weekly (25 July 2025) — Content Spotlight: LetterFeed” — selfh.st. https://selfh.st/weekly/2025-07-25/
2. GitHub Repository — LeonMusCoden/LetterFeed — “Convert email newsletters into RSS feeds” — github.com. https://github.com/LeonMusCoden/letterfeed