Feedbin: Self-Hosting the Ruby on Rails RSS Reader Behind feedbin.com

What Feedbin's open source repository actually is

Feedbin is a web-based RSS reader. The repository is the Ruby on Rails application behind it, and the README describes two distinct products sitting in the same codebase: a user interface for reading and managing feeds, and a REST-like API hosted in a separate repository, feedbin/feedbin-api, that clients connect to. The hosted service at feedbin.com is the commercial side. That split matters more than it first appears, because the README is explicit that the project's goal of being a great web-based RSS service is at odds with being a great self-hosted RSS reader. The same document says plainly that the author does not recommend running Feedbin in production unless you have plenty of time to get it properly configured.

So the audience is narrow. You are either someone who wants to read the Rails implementation of a feed reader, someone extending it, or someone building a client against the API. If what you want is a working reader on a small VPS tonight, this is not the repository for that, and the README says so before you clone anything.

The Rails core and the optional services around it

The main application is a Rails app, and the README states that none of the additional services are required to get Feedbin running locally. That is the important architectural fact: the extras are separable, and each one covers a specific gap.

Privacy Please is an HTTPS image proxy. In production Feedbin is HTTPS only, and the README explains the consequence: all assets must be served over HTTPS or the browser shows insecure content warnings. The proxy routes image requests through an HTTPS-enabled host, which also hides the reader's IP from the image host. Extract is a Node.js service that pulls the full content of an article when a feed only publishes excerpts. pigo provides face detection for preview image cropping, and must either be on your PATH or pointed at with a PIGO_PATH environment variable.

Configuration is entirely environment variables. The .env.example file separates required settings from optional ones. DATABASE_URL and SECRET_KEY_BASE are the required pair. Redis and Elasticsearch fall back to localhost if REDIS_URL and ELASTICSEARCH_URL are left empty. AWS credentials are needed for file uploads. The unified image store, described in the file as Backblaze B2 behind the S3 API, has its own block of variables, and the comment in .env.example states that production refuses to boot without UNIFIED_BUCKET_IMAGES and UNIFIED_IMAGE_HOST. That is a hard startup gate, not a warning.

Installing Feedbin locally and getting to a first page

The README lists the requirements first: Linux or macOS, Ruby 3.4, Postgres 11, Redis 6 and Elasticsearch 8.5. Install those before touching the repository, because the next step assumes they are reachable.

Clone the repository and install the application dependencies. The README notes that any error after this command means one of the dependencies failed to build on your platform, and that resolving it is your problem:

git clone https://github.com/feedbin/feedbin.git
cd feedbin
bundle

Configuration comes next. The README says to rename .env.example to .env and customize it. At minimum you need the two required values, and the database URL follows the format shown in the example file:

export DATABASE_URL=postgres://username:password@host:port/database
export SECRET_KEY_BASE=a-long-random-string
export RACK_ENV=production
export RAILS_ENV=production

With the environment in place, set up the database and start the processes. The README uses foreman, which reads the Procfile at the repository root:

rake db:setup
bundle exec foreman start

What you should see after foreman start is the processes defined in the Procfile coming up, and the application reachable through your Rack-compatible server. The README does not document a default port, a first-run admin account, or a seed login, so expect to work those out from config/ and db/ rather than from the install guide. The repository also carries package.json with a single lint script for the JavaScript under app/javascript, which is a development convenience rather than a setup step.

Where self-hosting Feedbin breaks down

The most honest limitation is stated by the project itself. The README says no support is provided for installing the open-source project, and directs customers to email [email protected] instead. A self-hoster is outside that channel by definition.

The second limitation is the dependency surface. Postgres, Redis and Elasticsearch are all in the requirements list, and Elasticsearch 8.5 in particular is not a component most people already run. The .env.example also expects object storage for uploads, with separate buckets for archives, favicons, newsletters and icons, plus the unified image store. You can run locally without most of this, since the README says Feedbin will start without most of the variables and simply turn off features, but the moment you want the production-shaped behaviour the README describes, the configuration load grows quickly. The unified bucket gate is the clearest example: production will not boot without it.

There is also a version-pinning cost. Ruby 3.4, Postgres 11 and Elasticsearch 8.5 are the documented targets. If your infrastructure is on different major versions, that is your migration to plan, and the README does not describe an upgrade path or a rollback procedure for any of it.

Feedbin vs Fresh RSS, Tiny Tiny RSS and yarr

The README answers the alternatives question directly, and the answer is not flattering to itself. It names yarr, Tiny Tiny RSS and Fresh RSS as the projects to look at if you want a self-hosted RSS reader. The difference is not a feature checklist; it is what the software was built for.

Feedbin's codebase exists to run a multi-tenant hosted service. That is why it has an API repository alongside it, why uploads go to object storage with separate buckets per asset type, why an image proxy and a separate extraction service exist, and why Elasticsearch sits behind search. Fresh RSS and Tiny Tiny RSS are built the other way around: the self-hoster is the primary user, so the install and the operational surface are shaped around one person running one instance. yarr is smaller still. Choosing Feedbin for a personal reader means paying the multi-tenant tax without the multi-tenant benefit.

The README also points to angristan/feedbin-docker for the whole stack. That is the pragmatic middle path if you want Feedbin specifically and do not want to assemble the services yourself, though it is a separate repository with its own maintenance, not part of this one.

Licence and the cost of keeping up

The repository is MIT licensed. In practical terms that is permissive: you can read it, modify it and run it. It is not legal advice, and the licence file at the repository root is the authority if you need to rely on the terms.

The maintenance picture is more mixed than the licence. The last push to the repository was on 2026-09-13, which is recent. The repository has no published GitHub releases, so there is no tagged version to pin against, and the README does not describe an upgrade procedure. That combination means you track the main branch or you track nothing. For a codebase whose README warns about configuration complexity, an untagged upgrade path is a real operational cost: there is no documented rollback, and the environment variable surface is large enough that a change in .env.example can strand a running instance.

Budget for that before you start. A self-hosted Feedbin is not a set-and-forget install; it is a Rails application with four backing services and a moving main branch.

Editorial conclusion

Adopt Feedbin's codebase if you want to read or extend the Rails application behind a commercial RSS service, or if you need the REST-like API and are prepared to wire up Postgres, Redis, Elasticsearch and object storage yourself. Do not adopt it as a low-effort self-hosted reader: the README states no support is provided for installing the open-source project and recommends yarr, Tiny Tiny RSS or Fresh RSS instead. Before committing, verify that your Postgres, Redis and Elasticsearch versions meet the documented requirements, that UNIFIED_BUCKET_IMAGES and UNIFIED_IMAGE_HOST are set because the .env.example notes production refuses to boot without them, and that you have a plan for the AWS credentials the upload paths expect.

Frequently asked questions

Official sources

1. feedbin/feedbin on GitHub
2. Issues
3. License: MIT
4. Project website
5. README