# profilarr: a configuration manager for a Radarr and Sonarr stack

> A Deno and SvelteKit self-hosted app that pulls quality profiles and custom formats from shared databases, lets you test a release against them, and pushes the result to any number of Arr instances.

**Dictionarry-Hub/profilarr** — Configuration Management Platform for Radarr/Sonarr

- Repository: https://github.com/Dictionarry-Hub/profilarr
- Website: https://dictionarry.dev
- Stars: 2,734 · Forks: 60
- Language: TypeScript
- License: AGPL-3.0
- Published: 2026-10-06 · Updated: 2026-10-06 · Language: en
- Canonical page: https://hysenlabs.com/projects/dictionarry-hub-profilarr

## Running it as two containers behind one port

Profilarr ships as a Docker image on GitHub Container Registry, and the compose file in the repository shows the intended shape. There is the main service plus an optional parser sidecar:

```yaml
services:
  profilarr:
    image: ghcr.io/dictionarry-hub/profilarr:latest
    container_name: profilarr
    ports:
      - '6868:6868'
    volumes:
      - ./config:/config
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
```

The `6868` port is the only one exposed. Configuration persists in the `./config` volume, and `PUID`, `PGID` and `UMASK` are there for file permissions on a NAS, which is the usual deployment target given the repository topics mention homelab and self-hosted.

The parser is a second image on the same registry, and the README makes its role unusually clear. It exists only for custom format and quality profile testing. Linking databases, syncing to instances and every other feature work without it, and the README says you can delete the service and its environment variables if you do not want the testing tools. That is a considerate design choice, since the dependency is expressed as optional in the documentation rather than as a hidden requirement.

The runtime stack underneath is visible in the `Dockerfile`, which builds a SvelteKit front end with Vite and then compiles it into a standalone Deno binary. It pins Deno 2.9.7 as the build image and runs `deno ci` before the build, so the repository is TypeScript served by Deno rather than a Node application.

## What a database link actually gives you

The Build column of the README's feature list is the core of the product. You link Profilarr to a curated database, and it pulls quality profiles, custom formats, regular expressions and media management definitions from there rather than asking you to write each one by hand. Three sources are named: Dictionarry, which is the same organisation's own database repository, TRaSH Guides through a companion repository, and Dumpstarr.

A custom format here is a condition set that decides whether a release matches: resolution, source, release group, size, language and more. Quality profiles group and order those qualities and assign a score per application, which is why the same database can serve both Radarr and Sonarr without you reconciling two copies. Regular expressions get their own reusable slot so a pattern is written once and referenced, rather than duplicated across a dozen formats.

You can also build a database yourself from the PCD template and share it, which is the more interesting half for anyone running a small server with idiosyncratic preferences. Media management entries cover naming conventions and quality definitions, and delay profiles handle protocol preferences, delays and score gates.

The Local tweaks feature is the one to understand before you adopt it. Changes you make on top of a linked database persist when the upstream database updates, with conflict handling for the cases where upstream changed the same thing. That is the difference between a config manager and a one-time importer.

## Why the parser service exists for testing

Getting a custom format right without being able to test it is guesswork, and Profilarr's answer is the Test column: a C# parser that matches Radarr and Sonarr's own parsing logic. The claim matters, because scoring behaviour in the Arr applications is not always obvious from the condition text alone.

With it you can test a release against conditions and get a full breakdown of how each passes or fails, with match visualization. You can validate a regular expression against embedded Regex101 test cases without leaving the app. You can simulate how a quality profile scores and ranks releases for a given movie or series.

Simulating profile ranking is the feature that has the most obvious use. Before pushing a profile change to five instances, you can point it at a specific title and see which releases it would prefer. Given that sync pushes to any number of Arr instances, being able to check the outcome first is the difference between a tool you trust and one you apply carefully.

Worth noting for planning purposes: this is the only feature that requires the sidecar container, so a deployment that skips testing can run a single container and nothing else.

## Image tags, kernel requirements and version floors

The release channels table is unusually clear about what each tag means. `latest` is the newest stable release including future major versions. `develop` is pre-release builds under testing and not guaranteed stable. An exact tag such as `2.1.0` never updates, and a major tag such as `2` stays within v2 and will not jump to a new major. Both images publish the same tags and the README says to keep them on the same channel.

New features are tested on the `develop` image by beta testers before a batch becomes stable, which explains why the repository's default branch is `develop` rather than `main`. The recent releases follow a normal cadence: v2.2.0 on 2026-08-17 added release-group filtering and release-date sorting to library views, v2.1.0 on 2026-08-09 added upgrade filter previews and size-based upgrade selectors, and v2.0.9 on 2026-06-24 was a single fix restoring source release builds. The `develop` branch was last pushed on 2026-09-24 and the repository is not archived.

The hardware floor is the part that catches people out. Profilarr v2 needs a Linux kernel of `3.17+` on a `linux/amd64` or `linux/arm64` Docker host, and the README states plainly that older kernels including Synology DSM on `3.10` are not supported. On the application side it needs Sonarr `v4+` and Radarr `v5+`, so an older Arr stack needs upgrading before this is an option.

## Jobs, sync and notifications for a running server

The Deploy column covers the automation that matters once this is installed rather than experimented with. Sync pushes configurations to any number of Arr instances. Jobs schedule sync, upgrades, renames, backups and cleanup on a timer, so the same rules apply to every instance without anyone remembering to run them. Rename does bulk file and folder renames with dry-run previews, which is the only safe way to touch a media library at scale.

Notifications cover Discord, Telegram, Slack, ntfy, Pushover, Gotify, Apprise and generic webhooks. That is a long list because these are mutually exclusive preferences rather than a claim of integration depth, and it covers most home notification setups without needing a bridge.

Upgrade automation deserves one caution. The release notes for v2.1.0 include support for filters, selectors and cooldowns on automated searches, and a fix for removing an unsupported semver-major-days value from a GitHub Actions cooldown. Search automation is where a configuration manager touches your indexer budget, so treat the default cooldown settings as something to read rather than accept.

The AGPL-3.0 licence matters here in a specific way. Self-hosting it for your own server is unproblematic. If you were planning to modify it and expose that modified version over a network, the copyleft terms are what you would need to look at, and that is a question for a lawyer rather than for this article.

## Where the README ends and dictionarry.dev begins

The README is written as a feature tour with a working compose file and a reference table of environment variables, which is enough to get running and not enough to configure well. It opens with an honest description of the problem: hours spent on quality profiles, custom formats assembled from forum posts, and the fear that settings drift between instances.

The website at dictionarry.dev and the `docs/` directory in the repository are where the depth is. The README names the concepts and points outward rather than explaining them, which is the right call for a project whose configuration surface is large, but it does mean a first-time user ends up in the docs to learn what a delay profile actually does.

The repository itself is worth a look for a different reason. Alongside `src/`, `static/` and `tests/` you get `compose.dev.yml` beside `compose.yml`, which tells you the maintainers run the develop image locally against the same compose shape, a `.semgrepignore` and `.cliffignore` for static analysis and changelog generation, and `cliff.toml` driving release notes from commits. That is a project with release plumbing in place rather than release notes written by hand, which is the more relevant signal when you are deciding whether to pin a version.

## Conclusion

profilarr makes sense when you run more than one Arr instance and have been copying quality profiles between them by hand or rebuilding custom formats from forum posts. The sync engine and the local tweaks layer are the parts that save real time, and the parser service is what turns profile editing from guesswork into something you can check before it reaches your instances. Two things decide it for you. If your only requirement is importing a TRaSH Guides YAML file once, this is a heavier tool than the job needs. And check your kernel before anything else: Profilarr v2 requires Linux `3.17+`, which rules out Synology DSM on `3.10`. Start with the `develop` tag on a throwaway instance, connect one Radarr, and only pin a `2` tag once you trust what sync does to your profiles.

## FAQ

### What is Profilarr for?

It is a self-hosted configuration manager for Radarr and Sonarr. You link it to curated databases such as Dictionarry, TRaSH Guides or Dumpstarr, pick the quality profiles and custom formats you want, test them against real releases, and push them to any number of Arr instances on a schedule. It also handles automated upgrades, bulk renames, backups and notifications.

### How to configure profilarr?

Run the container, open port 6868, and point it at your Arr instances. The compose file publishes `6868:6868`, mounts `./config` for persistence and takes `PUID`, `PGID`, `UMASK` and `TZ` as environment variables. Configure the `PARSER_HOST` and `PARSER_PORT` variables only if you want the optional parser sidecar, which exists for custom format and quality profile testing.

### Does Profilarr work with the arr stack and what does it need to run?

It targets Sonarr v4+ and Radarr v5+ on a Docker host with a Linux kernel of 3.17 or newer, on linux/amd64 or linux/arm64. The README states that older kernels, including Synology DSM installs on kernel 3.10, are not supported by Profilarr v2. Images are tagged `latest`, `develop`, an exact version or a major version, and both the main and parser images should stay on the same channel.

## Sources

- [Dictionarry-Hub/profilarr on GitHub](https://github.com/Dictionarry-Hub/profilarr)
- [License: AGPL-3.0](https://github.com/Dictionarry-Hub/profilarr/blob/develop/LICENSE)
- [Project website](https://dictionarry.dev)
- [README](https://github.com/Dictionarry-Hub/profilarr/blob/develop/README.md)
- [Releases](https://github.com/Dictionarry-Hub/profilarr/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dictionarry-hub-profilarr