unsubbed.co

Redirecterr

Redirecterr handles filter and redirect Overseerr requests as a self-hosted solution.

Open-source media request routing, honestly reviewed. Built for people running multiple Radarr and Sonarr instances who are tired of approving every request by hand.

TL;DR

  • What it is: A lightweight Docker sidecar that intercepts Overseerr/Jellyseerr media requests and routes them to the right Radarr or Sonarr instance based on configurable YAML filters [1].
  • Who it’s for: Self-hosters running two or more *arr instances (anime vs. regular, 4K vs. HD, kids vs. adults) who want intelligent automatic routing instead of manual approval for every request [1].
  • Cost: Free. No SaaS version exists. You run it alongside your existing stack on whatever VPS you already pay for.
  • Key strength: Solves a real gap in the Overseerr experience — routing logic that Overseerr itself doesn’t provide. Filter by keyword, content rating, requester, media type, 4K flag, season count [README].
  • Key weakness: No GUI — configuration is a YAML file only. The project has 131 GitHub stars, one visible contributor, and no published license [README][GitHub]. This is a niche utility for an already-technical audience, not a beginner tool.

What is Redirecterr

Overseerr is the standard front-end for media request management in a Plex/Jellyfin homelab. Users submit requests, an admin approves them, and they land in Radarr or Sonarr. The problem: Overseerr supports multiple *arr instances, but it doesn’t have built-in logic to decide which instance a request should go to. Every request needs a human decision, or everything lands in the same bucket.

Redirecterr fills that gap. It sits between Overseerr and your *arr instances as a webhook receiver. When a user submits a request in Overseerr, instead of waiting for manual approval, Overseerr fires a webhook at Redirecterr. Redirecterr reads the request metadata — media type, keywords, content rating, requester identity, 4K flag — runs it through a YAML-defined ruleset, and calls the Overseerr API to approve the request and route it to the correct instance automatically [README][1].

The creator described the motivation on r/selfhosted directly: *“Redirecterr runs each request through a set of filters and determines where to send it. You can filter based on any media information available in Overseerr, including the requester’s username or email. It also supports routing requests to multiple arr instances simultaneously.” [1]

The comparison the creator draws is to Petio — an older media request tool that had a filter system with a GUI. Petio is largely unmaintained now. Redirecterr covers the filter-and-route use case without the GUI [1].

The project was noted in the selfh.st “New Software” roundup in November 2024 [2], has shipped 12 releases as of this writing (latest: 2.0.1, September 21, 2025), and sits at 131 GitHub stars with 4 forks. The entire codebase is TypeScript with a Dockerfile. Small project, specific purpose.


Why People Choose It

The Reddit announcement thread [1] is the richest source of real-world motivation. The use cases that come up repeatedly:

*Multiple arr instances by genre or quality. The canonical examples from the creator: anime to sonarr_anime and everything else to sonarr; kids movies to radarr_kids; remux-quality content for specific users while standard quality goes to everyone else [1]. These aren’t edge cases — anyone running a shared Plex server with a family or friend group hits this problem within a month.

Per-user routing. You can filter on requestedBy_username or requestedBy_email, which means you can give trusted users direct access to premium quality profiles while everyone else gets the standard path. No more manually approving and re-routing every request a specific person makes [README].

4K gatekeeping. The is_4k flag lets you write rules specifically for 4K requests — send them to a dedicated sonarr_4k instance with a specific root folder and quality profile, while standard-definition requests follow a different path [README].

Content rating filtering. The contentRatings condition with exclude logic means you can prevent certain-rated content from landing in a family instance even if the requester forgot to think about it [README].

Multi-instance simultaneous delivery. The apply field accepts a list, not just one instance. A rule can send a show to both sonarr and sonarr_4k at once — useful if you want to grab both versions automatically [1][README].

The selfh.st newsletter picked it up within a month of launch, categorizing it under “New Software” alongside other legitimate homelab tools [2]. That’s a reasonable signal that the community found it genuinely useful rather than a toy project.


Features

Based on the README and creator’s own description:

Webhook receiver:

  • Listens on port 8481 for Overseerr REQUEST_PENDING_APPROVAL webhooks
  • Custom JSON payload template configured in Overseerr’s notification settings
  • Automatically calls the Overseerr API to approve and route based on filter match [README]

Filter conditions available:

  • media_type: movie or tv
  • is_4k: match only 4K requests, only non-4K, or both
  • keywords: keyword matching against media metadata (include/exclude/require logic)
  • contentRatings: age rating filtering (include/exclude/require)
  • requestedBy_username / requestedBy_email: route by who’s asking
  • max_seasons: limit routing to shows under a season count
  • Additional fields documented in fields.md in the repo [README]

Condition matching modes:

  • require: all listed values must match
  • exclude: none of the listed values must match
  • include: at least one value must match [README]

Instance configuration:

  • Supports any number of named Radarr/Sonarr instances
  • Per-instance server_id maps to Overseerr’s service order
  • Optional quality_profile_id override per instance
  • Optional approve: false flag to disable auto-approval for specific instances [README]

Fallback behavior:

  • approve_on_no_match: true auto-approves requests that don’t hit any filter — sensible default [README]

Deployment:

  • Docker and Docker Compose
  • Single YAML config file mounted as a volume
  • Structured log output with configurable log level [README]

Pricing: SaaS vs Self-Hosted Math

There is no SaaS version of Redirecterr. It’s a self-hosted-only tool, and the software itself is free.

The relevant cost question is what it runs alongside. Redirecterr is a companion to Overseerr and *arr — tools that are themselves free and self-hosted. If you’re already running that stack on a VPS, Redirecterr adds negligible resource overhead: it’s a small TypeScript process that only wakes up when Overseerr fires a webhook.

What you’re actually paying:

  • The VPS running your *arr stack: $5–20/mo depending on provider and size
  • Redirecterr: $0 additional

What you’re replacing:

  • Manual approval time: if you’re approving 20–50 media requests per week and manually re-routing each one to the right instance, that’s 10–30 minutes a week of administrative friction that Redirecterr eliminates
  • Alternatively, without routing logic, you run a single Radarr/Sonarr instance and lose the ability to separate anime, 4K, kids content, or user tiers entirely

There are no commercial alternatives doing exactly this — the closest prior art was Petio, which is unmaintained [1]. The choice isn’t “pay for SaaS vs. self-host.” It’s “add 30 minutes of setup time once vs. ongoing manual approval friction forever.”


Deployment Reality Check

The README is short and direct — setup is not complex, but it does require understanding the *arr ecosystem before you start.

Prerequisites you must already have:

  • A working Overseerr or Jellyseerr instance
  • At least two Radarr or Sonarr instances registered in Overseerr
  • Docker and Docker Compose on your server
  • Automatic request approval disabled in Overseerr (critical — Redirecterr intercepts pending-approval webhooks, so auto-approval in Overseerr would bypass it entirely) [README]

What the setup actually involves:

  1. Write a config.yaml with your instance definitions and filter rules
  2. Deploy the Docker Compose service
  3. In Overseerr, add a Webhook notification pointing at http://redirecterr:8481/webhook with a specific JSON payload template
  4. Set notification type to “Request Pending Approval”
  5. Test with a real request

The server_id mapping in the config is the most common stumbling block: it corresponds to the left-to-right order of services in Overseerr’s settings page, starting at 0. There’s a visual example linked from the README [README]. Get this wrong and requests route to the wrong instance silently.

What can go sideways:

  • No web UI means debugging is entirely log-based. Set LOG_LEVEL=info or debug and watch the container logs.
  • The fields.md file documents available condition fields but requires reading the source to understand edge cases.
  • No license is listed in the repository [GitHub]. For personal homelab use this is unlikely to matter. For anyone deploying this commercially or in an organization with IP policies, the absence of a license is technically “all rights reserved” under copyright law — worth noting.
  • Solo developer project with 131 stars. This is not a foundation-backed tool. If the author loses interest, you maintain a fork or migrate to manual approval.

For someone already comfortable with Docker and the *arr stack: 15–30 minutes to a working setup. For someone new to the *arr ecosystem who also needs to set up Overseerr and multiple Radarr/Sonarr instances first: that’s a full afternoon of work before Redirecterr even enters the picture.


Pros and Cons

Pros

  • Solves a real gap. Overseerr has no built-in request routing logic. Redirecterr is the only maintained tool currently filling this role [1].
  • Flexible filter system. Keyword, content rating, requester identity, 4K flag, media type — the combination covers most real-world routing scenarios [README].
  • Multi-instance simultaneous delivery. A single request can land in multiple *arr instances at once, which no other request management tool handles automatically [1][README].
  • Lightweight. Small TypeScript process, minimal resource footprint. Won’t noticeably affect a VPS already running Plex, Sonarr, Radarr, and Overseerr.
  • 12 releases. The project has been actively maintained since launch in November 2024, showing consistent iteration [GitHub].
  • approve_on_no_match fallback. Unmatched requests don’t get dropped silently — they’re auto-approved. Safe default for partial filter coverage [README].

Cons

  • No GUI. Configuration is YAML only. There’s no web interface for managing rules, viewing routing history, or testing filters against example requests [1][README].
  • No license published. The GitHub repository has no LICENSE file, which is atypical for an open-source project and technically leaves it “all rights reserved” [GitHub].
  • Overseerr/Jellyseerr only. If you use a different request management front-end (Doplarr, Petio, manual Radarr/Sonarr), this tool doesn’t help.
  • Solo maintainer, small project. 131 stars, one visible contributor. Longevity is unknown. Any project this small carries bus-factor risk.
  • No API or UI for rule testing. You can’t dry-run a filter against a request payload without actually submitting a real media request.
  • Setup requires disabling Overseerr’s auto-approval globally. This is a hard requirement that changes the behavior for all users, not just the ones you’re routing [README].

Who Should Use This / Who Shouldn’t

Use Redirecterr if:

  • You’re running two or more Radarr or Sonarr instances and find yourself manually re-routing requests every week.
  • You want anime, 4K, kids content, or language-specific media separated into dedicated instances automatically.
  • You want per-user routing — sending certain users to different quality profiles without touching every request.
  • You’re comfortable editing YAML and reading Docker logs. You don’t need a GUI for a config this size.

Skip it if:

  • You run a single Radarr and single Sonarr instance. There’s nothing to route between.
  • You’re new to the *arr ecosystem and haven’t gotten Overseerr, Radarr, and Sonarr working reliably first. Redirecterr is a layer on top of a working stack, not a starting point.
  • Your organization’s IP policy requires a published open-source license before deploying software.
  • You want a GUI to manage routing rules or a dashboard showing where each request landed.

Alternatives Worth Considering

Petio — The tool Redirecterr explicitly replaces. It had a GUI and filter system but is largely unmaintained. If you’re already running Petio and it works, there’s no immediate reason to migrate. If you’re starting fresh, Redirecterr is the maintained option [1].

Overseerr manual approval — The zero-tooling alternative. Every request lands in a queue, an admin routes it by hand. This works at low volume (5–10 requests per week). At higher volume or with a shared server, it becomes a time sink.

Jellyseerr — A Jellyfin-focused Overseerr fork. Not an alternative to Redirecterr — Redirecterr works with Jellyseerr as well as Overseerr [GitHub topics].

Doplarr — A Discord bot for *arr requests. Serves a different use case (Discord-native requesting) rather than Overseerr integration. No filter-and-route capability.

Custom scripts — Several r/selfhosted threads describe people writing their own Python or Bash scripts to call the Overseerr API after request approval. Redirecterr formalizes this pattern with a config file and maintained release cycle instead of a one-off script.


Bottom Line

Redirecterr is a narrow tool that does one thing: route Overseerr media requests to the right *arr instance based on rules. It does that thing well, with a sensible filter model and active maintenance. The audience is small — you have to already be running Overseerr plus multiple *arr instances and feeling the pain of manual routing — but for that audience, there’s no real competition currently maintained. The absence of a GUI and the missing license are real caveats worth tracking. For a personal homelab with a family or friend group generating 30–100 media requests per week across multiple *arr instances, a 30-minute YAML setup that replaces weekly manual triage is a straightforward trade.


Sources

  1. varthe (project author), r/selfhosted“Redirecterr: Advanced request filtering for Overseerr” (Nov 2024). https://www.reddit.com/r/selfhosted/comments/1gtr0wd/redirecterr_advanced_request_filtering_for/
  2. Ethan Sholly, selfh.st“This Week in Self-Hosted (22 November 2024)” — listed under New Software. https://selfh.st/weekly/2024-11-22/

Primary sources:

Features

Integrations & APIs

  • REST API
  • Webhooks