Stringer

Self-hosted RSS, honestly reviewed. No marketing fluff — just what you get when you deploy it.

TL;DR

• What it is: A self-hosted, MIT-licensed RSS reader built in Ruby on Rails. It calls itself “anti-social” — no sharing, no recommendations, no algorithms. Just feeds [README].
• Who it’s for: People who read RSS for themselves, want zero reliance on any third-party service, and are comfortable deploying a Rails/PostgreSQL app [1][2].
• Cost savings: Feedly Pro runs $8.25/mo, Inoreader starts at $7.99/mo. Stringer self-hosted costs whatever a small VPS costs — $4–6/mo — with no per-user or per-feed pricing.
• Key strength: Radically simple. No social layer, no algorithm, no dark patterns. The tool gets out of your way [README][1].
• Key weakness: It is genuinely minimal — no mobile apps, no read-it-later integration, no Google Reader API (only Fever API for mobile). The project is also in maintenance mode more than active development. If you want a full-featured RSS platform, look elsewhere [3].

---

What is Stringer

Stringer is a self-hosted RSS reader that was built around a single design decision: subtract everything. No external service dependencies. No social graph. No “recommended for you” feed. No machine learning. Just you and your subscriptions [README].

The project was created by Matt Swanson and is currently maintained by Robert Fletcher. It sits at 4,109 GitHub stars — a respectable number for a tool this narrow in scope. The license is MIT with no strings attached [README].

Under the hood, Stringer is a Ruby on Rails application backed by PostgreSQL. The frontend uses Backbone.js and Bootstrap/Flat UI. Feed fetching is handled by feedjira and feedbag — mature Ruby libraries that do the parsing work. Background jobs run on GoodJob, a PostgreSQL-backed async job processor, which keeps the infrastructure footprint tight: you need a server, Ruby, and PostgreSQL, and that’s it [README].

When Google Reader shut down in 2013, a lot of RSS-dependent people went scrambling. Stringer was one of the tools that emerged in that window. A 2013 Torque Mag post [2] described the appeal clearly: “I like the idea of having my own system so that I never have to worry about another system being down or being sunset.” That’s still the pitch in 2026, just with better deployment tooling.

---

Why people choose it

The honest answer is that almost all available third-party writing on Stringer dates from 2013, when it was new [2]. The LinuxLinks listing [1] is a brief catalog entry. The only comparison context in the reviews is from a blogger who evaluated self-hosted feed readers and picked Miniflux instead [3]. There are no current in-depth breakdowns of Stringer the way you’d find for n8n or Nextcloud.

That absence is itself informative. Stringer isn’t getting new reviews because it’s not changing much. It’s not a product with a roadmap and a growth team — it’s a tool that does a specific job and has been doing it the same way for over a decade. The people who use it tend to set it up and leave it running without writing blog posts about it.

What draws people to Stringer versus the alternatives:

Versus Feedly, Inoreader, NewsBlur (commercial SaaS). The argument is straightforward: you stop paying a monthly fee, your data lives on your server, and the service can’t be acquired or shut down under you. As the Torque Mag author [2] put it in 2013, the appeal of RSS is durability, and cloud readers keep dying. Stringer self-hosted solves that permanently.

Versus FreshRSS. FreshRSS is the other major self-hosted RSS option. It supports Google Reader API, has more features (filters, labels, statistics, multi-user), and has a larger active contributor base. Stringer trades all of that for simplicity. FreshRSS is the tool for people who want a full RSS management system; Stringer is the tool for people who want just enough.

Versus Miniflux. Miniflux won out in the one comparison review we found [3]. The author chose it specifically because it supports the Google Reader API — which means you can connect it to the Reeder iOS app and other clients. Stringer uses Fever API instead, which has a smaller set of compatible clients. If mobile client compatibility matters to you, this is a real constraint.

Versus running a local RSS app. Before cloud readers, people ran desktop apps like NetNewsWire or Vienna. The argument for Stringer over a local app is that your read state syncs across devices and the fetching happens server-side — you don’t miss items when your laptop is closed.

---

Features

Stringer is deliberately short on features. Here’s what it actually includes, based on the README:

Core reading experience:

• Subscribe to any RSS or Atom feed
• Mark as read, star items for later
• Keyboard shortcuts for navigation (press ? to see the full list) [README]
• Clean reading view — no ads, no promoted content, no algorithmic re-ordering

Fever API:

• Stringer implements a clone of the Fever API, originally from a defunct paid product [README]
• This allows you to use any mobile client that supports Fever — Reeder (iOS) is the most common, but support for Fever in modern clients is narrowing as Google Reader API has become more standard
• Connection settings: Server at {your-url}/fever, email stringer, password = your Stringer password [README]

Storage cleanup:

• rake cleanup_old_stories removes read stories older than 30 days that aren’t starred [README]
• Default threshold is 30 days, configurable
• Can be scheduled as a cron job to run automatically

Internationalization:

• Translated into several languages via LocaleApp [README]
• Set language via the LOCALE environment variable
• On Heroku: heroku config:set LOCALE=en

Deployment options:

• One-click Heroku deploy button (Eco/Basic plan is sufficient) [README]
• Manual Heroku, Linux VPS, Docker, OpenShift — documented in /docs/ [README]
• PostgreSQL required; no alternative database support

What it doesn’t have:

• No native mobile app — mobile access is through the browser or Fever API clients
• No read-it-later integration (no Pocket/Instapaper built-in)
• No tag/label system
• No multi-user support
• No Google Reader API (only Fever)
• No full-text search across articles
• No filters or keyword blocking (Miniflux and FreshRSS have this)
• No statistics or usage dashboards

That’s not a complaint — it’s a description. Stringer is what it says it is.

---

Pricing: SaaS vs self-hosted math

Stringer has no managed cloud tier. There’s no paid version, no hosted option, no freemium model. It’s self-host only [README].

What self-hosting Stringer costs:

• Software: $0 (MIT license)
• Heroku Eco/Basic dyno: ~$5–7/month (limited free tier exists but sleep after inactivity) [README]
• Hetzner or Contabo VPS (if running other services too): $4–6/month
• Your domain if you want a clean URL: ~$10–12/year

What commercial RSS readers cost:

• Feedly Free: 3 feeds, limited to 100 articles — not really usable
• Feedly Pro: $8.25/mo (billed annually) — unlimited feeds, no AI features
• Feedly Pro+: $12.50/mo — adds AI summaries and keyword alerts
• Inoreader Supporter: $7.99/mo — active feeds, no ads, rules
• Inoreader Patron: $14.99/mo — full rule engine, filters, bundles
• NewsBlur: $36/year (~$3/mo) — one of the cheaper paid options
• Miniflux hosted: $15/year (~$1.25/mo) — cheapest managed option if you want full-featured

Concrete math for a typical power RSS reader:

If you’re on Feedly Pro at $8.25/mo, that’s $99/year. Self-hosting Stringer on a $5 VPS: $60/year. If you’re already running a VPS for other services, Stringer adds essentially zero marginal cost — it shares the server.

Over three years: Feedly Pro ≈ $297. Stringer on shared VPS ≈ $0 incremental. That $300 difference is real, but it’s not the main reason people choose Stringer. The main reason is data ownership and service continuity, not the money.

One honest caveat: Miniflux’s hosted option at $15/year is remarkably cheap for a more feature-complete reader. If cost is the primary driver, Miniflux hosted is harder to beat than Stringer self-hosted.

---

Deployment reality check

Stringer offers four documented paths: Heroku (one-click), manual Heroku, Linux VPS, Docker, and OpenShift [README]. The Heroku one-click is genuinely one-click — the repo has a app.json that provisions everything automatically. Heroku’s free tier is gone, but the Eco dyno tier is cheap enough that it’s still a reasonable starting point [2].

For a Linux VPS with Docker:

You need:

• A Linux VPS (any $4–6/mo box works — Stringer is lightweight by modern standards)
• Docker and docker-compose
• PostgreSQL (can be a container)
• A reverse proxy (Caddy or nginx) for HTTPS
• A domain or subdomain

The Docker path is documented in /docs/Docker.md in the repo. There’s no official Docker Compose file in the main repo, but community-maintained examples exist on GitHub.

What can go sideways:

The main risk with Stringer is the technology stack, not the installation difficulty. It’s a Ruby on Rails app, and most small VPS owners running self-hosted software use Docker images or Go/Node binaries. If something breaks in the Ruby layer — a gem version conflict, a Rails update — debugging it requires some familiarity with the Ruby ecosystem. This is not a problem for the Ruby crowd but it’s worth knowing if you’re coming from an all-container background.

The Fever API is also aging out. Modern RSS clients are increasingly moving to the Google Reader API or Miniflux’s native API. If you’re buying into Stringer for mobile access, check that your client of choice still supports Fever before committing [README][3].

The project’s activity level is worth acknowledging. The CircleCI badge in the README links to active CI, and Robert Fletcher is listed as maintainer, but GitHub stars peaked and the issue/PR throughput is slow. This isn’t a project that ships breaking changes, but it’s also not one that ships new features. Budget accordingly for a tool in maintenance mode rather than active growth.

Realistic setup time:

• Technical user with Docker experience: 30–45 minutes to a working instance
• Ruby developer: 20 minutes
• Non-technical founder following a guide: 2–3 hours for a VPS install; 15 minutes for Heroku one-click if you have an account

---

Pros and cons

Pros

• MIT license, no conditions. Self-host, fork, embed, use commercially. No open-core trap [README].
• Zero external dependencies. No third-party service can break it. Once it’s running, it runs until you turn it off [README][1].
• Anti-algorithm, anti-social by design. RSS in chronological order. No vendor deciding what you see. This is a genuine feature for people who are done with algorithmic feeds [README][2].
• Keyboard-driven. Full keyboard shortcut set — readable by pressing ?. Makes power reading fast [README].
• Fever API. Compatible with a subset of mobile clients, mostly Reeder [README].
• Heroku one-click deploy. Lower barrier to entry than most Ruby apps [README][2].
• Multi-language. Several locale translations maintained via LocaleApp [README].
• Minimal resource footprint. Runs fine on Heroku Eco or a small shared VPS [README][2].

Cons

• Fever API only, no Google Reader API. The Google Reader API has become the standard for self-hosted RSS mobile access. Miniflux and FreshRSS support it; Stringer doesn’t. This narrows the compatible mobile client list [3].
• No search. There’s no way to search your article history. You either remember which feed published something or you don’t [README, by absence].
• No filters or keyword blocking. Can’t suppress content from a feed based on keywords. Miniflux has regex-based blacklisting. Stringer doesn’t [3].
• Single-user only. No multi-user support. Fine for personal use, a problem if you want to share an instance with a household or team [README, by absence].
• Ruby stack maintenance overhead. Dependencies require periodic updates. Not onerous for a Ruby developer, but unfamiliar territory for most self-hosting newcomers [README].
• Low development velocity. New features aren’t coming. Open issues tend to stay open. If you find a bug, the fix timeline is uncertain [GitHub activity].
• No native mobile app. Mobile reading goes through the browser (fine) or Fever-compatible clients (narrowing set) [README].
• No read-it-later or annotation integration. No built-in Pocket/Instapaper support. If that workflow matters to you, it’s a manual step [README, by absence].

---

Who should use this / who shouldn’t

Use Stringer if:

• You currently pay for Feedly, Inoreader, or NewsBlur and want to stop the monthly bill without losing RSS access.
• You have 20–50 feeds and read everything in chronological order. You don’t want recommendations, trending stories, or any kind of curation layer.
• You’re comfortable on Heroku (or Docker) and can do a one-time deploy without hand-holding.
• Your primary reading device is a browser, not a dedicated iOS RSS app.
• You want the simplest self-hosted RSS option that will run without maintenance for years.

Skip it (use Miniflux instead) if:

• You need mobile access via the Google Reader API or want to use Reeder, NetNewsWire, or other modern iOS/Android clients.
• You need keyword filters or feed rules.
• You want a more actively maintained project.
• You want a hosted option at $15/year rather than self-hosting.

Skip it (use FreshRSS instead) if:

• You need multi-user support for a household or team.
• You want full-text article search.
• You need statistics, labels, and a more complete feed management system.
• You run a PHP/LAMP stack and a Ruby app doesn’t fit your setup.

Stay on commercial SaaS if:

• You’ve never managed a VPS and don’t want to start.
• You need iOS/Android apps with offline reading, sync, and push notifications — that’s still Feedly Pro or Inoreader territory.
• You rely on Feedly’s AI digest or newsletter features.

---

Alternatives worth considering

• Miniflux — the strongest direct alternative. Go binary, fast, PostgreSQL, supports Google Reader API for mobile clients, actively maintained. Hosted option at $15/year. Self-hosted on Docker in minutes. Roger Stringer chose it over Stringer specifically for Google Reader API compatibility [3]. If you’re comparing these two, start with Miniflux.
• FreshRSS — PHP-based, full-featured, multi-user, active development, supports Google Reader API and several others. More complex to configure but significantly more capable. Good choice for a household or small team.
• NewsBlur — open source and has a paid hosted option (~$36/year). Has a social layer (which you can ignore) and more features than Stringer. The self-hosted version requires more infrastructure than Stringer.
• Tiny Tiny RSS (TT-RSS) — PHP-based, long-running project, feature-complete but known for a historically difficult maintainer relationship with the community. It works, but read the GitHub issues before committing.
• Feedly Pro — the commercial incumbent at $8.25/mo. Best if you need reliable mobile clients, AI digests, and zero server administration.
• Inoreader — more powerful feed rule engine than Feedly, comparable pricing. Commercial only.

For a non-technical founder evaluating self-hosted RSS, the realistic shortlist is Miniflux vs FreshRSS. Stringer fits a narrower use case: someone who wants the absolute minimum viable RSS reader and is fine with Fever API or browser-only reading.

---

Bottom line

Stringer is exactly what it says it is: an anti-social RSS reader with no external dependencies, no social layer, and no pretension to be more than a feed reader. It’s been running in production for over a decade, which in the self-hosted tool world counts for something. The MIT license is clean, the Heroku deploy is genuinely one-click, and once it’s running you’ll likely never think about it again.

The honest limitation is that the self-hosted RSS category has evolved since 2013. Miniflux and FreshRSS are both more actively maintained, support the Google Reader API (which matters for mobile client compatibility), and have more features without much more complexity. For most people starting fresh, one of those two is the better default. Stringer earns its place for the reader who specifically wants nothing extra — no filters, no recommendations, no machine learning, no social features — and just needs their feeds delivered cleanly on a server they own.

If deploying a Rails app is the blocker, that’s exactly the kind of setup task that upready.dev handles for clients. One-time fee, running in production, done.

---

Sources

1. LinuxLinks — Stringer: self-hosted, anti-social RSS reader (catalog entry). https://www.linuxlinks.com/stringer-self-hosted-anti-social-rss-reader/
2. Torque Mag — Stringer: Open Source Self-Hosted RSS Reader (May 2013). https://torquemag.io/2013/05/stringer-reader/
3. Roger Stringer — Picking a self-hosted Feed Reader (chose Miniflux over Stringer, Google Reader API as deciding factor). https://rogerstringer.com/blog/picking-a-self-hosted-feed-reader/

Primary sources:

• GitHub repository and README: https://github.com/stringer-rss/stringer (4,109 stars, MIT license)
• Deployment documentation: https://github.com/stringer-rss/stringer/tree/main/docs