Should I vibe code
Hosted RSS and newsletter reader with search and filtering
Feedbin is open source, and its own README tells you not to self-host it. Read that before you write a line.
?
Their verdict, the Standard price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
Start with the unusual fact: Feedbin is MIT-licensed and the whole application is on GitHub, so the real thing is already yours. Then read its README, where the author writes that being a great hosted service is at odds with being a great self-hosted one, says he does not recommend running it in production unless you have plenty of time to configure it, and points you at yarr, Tiny Tiny RSS and FreshRSS instead. Take him at his word. Run FreshRSS or Miniflux; if you would rather write your own, a poller, a parser and one boolean per article really is an evening, and the export format is a twenty-year-old open standard. The part that is not RSS is the newsletter inbox — Feedbin hands you an address and turns whatever lands there into feed items — and rebuilding that means accepting inbound mail from strangers on your own domain and rendering HTML written by marketing platforms, tracking pixels included. That is the piece to either buy or deliberately leave out.
What actually breaks
not "if". the specific failures.
- The newsletter address, which is an inbound mail endpoint anyone can learn and send anything to — once it leaks you are running a public spam target with an HTML renderer behind it
- Newsletter markup, which is table soup produced by an ESP and carries tracking pixels that phone home the instant you render it without a proxy
- Full-text extraction, which works beautifully until a publisher moves the article body behind JavaScript and your reader quietly needs a browser fleet
- Feed HTML, which is arbitrary markup written by strangers and will eventually push a script tag into whatever renders it
- Search, because a LIKE over three years of stored article text stops feeling instant somewhere in year one — Feedbin runs Elasticsearch for exactly this reason
- GUID churn, where a site changes its id scheme overnight and re-delivers four hundred read articles as unread
- Your patience with the stack, if you clone Feedbin itself: Ruby, Postgres, Redis, Elasticsearch and separate services for extraction and image proxying, with no support offered to self-hosters
Is that you?
the verdict is a default, not a law
- You self-host FreshRSS, Miniflux or yarr and spend the evening on your own client rather than your own backend
- OPML import and export work before the themes do
- Feed and newsletter HTML is sanitised at ingestion, not at render time
- The poller sends conditional requests and backs off, so three hundred small blogs are not subsidising your refresh loop
- Other people read through your instance and you are the only one who can restart it
- You are handing out newsletter addresses on the domain you also use for real mail
- You intend to load remote images directly, which tells every newsletter sender your IP address and your reading times
- You are cloning the Feedbin repo expecting a docker compose up — the README says in as many words that it is not that
If you build it anyway
the checklist, then the prompt that enforces it
- Read Feedbin's README before deciding anything. It is the rare project that names its own limits, recommends three alternatives and links a community Docker build for people who insist anyway.
- Write OPML import and export on day one and round-trip test them. Thirty lines, and the entire reason this category is safe to build.
- Poll politely: If-Modified-Since, If-None-Match, honour 304 without reparsing, exponential backoff on 429 and 5xx, and a User-Agent containing a real contact URL.
- Sanitise every piece of HTML through an allowlist at ingestion and store the sanitised copy. Newsletter markup is the more hostile of the two inputs, not the less.
- If you build the newsletter inbox, treat the address as public. Accept only plus-tagged aliases you registered, rate-limit per sender, cap message size, and never auto-reply to an envelope sender you cannot verify.
- Strip or proxy remote images in newsletters. The pixel is the point of the pixel, and rendering it hands a marketing platform your reading schedule.
- Set a retention policy for stored article text before writing the storage layer, rather than after the disk-full alert.
I want a feed reader for myself. Before writing anything, tell me honestly whether FreshRSS or Miniflux already does this, because self-hosting one of those is the right answer more often than it isn't. If I still want my own, build in this order and argue if I reorder it: 1. OPML import and export first, with a round-trip test. This is my exit, it is cheap today and impossible once the schema drifts. 2. The fetcher's manners second: If-Modified-Since, If-None-Match, honour 304 without reparsing, exponential backoff on 429 and 5xx, a User-Agent with a real contact URL, and a per-feed interval derived from how often that feed actually publishes. 3. Sanitise at ingestion, never at render. Allowlist tags and attributes; drop script, iframe, object, event handlers and javascript: URLs; store only the clean copy. 4. Deduplicate on guid and on a hash of link plus title, so a site that rewrites its ids does not resurrect hundreds of read articles as unread. 5. One malformed feed must never stall the scheduler. Broken XML, lying encodings and redirect chains ending at a parked domain are the normal case, not the edge case. Push back before building the newsletter inbox. If I insist: the address is public the moment it is used anywhere, so accept only aliases I have pre-registered, rate-limit per sender, cap message size, and never auto-reply to a forged envelope. Strip remote images by default and tell me why the pixels are there. Do not build an open image or content proxy. If I ask later, require my session, sign the URL, resolve DNS and reject private and link-local ranges, and refuse cross-host redirects. Out of scope: social scraping, comment fetching, recommendations, sharing. And if I ask you to clone the Feedbin repo instead, read me its README first.
That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
Seven dollars a month is a rounding error against an evening, so nobody is doing this for the money. Pay it if you want the newsletter inbox without operating inbound mail, if you want search across years of full article text without operating Elasticsearch, or if you want the iOS and Android clients that already speak the API. Those three are the product; the reader part is not.
$7/mo is cheaper than your weekend.
OPML, and that is genuinely the whole answer — your subscription list is an open format every reader on earth imports, so abandoning your build costs an afternoon of choosing a replacement. The two things OPML does not carry are read state and stars, so dump those as a CSV keyed on article URL beside it. Newsletters are the exception: if you built the inbox, keep the raw messages as .eml files somewhere ordinary, because no reader imports another reader's newsletter archive.
Feedbin itself, MIT-licensed and complete, with a README that tells you the hosted version is the one you want.
Self-hosted aggregator with multi-user support, a sane polling core and an install you can finish in an evening.
Single-binary feed reader that already gets conditional requests, scraper rules and sanitisation right.
Tiny local-first reader that runs as one process with no database to operate, recommended by Feedbin's own README.
Questions
If Feedbin is open source, why isn't the answer simply "self-host Feedbin"?
Because the author says not to. The README states that being a great hosted service is at odds with being a great self-hosted one, that there are a lot of moving parts, and that he does not recommend running it in production without plenty of time. It wants Ruby, Postgres, Redis and Elasticsearch plus separate services for content extraction and image proxying, and no support is offered for installing it. FreshRSS or Miniflux gets you most of the value for a fraction of the operations.
What is the genuinely risky part of building a reader?
Two things, and neither is the RSS. An open image or content proxy is an SSRF probe pointed at your own network and free bandwidth for whoever finds it. And the newsletter address is an inbound mail endpoint on your domain that anyone can send to once it leaks, which means you are accepting, storing and rendering unsolicited HTML from strangers by design.
Is the newsletter inbox worth seven dollars on its own?
For a lot of people, yes. Rebuilding it means MX records or an inbound webhook, per-sender rate limiting, storage for mail you did not ask for, and a renderer that survives whatever an enterprise ESP considers HTML — plus a proxy so the tracking pixels do not report your reading habits back. That is a weekend you will spend again each time something upstream changes.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
Everything BazQux charges $30 a year for is the part that isn't RSS. The RSS part is an evening.
RSS is a fetch loop with a read flag. The only real work is not being rude to the servers you're polling.
Saving a link is not saving an article. Store the HTML at save time or your archive is a list of 404s.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice