theme.park: CSS skins for Sonarr, Radarr, Plex and 50 self-hosted apps

The problem theme.park solves for self-hosted media stacks

Anyone running Sonarr, Radarr, Lidarr, Readarr, Prowlarr, Bazarr, Ombi, Overseerr, Petio or Organizr knows the default look: each project ships its own UI, its own colour palette and its own idea of what a dark mode should be. The result is a dashboard of six or seven tabs that do not match. theme.park exists to flatten that. The README describes it as "a collection of themes/skins for your favorite apps", and the repository's topic list names the apps it targets: sonarr, radarr, lidarr, ombi, plex, guacamole, organizr. It is aimed at the homelab operator who already runs a reverse proxy and a handful of containers, not at application developers. The scope is deliberately narrow. theme.park does not change application behaviour, add features or touch the API. It ships CSS. If an app renders its interface as server-side HTML that you can reach through a proxy, theme.park can probably restyle it. If the app renders inside a native client, it cannot.

How the CSS actually reaches your apps

The mechanism is a stylesheet delivered over HTTP and injected into the app's pages. The repository layout shows the two halves of that: a css/ directory holding the stylesheets, and themes.py plus fetch.sh, which appear to build or collect them. The delivery side is the docker/ directory and the three architecture-specific Dockerfiles (linux-amd64.Dockerfile, linux-arm-v7.Dockerfile, linux-arm64.Dockerfile), which package a web server that serves those CSS files. The README links a Docker image on Docker Hub under gilbn/theme.park and a GitHub Container Registry package. There is also a docker-mods/ directory, which is the mechanism used to apply themes to containers that support Docker mods, so in those cases the theme is injected at container start rather than by editing a proxy config. The documented installation path is the Docker image, and the docs site at docs.theme-park.dev/setup carries the per-app instructions. The important architectural point is that theme.park depends on the app's own HTML staying stable. Every selector in those stylesheets is tied to class names and element structure the upstream project controls and can change without notice.

Installing the theme.park container and linking a first app

The README points to the Docker image as the installation route, and the docs site carries the per-app detail. A minimal container run looks like the block below, using the image name from the README's Docker Hub badge. The port mapping is what the documentation describes; check docs.theme-park.dev/setup before you copy it, because the docs are the authority on current options rather than this article.

docker run -d \
  --name theme-park \
  -p 8080:8080 \
  gilbn/theme.park

Once the container is up, you point your app at the stylesheet it serves. In practice this means adding a custom CSS entry inside the app where the app supports one, or injecting a link through your reverse proxy where it does not. Sonarr, Radarr and the other Servarr apps expose a custom CSS field in their settings, and the docs.theme-park.dev page for each app gives the exact URL to paste. The URL carries the theme name as a path segment, so switching from one theme to another is a matter of changing that segment rather than reinstalling anything. The repository's theme list covers Dracula, Overseerr, Organizr, Aquamarine, Hotline, Hotpink, Space-Gray, Dark, Plex, Nord and Maroon, among others. After you paste the URL and reload, the app's background and accent colours should change immediately; if nothing changes, the stylesheet is not being fetched, and the first thing to check is whether the browser can reach the theme.park host directly.

Where theme.park breaks, and when it is the wrong tool

The failure mode is upstream UI drift. Because the themes are selector-based CSS, an application update that renames a class or restructures a panel can leave parts of the interface unstyled while the rest keeps working, which looks worse than no theme at all. The README does not document any compatibility matrix per app version, and it does not document a rollback procedure, so if a release breaks an app you are relying on the fix is either waiting for a repository update or removing the CSS link yourself. The release history shows the project does ship fixes: 1.23.0 landed on 2026-09-19, a week after 1.22.2 on 2026-09-12, with 1.22.1 back on 2026-06-21. That cadence suggests maintenance is ongoing, but it also means the gap between an upstream app release and a matching theme fix is not something the repository commits to. There is a second, quieter limitation: theme.park styles web interfaces. If you watch content through a native Plex or Jellyfin client on a TV, or through a mobile app, none of this applies. And if you run exactly one app and you are happy with its built-in dark mode, adding a container and a proxy rule for one stylesheet is more moving parts than the problem deserves.

theme.park compared with per-app custom CSS

The obvious alternative is doing it yourself: open each app's custom CSS box and paste your own rules. That approach has a real advantage, which is that you only write selectors for the elements you actually care about, so an upstream UI change breaks your stylesheet in a way you can see and fix in one file. The cost is duplication. Seven apps means seven stylesheets, seven sets of variables, and seven places to update when you decide the accent colour should shift. theme.park inverts that trade: one theme definition applied across the supported apps, maintained by someone else, at the price of depending on that someone else's release timing. A second alternative is a browser-side theme manager such as Stylus, which injects CSS locally and never touches your server. That works well for a single user on a single browser, and it fails completely for a shared instance, a TV browser or anyone else who logs in. The choice between these three comes down to how many users and how many apps you have.

Licence, upgrade cost and what the repository does not promise

theme.park is MIT licensed, which is permissive: you can use it, modify it and redistribute it, and the repository's own css/ and themes.py files are the source you would fork if you wanted a private variant. The README links a page on adding your own theme options, so local customisation is an intended path rather than a workaround. As with any MIT project, the licence grants no warranty, and nothing in the repository obliges the maintainer to fix a broken selector for a given app version. Upgrade cost is the part worth budgeting for. The container image is versioned through releases, so pinning a tag rather than tracking latest gives you a known state; the trade is that you then have to move the pin deliberately when an upstream app changes. Because the themes are CSS, an upgrade is low risk in the sense that it cannot corrupt data or change application logic. It is high annoyance in the sense that a visual regression is immediately visible to every user of the instance, and the repository does not document a staged rollout or a preview mode. The last push to the repository was on 2026-09-22, two days after the 1.23.0 release.

Editorial conclusion

Adopt theme.park if you run several of the supported apps and want one consistent dark look across all of them, and if you are willing to pin a container tag and re-check your CSS selectors after each app upgrade. Skip it if you need themes inside native mobile or desktop clients, or if you cannot tolerate a reverse proxy change. Before rolling it out, open the docs.theme-park.dev setup page for your specific app and confirm the current injection method, then check the release notes for the version you are about to pin.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. themepark-dev/theme.park on GitHub