Open-source theming for self-hosted apps, honestly reviewed. CSS injection, Docker mods, and why your arr stack no longer has to look like 2009.

TL;DR

What it is: A collection of CSS themes for 50+ self-hosted apps — Sonarr, Radarr, Plex, Organizr, and most of the popular homelab stack — with a unified visual language across all of them [1][2].
Who it’s for: Self-hosters running the *arr stack, Plex or Jellyfin setups, and anyone who wants their homelab dashboard to look intentional rather than assembled from random open-source defaults [2].
Cost: $0. MIT license, no SaaS tier, no paid plan, no per-seat anything [1].
Key strength: Install once via a Docker mod or reverse proxy subfilter and every covered app gets the same dark theme. No patching app source code, no maintaining forks [2][3].
Key weakness: Purely cosmetic — it doesn’t fix bad UX, doesn’t add features, and breaks silently when upstream apps change their CSS class names. You’re depending on GilbN’s maintenance schedule, not your own [1].
GitHub: 3,022 stars, MIT license, actively maintained [1].

What is theme.park

theme.park is a CSS injection toolkit. It ships a collection of hand-crafted stylesheets that restyle popular self-hosted applications — Sonarr, Radarr, Lidarr, Bazarr, Prowlarr, Plex, Organizr, Overseerr, Ombi, and around 50 others — so they all share the same visual palette [2][3].

The pitch is simple: if you run eight apps on your homelab and they each have their own default UI style (Sonarr’s dark blue, Radarr’s slightly different dark blue, Plex’s entirely different dark, etc.), theme.park gives you a single stylesheet set that makes all of them look like they came from the same product team. The official theme library ships options like Dracula, Dark, Aquamarine, Hotline, Hotpink, Space-Gray, Overseerr-style, and Plex-style palettes [2][3].

What it isn’t: theme.park doesn’t modify application behavior, doesn’t add features, and doesn’t run any server-side logic. It’s CSS files served from a CDN or your own Docker container, injected into apps via reverse proxy response modification or Docker entrypoint hooks. The app you’re theming doesn’t know it’s being restyled [3].

The project is maintained by GilbN, a single developer, with community contributions accepted via pull request for new themes and app support [1][2].

Why people choose it

No genuine third-party review articles were available in the research data for this tool — the scraped sources returned results for physical theme parks rather than the software. What follows is based on the project’s GitHub repository, official documentation, and the stated community reception on Discord and GitHub [1][2][3].

The argument for theme.park comes down to one frustration: homelab setups are visually fragmented. You pick your tools for their functionality — Sonarr for TV, Radarr for movies, Bazarr for subtitles, Overseerr for request management — and end up with five apps that look like they were built by five different teams in five different decades, because they were. The time cost of writing custom CSS per app is real. The maintenance cost of keeping that CSS in sync with upstream updates is worse.

theme.park solves both by centralizing the CSS and owning the maintenance. If Sonarr changes a class name in an update, GilbN (or a contributor) issues an updated stylesheet. You pull the new Docker image or bump a CDN URL, and you’re done. You didn’t write a line of CSS [3].

The Docker mod integration for linuxserver.io containers is the real adoption driver. LinuxServer.io is the most popular source of containerized *arr stack images, and a single environment variable pointing to a theme.park Docker mod is all it takes to restyle the app. No nginx config, no CSS file management, just a Docker Compose change [3].

Features

Theme library:

12+ official themes: Dracula, Dark, Aquamarine, Hotline, Hotpink, Space-Gray, Plex, Organizr, Overseerr-style, and others [2][3]
Community themes available via pull request — not just a one-person project [2]
CSS add-ons for specific apps (extra visual tweaks beyond the base theme) [2]

App coverage:

~50 officially supported apps including Sonarr, Radarr, Lidarr, Readarr, Prowlarr, Bazarr, Overseerr, Ombi, Plex, Organizr, Heimdall, Portainer, and others [2][3]
Coverage is community-driven, so niche apps may not be supported [1]

Installation methods — this is where it gets technical:

Docker mods for linuxserver.io containers: add DOCKER_MODS=ghcr.io/gilbn/theme.park:<app> to your Compose file and the theme injects at container startup [3]
Custom scripts for select Hotio containers [3]
CSS subfiltering via Nginx, Apache, Caddy, or Traefik reverse proxies — the proxy intercepts the app’s HTML response and injects a <link> tag [3]
Self-hosted CSS via the official Docker image — serves all CSS files locally so no external CDN dependency [2][3]

Self-hosting the CSS files: There’s a Docker image (gilbn/theme.park) that lets you serve all CSS from your own infrastructure. Useful if you’re air-gapped, have CDN reliability concerns, or just prefer keeping all dependencies local [2].

Pricing: self-hosted math

There is no SaaS version of theme.park. There is no paid tier, no license key, no hosted service. The project is MIT-licensed and free [1].

The real cost question is your time. The three paths and their realistic investment:

Docker mod path (linuxserver.io users): Add two environment variables to your Compose file. Under five minutes per app. No ongoing maintenance on your end [3].

Reverse proxy subfilter path: Requires modifying your nginx/Caddy/Traefik config to inject a CSS link tag. Roughly 30–60 minutes the first time if you haven’t done response modification before. Reusable pattern once you have it [3].

Self-hosted CSS path: Add the theme.park Docker container to your stack, update your app configs to point to local CSS. Moderate setup, full control, no external dependency [2][3].

The alternative cost: Custom CSS per app, written and maintained by you. If you have 10 apps and each theme takes 4 hours to write and 1 hour per major update, that’s 40 hours upfront plus ongoing maintenance time. theme.park is the obvious trade — you give up control, gain a maintained library.

No SaaS comparison applies here because no commercial product occupies this specific niche.

Deployment reality check

Easiest path (Docker mods): If you’re already running linuxserver.io containers — and most *arr stack users are — this is genuinely one environment variable per app. You don’t touch nginx, you don’t write CSS, you don’t think about it again until you change your theme preference [3].

Medium path (reverse proxy subfilter): Requires understanding how your reverse proxy handles response modification. Nginx’s sub_filter directive, Caddy’s response body replacement, Traefik middlewares — all work, all have documentation in the theme.park docs. If you’re running a reverse proxy with SSL termination (which you should be), you probably already know enough to do this [3].

What can go wrong:

CSS class name drift. When app developers refactor their frontend, CSS selectors break. theme.park themes go stale until the maintainer or community submits a fix. If Radarr ships a major UI overhaul, expect some period where the theme looks broken in specific areas [1].
App coverage gaps. Not all self-hosted apps are supported. If your stack includes less-popular apps, theme.park won’t cover them and you’ll have a visual mismatch anyway [2].
Single maintainer dependency. GilbN is one person. The project is MIT-licensed, so you can fork it, but the community momentum is tied to this repository. Compare this to larger projects with organizational backing [1].
No partial theme support. If you want Dracula for Sonarr but Plex-style for Organizr, you configure each app separately. It works, but the uniformity is manual [3].

What doesn’t go wrong: theme.park doesn’t touch your app’s functionality, database, or network. A broken theme means visual weirdness, not data loss or service outages. The blast radius of a bad update is purely cosmetic [3].

Pros and cons

Pros

Zero cost, MIT license. No subscription, no usage limits, no vendor relationship. Fork it, self-host the CSS, do whatever you want [1].
Docker mod integration is genuinely painless. One environment variable per linuxserver.io container. This is as close to zero-friction as self-hosted tooling gets [3].
*Covers the full arr stack. Sonarr, Radarr, Lidarr, Bazarr, Prowlarr, Readarr, Overseerr, Ombi — the entire media automation stack is covered [2][3].
Self-hosting the CSS files is straightforward. No external CDN dependency if you prefer full control [2].
Community contributions. New themes and app support come in via pull requests, not just GilbN [1][2].
Dracula theme. If you use Dracula everywhere else in your dev environment, having it in Sonarr and Radarr too is genuinely nice.

Cons

CSS drift is real. App frontend updates break themes. The lag between an app update and a theme fix can be days to weeks depending on how active the community is for that specific app [1].
Single maintainer dependency. The project health is tied to one person’s availability. There’s no organizational backing [1].
Coverage gaps. ~50 apps is a lot, but if your stack includes Gitea, Vaultwarden, Uptime Kuma, or other popular self-hosted tools that aren’t covered, you’ll still have a patchwork UI [2].
Purely cosmetic. This solves nothing functional. If Sonarr has UX you hate, a Dracula theme doesn’t help [2].
Reverse proxy path requires nginx/Caddy knowledge. Non-technical users who haven’t set up response body modification before will hit a learning curve [3].
No visual preview without setup. You have to configure a theme to see how it looks on your actual apps — screenshots show the general palette but not app-specific edge cases.

Who should use this / who shouldn’t

Use theme.park if:

You’re running 3+ self-hosted apps and the visual inconsistency bothers you.
Your stack is majority linuxserver.io containers — the Docker mod path is trivial.
You want a consistent dark theme across Sonarr, Radarr, Overseerr and the rest without writing CSS.
You’re already self-hosting with a reverse proxy — the subfilter path fits naturally into existing infrastructure.

Skip it if:

Your self-hosted stack doesn’t overlap with the 50 supported apps — you’d get partial coverage at best.
You need functionality improvements, not cosmetic ones. theme.park cannot fix bad UX.
You’re not comfortable with Docker environment variables or basic reverse proxy config — the setup is easy for experienced self-hosters but has no GUI installer.
You run Hotio containers primarily and the limited Hotio script support is your only install path — verify your specific apps are covered before investing the time.

Alternatives worth considering

Custom CSS per app: You write it, you maintain it, you control it fully. Appropriate if you have one or two apps or very specific requirements. Time-intensive at scale.

Organizr: A self-hosted dashboard that wraps multiple apps under one URL with a unified UI. Organizr has its own theme system and can visually unify apps by embedding them, not by restyling them. Different approach — iframes and tabs vs CSS injection. Organizr is also supported by theme.park, so they compose [2][3].

Heimdall / Dashy / Homarr: Dashboard launchers that link to apps rather than embedding them. They provide a unified landing page but don’t restyle the underlying apps. Complementary to theme.park, not a replacement.

App-native themes: Many apps (Plex, Jellyfin, Organizr) have their own theme systems. You can manually configure each one. Works, but doesn’t create cross-app consistency unless you happen to choose matching palettes everywhere.

Nothing: The default UIs work. If your users are just you and you don’t care what Sonarr looks like, theme.park is cosmetic luxury, not infrastructure.

Bottom line

theme.park does exactly one thing and does it cleanly: it makes 50+ self-hosted apps share the same visual language without modifying their code. For anyone running the *arr stack on linuxserver.io containers, the Docker mod path makes this a five-minute add-on to an existing setup. The trade-offs are honest — you’re depending on a single maintainer’s update cadence, CSS selectors break when apps change their frontends, and the tool does nothing about functionality. But for the specific audience it targets — homelab users who want their media server setup to look like it was designed rather than assembled — it’s the only real solution that doesn’t involve writing and maintaining CSS yourself. Free, MIT, and maintained. The math is straightforward.

Sources

GitHub — gilbn/theme.park (3,022 stars, MIT license). https://github.com/gilbn/theme.park
Official website — theme-park.dev. https://theme-park.dev/
Documentation — docs.theme-park.dev. https://docs.theme-park.dev/

Note: The third-party review sources provided during research returned results for physical theme parks rather than this software tool. This review is based on the official repository, documentation, and website only.