*arr Scripts

Shell scripts that fill the gaps the official *arr apps won’t. Honestly reviewed — no marketing, just what you actually get.

TL;DR

• What it is: A collection of bash and Python scripts that bolt onto Radarr, Sonarr, Lidarr, Readarr, and SABnzbd — adding automation the core apps deliberately exclude [README].
• Who it’s for: Self-hosters who already have the *arr stack running and want deeper automation: automatic lyric embedding, audio format conversion, subtitle management, quality upgrades triggered on conditions the core apps can’t express [README].
• Cost savings: The scripts themselves are free (GPL-3.0). The *arr apps they extend are also free. The only cost is the VPS you’re already paying for. No SaaS equivalent exists for what this does [README].
• Key strength: Fills real automation gaps in the *arr ecosystem that the official apps explicitly won’t address — Lidarr extended in particular handles music tagging, lyrics, and format conversion in ways the base app doesn’t touch [README].
• Key weakness: Provided “as-is” with no official support from the *arr communities. Not compatible with Portainer. Maintenance depends entirely on one maintainer and 31 contributors [README].

---

What is *arr Scripts

The *arr apps — Radarr (movies), Sonarr (TV), Lidarr (music), Readarr (books) — are excellent at what they do: monitor, search, download, rename, and organize media. What they deliberately don’t do is a long list of post-processing tasks that power users want: embedding lyrics into audio files, converting FLAC to MP3 for compatibility, filtering downloads by audio language, applying specific tagging schemas, managing subtitles at the file level.

*arr Scripts originated as scripts that RandomNinjaAtk bundled directly inside custom Docker images called “Extended” containers — radarr-extended, sonarr-extended, lidarr-extended, and so on. Those containers grew popular precisely because they closed the gap. The repository you’re looking at now is the extraction of those scripts into a standalone form, designed to be dropped into the standard Linuxserver.io container images rather than requiring a separate container fork [README].

The project sits at 1,389 GitHub stars with 103 forks and 31 contributors. It’s written almost entirely in Shell (94.8%) with some Python (5.2%), which tells you exactly what this is: bash automation glue, not a polished application [GitHub].

The key technical design decision — and an important one — is that the scripts operate exclusively through the publicly available *arr REST APIs. They don’t patch binaries, don’t modify *arr source code, and don’t hook into internal application state. This means they can’t break *arr upgrades by touching code that moves, but it also means they’re bounded by what the APIs expose [README].

---

Why People Choose It

The honest answer: there’s nothing else that does what the Lidarr-extended scripts do for music. The broader *arr community [4] runs Sonarr, Radarr, and friends for straightforward media management, and the core apps cover the primary use case well. But “download and rename” is not enough for the user who wants their Lidarr music library to also have embedded lyrics, MusicBrainz-accurate tags, converted formats for portable players, and automatic quality upgrades when higher-bitrate versions appear.

The official Lidarr project’s response to most of these requests is “out of scope” — reasonable from a maintainability standpoint, frustrating if you want the feature. *arr Scripts exists to answer those requests without waiting for the upstream to change its mind.

The same dynamic applies to Sonarr and Radarr to a lesser degree: subtitle downloading, audio language filtering, SABnzbd post-processing hooks. These are things users repeatedly ask for in the *arr forums and repeatedly get told to solve externally.

The Portainer warning in the README is notable: the maintainer explicitly tells users not to use Portainer, citing known breakage and community consensus in both the *arr communities and Linuxserver.io [README]. This isn’t a theoretical caveat — it’s a recurring support issue that the maintainer has apparently stopped fielding because the answer is always the same.

---

Features

The script set is split by target application. Each has its own README with specific instructions.

Lidarr:

• Automated music quality upgrades — rescans and replaces when better versions appear
• Audio format conversion (e.g., FLAC → MP3/AAC for device compatibility)
• Lyric downloading and embedding directly into audio files
• MusicBrainz-based metadata tagging and artist data enrichment
• Extended notification and processing hooks

Sonarr:

• Subtitle downloading and management at the episode level
• Audio language filtering — skip or prefer downloads based on audio track language
• Extended post-processing triggers

Radarr:

• Similar subtitle and audio language filtering as Sonarr
• Quality upgrade automation beyond what Radarr’s built-in cutoffs handle

Readarr:

• Extended book management and processing (specifics vary by version)

SABnzbd:

• Post-download processing scripts that integrate with the *arr workflow

Universal scripts:

• Shared utility functions used across multiple application scripts

All scripts operate via REST API calls against the *arr apps — no binary patching, no application code modification [README]. This is both a safety feature and a capability ceiling: anything not exposed by the *arr APIs cannot be automated here.

---

Pricing: SaaS vs Self-Hosted Math

This is straightforward: there is no SaaS version, no paid tier, and no commercial equivalent. The scripts are GPL-3.0 licensed and free to use.

The cost model is entirely absorbed into your existing self-hosted infrastructure:

• *arr Scripts cost: $0 [GitHub, GPL-3.0]
• *arr apps cost: $0 (all free, self-hosted)
• Infrastructure: whatever you’re already paying for your Linuxserver.io containers — typically $5–20/mo for a VPS that handles the full *arr stack

There is no SaaS comparison to make here. The functionality these scripts provide doesn’t exist as a commercial product. The closest framing is: without these scripts, you’re writing these automations yourself or going without them. The value isn’t “saves you $X/month vs SaaS” — it’s “gives you functionality that money can’t buy elsewhere.”

---

Deployment Reality Check

*arr Scripts is not a beginner tool. The deployment assumption is that you already have:

1. A working Linuxserver.io-based Docker setup for at least one *arr app
2. Familiarity with Docker volumes, bind mounts, and container configuration
3. Comfort editing configuration files and reading bash scripts

The setup process per the README: download the relevant scripts, mount them into the *arr container via a Docker volume, configure the script variables (API keys, paths, format preferences), and enable them as custom scripts inside the *arr application’s settings. Each application (Radarr, Sonarr, Lidarr, etc.) has its own instructions page.

What can go sideways:

• Portainer users get explicitly warned out. If you’re managing your containers through Portainer, the maintainer’s position is clear: known breakage, don’t expect help [README].
• No support from the *arr communities. The official Sonarr, Radarr, and Lidarr communities do not support third-party scripts. If something breaks, you’re on the GitHub discussions page, not the official Discord [README].
• “Provided as-is” support policy. The README states that if a script works once, it should always work, and issues that haven’t been previously reported are likely user error. This is a reasonable position for a volunteer maintainer but means you need to be capable of reading bash to debug problems [README].
• Maintenance risk. With 1,389 stars and 31 contributors, this is a moderately popular project, but its bus factor is concentrated around the primary maintainer. The *arr apps themselves release updates regularly, and API changes occasionally break script assumptions.
• No GUI. Everything is file-based configuration and logs. If you’re used to clicking through a web interface, this will feel primitive.

Realistic time estimate for someone already running the *arr stack: 1–3 hours to configure and test Lidarr-extended scripts. For Sonarr/Radarr subtitle configuration: 30–60 minutes. For a first-time *arr deployer: add 4–8 hours of learning the base apps before these scripts become relevant.

---

Pros and Cons

Pros

• Fills real gaps the core apps won’t. Lyric embedding, format conversion, and audio language filtering are genuinely useful and not available from the official *arr projects [README].
• API-only approach is safe. No binary patching means *arr upgrades don’t break your installation at the code level [README].
• Free and GPL-3.0. No licensing cost, no usage restrictions beyond GPL terms [GitHub].
• Modular. You add only the scripts you need for the apps you run. Radarr users don’t need to touch Lidarr scripts [README].
• Active maintenance history. 1,101 commits and 31 contributors suggests ongoing attention, not an abandoned side project [GitHub].
• Linuxserver.io integration. Designed for the most common *arr container setup, which means good community documentation alignment [README].

Cons

• Not for beginners. Requires existing *arr knowledge and Docker comfort. Zero onboarding experience [README].
• No official support from *arr communities. You’re on your own if something breaks in a *arr update [README].
• Portainer is explicitly unsupported. A meaningful portion of self-hosters use Portainer and will hit problems [README].
• “As-is” support posture. The maintainer’s stance on support is explicit and limited. For production media library management, this matters [README].
• GPL-3.0 license. Not MIT — if you’re planning to embed or redistribute these scripts commercially, GPL-3.0 has implications.
• Single-maintainer concentration risk. Popular but not so popular that a maintainer departure would result in quick community pickup.
• Documentation is functional, not polished. Each app has a README with instructions, but there’s no centralized documentation site, no troubleshooting guide, and no changelog visible in the main README [GitHub].

---

Who Should Use This / Who Shouldn’t

Use *arr Scripts if:

• You’re already running Linuxserver.io-based *arr containers and know how Docker volumes work.
• You run Lidarr and want lyric embedding, audio format conversion, or enhanced tagging — this is the primary use case where nothing else competes.
• You’re comfortable reading bash scripts to understand what you’re running and debug issues when they arise.
• You’ve hit a specific automation gap in Radarr or Sonarr (subtitle management, audio language filtering) and verified these scripts address it.

Skip it (not ready for this) if:

• You’re new to self-hosting and haven’t gotten the base *arr apps stable yet. Learn those first.
• You’re using Portainer as your container management interface — the maintainer explicitly says this combination doesn’t work [README].
• You want a supported, maintained product with a team behind it. This is a community project with volunteer maintenance.
• You’re a non-technical founder who just wants organized media. The base *arr apps plus a media server (Jellyfin, Plex) are probably enough.

Consider an alternative if:

• Your main need is subtitles — Bazarr is purpose-built for this, better supported, and more feature-complete for the subtitle use case specifically.
• You want quality profile management across your *arr stack — Recyclarr handles that more cleanly.

---

Alternatives Worth Considering

• Bazarr — Purpose-built subtitle management for Sonarr and Radarr. Better supported, dedicated project, active community. If subtitles are your only need, start here instead.
• Recyclarr — Manages quality profiles, release filters, and custom formats across your *arr stack from a YAML config file. Complementary to *arr Scripts, not a replacement.
• Notifiarr — Unified notification and integration layer for the *arr ecosystem, Plex, and other services. Partially overlaps with some notification script functionality.
• The official *arr apps’ built-in custom scripts — Radarr and Sonarr both support custom script connections for on-import and on-upgrade events without any additional tooling. If your automation need is simple, try native custom scripts first before adding dependencies.
• Writing your own scripts — For a sufficiently technical user, the *arr APIs are well-documented (see servarr.com). If your use case is narrow, a 50-line bash script hitting the API directly may be simpler to maintain than the full *arr Scripts suite.

---

Bottom Line

*arr Scripts exists because the official *arr apps have drawn a clear line around what they’ll support, and a meaningful portion of power users want things on the other side of that line. For Lidarr users specifically, the extended music scripts — lyrics, format conversion, enhanced tagging — represent functionality you cannot get elsewhere without building it yourself. For Sonarr and Radarr users, the subtitle and audio language filtering fills genuine gaps. The price is zero and the GPL-3.0 license puts no practical restrictions on personal use. The cost is that you’re taking on a dependency with volunteer maintenance, no official support from the upstream *arr communities, and a setup process that requires you to already know what you’re doing. If you’re running the *arr stack and hitting the walls it’s built, these scripts are worth the setup time. If you haven’t hit those walls yet, you probably don’t need them.

---

Sources

Primary sources:

• GitHub repository and README: https://github.com/RandomNinjaAtk/arr-scripts (1,389 stars, GPL-3.0 license, 31 contributors)

Contextual sources:

• [4] Icchan, Netgamers.it — “Self-host this!” (May 2023) — community overview of the Servarr ecosystem (Sonarr, Radarr, Lidarr, Readarr). https://netgamers.it/t/self-host-this/837260

Note on sources [1], [2], [3], [5]: The third-party review scrape for this tool returned pages unrelated to *arr Scripts (a sheet music listing, a Plausible Analytics blog post, a jQuery captcha plugin page, and a JavaScript benchmark). No independent third-party reviews of *arr Scripts were available in the provided source data. Claims in this article are drawn from the GitHub README, repository metadata, and documented *arr ecosystem knowledge.