rssbox: turning YouTube, Twitch and SoundCloud channels into ordinary RSS feeds

One URL per channel, and the reader never learns it was an API

The premise is stated in a single sentence: the app uses the API of other websites and gives you an RSS feed in return. Quick and simple, as the project puts it.

What that buys you is the reason the project exists. A feed reader like this can poll a channel on a schedule and treat it like any other source, so you can follow a creator without opening their site, and you can keep the subscription in a reader that you control rather than in an algorithm.

The repository topics give the shape of the supported set: atom feed, dailymotion, imgur, mixcloud, soundcloud, twitch, vimeo, youtube, elasticbeanstalk and webapp. The topic list is more than a keyword set, because each entry represents a separate API integration with its own credential and its own failure modes.

The Ruby implementation is visible in the layout. There is an `app.rb` and an `app/` directory, `config.ru` for the Rack entry point, `views/` for the templates, `public/` for static files, `lib/` for the library code, a `Gemfile` and `Gemfile.lock`, a `Rakefile`, a `Procfile` for platforms that expect one, and a `Caddyfile` for the reverse proxy in front of the app.

The project is AGPL-3.0 licensed with the LICENSE file at the root, and it maintains a public list of instances in a GitHub discussion, which is a deliberate choice: the point of the project is that anyone can run one and the community can point to a working public instance rather than making everyone deploy their own.

API keys decide what you can actually read

The configuration model is the part to understand first, because it determines what the app does the moment you start it.

The environment example states the rule: if the key is not defined, then all services are enabled by default, and services that require API keys are not enabled unless their keys are defined. So the app starts with everything keyless turned on, and the keyed services appear only when you supply their credentials.

The services that work without any keys are Instagram, Mixcloud, Speedrun and Dailymotion.

The rest need a specific credential each, and the README walks through obtaining them. For YouTube you create a project in the Google Developer Console, make a server key and enable the YouTube Data API v3. For Vimeo you create an app on the Vimeo developer site and then a personal access token. For SoundCloud you open a support ticket to create an app and copy the client id and secret. For Twitch you create an app in your Twitch settings and copy the client id, plus a separate client id if you want to download Twitch videos. For Imgur you create an app in your account settings and copy the client id.

Instagram also has an `INSTAGRAM_SESSIONID` variable rather than an API key, which tells you the integration works off a logged-in session rather than an official API.

The consequence is that the feature set of your instance is exactly the set of keys you hold. The ENABLED_SERVICES variable lets you narrow it further, listing services explicitly.

One caveat worth stating plainly, because the project notes state it in a warning box: the Instagram integration is not being maintained and may not work very well at all.

Facebook is the hole in the list, and the README says why

Facebook was supported in the past, but the author has been unable to obtain API access since the platform locked it down in 2018. The project notes suggest it might be rebuilt some day, possibly using scraping techniques, and links to a discussion on issue 5.

That entry is the most useful thing in the configuration documentation, because it tells you what this class of tool runs into generally. Every integration here depends on an API that a platform owner controls. When that owner changes the terms, the integration stops, and no amount of configuration fixes it. The same applies to the Instagram situation, where the answer was a session id rather than an API key.

The repository also links a separate project for opening `vlc://` links, which is how the generated feed can hand a media item to a desktop player rather than to the browser. That is a small thing but it tells you the audience: people who want to hand a feed to a media player on their own machine.

The service list in the topics also includes platforms with unusual shapes, such as Speedrun and SVT Play, which is a sign the goal is broad coverage of what a feed reader might reasonably want to follow, not a polished product with a narrow, well supported scope.

Docker, Fly, Elastic Beanstalk and Kubernetes are all first class

The deployment story is unusually wide for a small project, and the repository layout shows four separate paths.

Docker is the base. There is a Dockerfile at the root and an image published to Docker Hub and to Amazon ECR. The build is a two stage Ruby build: the builder stage starts from `ruby:4.0`, copies only the Gemfile and lock file, and runs bundle install with the deployment config set and without the development and test groups. The runtime stage is `ruby:4.0-slim` with jemalloc and a few runtime libraries.

The compose file gives you the whole local stack. The `web` service builds from the current directory, sets `PORT=3000` and `REDIS_URL=redis://redis:6379/3`, and publishes port 3000. Redis runs as a separate service on the backend network. Prometheus and Grafana sit on a second network behind the `monitoring` profile, so they do not start unless you ask for them with that profile, and Grafana is reachable on port 3001 with the admin/admin login described in the comment.

The Dockerfile comments also document the operational commands you would expect: pulling and running the image, running the console entry point with `bin/cons`, creating a Docker network and running Redis alongside with appendonly enabled, and monitoring Redis with redis-cli. There are also lines for verifying jemalloc and verifying YJIT through RUBYOPT, which tells you the performance configuration is a deliberate part of the image rather than an accident.

Beyond Docker there are the platform specific paths: `.ebextensions/README.md` for Elastic Beanstalk, `kubernetes/README.md` for Kubernetes, `fly.toml` for Fly, and the `Procfile` for platforms that use one. The recent release tags are named `fly/v59`, `fly/v58` and `fly/v57`, which suggests Fly is where deployment happens most often.

Redis is optional, and it is only for URL resolution

The project notes make a point that is easy to miss: Redis is an optional dependency, and it is used only for the URL resolution feature.

That is a genuinely useful architectural choice for a feed proxy. URL resolution in this context means the app follows a redirect chain to find where the media actually lives, and doing that repeatedly for the same URL is wasteful. With Redis, the resolved URL can be cached and shared across requests and across workers. Without it, the feature is degraded or unavailable, but the core feed generation still works.

The compose file reflects that, because Redis is declared as a service the web container depends on, while the environment file marks the URL as optional with the REDIS_URL line commented out by default. The .env.example also carries a commented `CACHE_DIR=/tmp/rssbox/cache`, which suggests a filesystem cache exists as a fallback for the same purpose.

The rest of the environment file is worth reading as a configuration map. There are performance knobs such as MALLOC_ARENA_MAX, WEB_CONCURRENCY, MIN_THREADS and MAX_THREADS, a URL_MAX_CONCURRENCY, and RESTART_APP_INTERVAL, which suggests the process recycles itself periodically to bound memory growth. There is CSRF protection, enabled by default and switched off with `CSRF_PROTECTION=off`, and a `CSP_REPORT_URI` for content security policy violation reporting. Google Webmaster Tools verification is supported through a token file, and both Airbrake and New Relic are wired in for error reporting and monitoring.

The mix of a modern Ruby release, jemalloc, YJIT and a recycle interval tells you the author treats this as a long-running service that has to stay healthy, not as a script.

Where rssbox does not reach

The honest limitations are all in the same place, the boundary of what the upstream APIs allow.

Facebook is unsupported and there is no workaround short of scraping, which the README floats as a possibility rather than a plan. Instagram is described as unmaintained and possibly not working at all. Any service whose API terms change can stop working between one deploy and the next, and you would have to notice and fix it yourself, because there is no hosted version to hand that problem to.

The second limitation is that rssbox is a feed generator, not a reader. It gives you RSS; what you do with it, whether that is a reader on your own machine, a podcast client, or a script, is out of scope. If the problem is that you want one place to see everything, this is not that tool, and combining it with a reader is the intended usage rather than a workaround.

The alternative approach is worth naming: subscribing to the channels natively in each platform's own app or notification system. The difference in approach is that rssbox centralises the polling and the presentation into a format you control, and it lets you put everything into one reader and one workflow, at the cost of depending on third party API access that you do not control and that can be withdrawn.

On maintenance, the repository is not archived and the last push was on 2026-07-15, and the project version in the package metadata is 2.0.0 for the Ruby app itself.

Editorial conclusion

Adopt rssbox if you want a self hosted feed reader source for channels on YouTube, Vimeo, Twitch, SoundCloud and the other supported sites, and you want to add an API key only for the services you actually read. Do not adopt it expecting Instagram or Facebook coverage, since Instagram is marked as unmaintained and Facebook has been unsupported since the API lock down in 2018. Verify first which services you can obtain keys for, because the ones you cannot enable simply will not appear, and check the service list in ENABLED_SERVICES before you deploy.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. stefansundin/rssbox on GitHub