theme.park

Open-source theming for self-hosted apps, honestly reviewed. No Plex dark mode drama, just what you get.

TL;DR

• What it is: A curated collection of CSS themes for ~50 self-hosted applications — Sonarr, Radarr, Jellyfin, Overseerr, qBittorrent, and dozens more [README][website].
• Who it’s for: Homelab runners and self-hosting enthusiasts who want visual consistency across a stack of apps that each shipped with a completely different design sensibility [README].
• Cost: $0. There is no pricing page because there is nothing to pay for. It’s CSS served from GitHub or your own Docker container [README].
• Key strength: Covers ~50 apps with unified themes across the full media-server stack, and the Docker mod installation method for linuxserver.io containers is genuinely painless [README][website].
• Key weakness: It is purely cosmetic. theme.park cannot fix an app’s navigation, layout, or UX problems — it only recolors what’s already there. And when an upstream app ships a major UI update, themes can temporarily break [README].
• GitHub: 3,022 stars, MIT license [merged profile].

---

What is theme.park

theme.park is a stylesheet collection for self-hosted applications. The problem it solves is specific: you’ve assembled a media server and homelab stack — Radarr for movies, Sonarr for TV, Prowlarr for indexers, Overseerr for requests, Bazarr for subtitles, Tautulli for stats, Portainer for containers — and every one of them looks like it was designed by a different team in a different decade, because it was. theme.park applies a consistent color palette across all of them simultaneously [README][website].

The creator, GilbN, maintains the project on GitHub. It has been running long enough (and accumulated enough stars) that it’s now the de-facto standard answer when someone on r/selfhosted asks “how do I make my apps not look terrible?” The repository ships nine official themes — Dracula, Aquamarine, Hotpink, Space Gray, Dark, Plex, Hotline, Organizr, and Overseerr-style — and a community theme section where anyone can submit a color scheme via pull request [README][website].

What makes it technically non-trivial is the injection mechanism. You can’t just install theme.park the way you install an app — you have to get its CSS into apps that have no native theming API. The project solves this through three methods: Docker mods for linuxserver.io containers, custom scripts for select Hotio containers, and web server subfiltering using nginx, Apache, Caddy, or Traefik. It also ships a self-hosted Docker image if you want to serve the CSS files yourself rather than pulling from the upstream CDN [README][website].

This is not a dashboard, not a homepage, not a unified app launcher. If you want a front door to your homelab, look at Homarr or Organizr. theme.park assumes you already have the apps running and just want them to stop looking like an eyesore.

---

Why people choose it

The choice to use theme.park is rarely “should I use a CSS theming tool?” and almost always “why do my apps look so inconsistent and how do I fix it in under an hour.” The project fills an extremely specific niche: the arr ecosystem (Sonarr, Radarr, Lidarr, Bazarr, Prowlarr) plus the surrounding media stack (Overseerr, Plex, Jellyfin, qBittorrent, SABnzbd) was never designed to look like a cohesive product. Each app ships with whatever the original developer thought was acceptable in the year it launched.

The value proposition is simple: you spend an afternoon setting up a Jellyfin server, another afternoon configuring Sonarr, and at the end you have something that technically works but looks like a ransom note. theme.park applies one theme across all of it.

The Docker mod path — which works for linuxserver.io containers, which is most of the arr stack — is about as close to zero-effort as CSS injection gets. You add two environment variables to your docker-compose file and the theme applies on next container restart [README]. For people who have already committed to linuxserver.io images (which is most of the arr hobbyist community), this means theme support is genuinely a five-minute operation per app.

The Dracula theme is the most commonly deployed because it matches the Dracula color scheme that many of these users already run in their terminals, editors, and browsers. Visual continuity from VS Code to Jellyfin to qBittorrent is a real quality-of-life win for people who spend hours looking at these interfaces.

---

Features

Themes available (official):

• Dracula, Aquamarine, Hotpink, Space Gray, Dark, Plex, Hotline, Organizr, Overseerr [README]
• Community themes available separately via the project’s community section [website]

Supported applications (~50 total): The supported app list covers the bulk of a typical media-server stack. From the README screenshots and documentation: Radarr, Sonarr, Bazarr, Overseerr, Ombi, Petio, Organizr, Tautulli, Portainer, Grafana, qBittorrent, Deluge, SABnzbd, NZBGet, Prowlarr, Jackett, NZBHydra2, Gitea, Jellyfin, and more [README][website]. The exact count at time of scraping was “48 themed applications” per the homepage meta description [website], though the README references “50 selfhosted apps” — the list grows as contributors add support.

Installation methods:

• Docker mods (linuxserver.io): Two environment variables in your docker-compose — the easiest path [README]
• Custom scripts (Hotio containers): Supported for select Hotio images [website]
• Web server subfiltering: nginx, Apache, Caddy, Traefik — injects CSS at the reverse-proxy level, works for any app regardless of container source [website]
• Self-hosted Docker image: Serve the CSS files from your own server instead of pulling from the upstream CDN [website]

CSS addons: Some themes include addons for specific apps — tweaks beyond basic recoloring, such as removing elements or adjusting layouts [website].

Community: Discord server for installation support, community themes via GitHub pull requests [website].

---

Pricing: There Isn’t Any

theme.park has no pricing model because there is nothing to sell. The themes are MIT-licensed CSS files. You can pull them from the GitHub CDN, self-host them with the provided Docker image, or copy the raw files into whatever serves your web apps. There is no “pro” tier, no enterprise plan, no account required [README][website].

The only cost is your server’s bandwidth if you self-host the CSS, which is negligible — CSS files are tiny. If you pull from the project’s CDN, your apps make a single request for a stylesheet on load, which is also negligible.

This is worth stating plainly because the category “CSS theming tool” doesn’t have a meaningful SaaS equivalent. There’s no Figma-for-selfhosted-app-theming that theme.park is undercutting. The value equation is: free vs. whatever time you spend setting it up. For the Docker mod path, that’s 5–10 minutes per app. For the subfiltering path, it’s 30–60 minutes of nginx configuration.

---

Deployment Reality Check

The experience varies significantly depending on which installation method you use.

Docker mod (easiest — linuxserver.io containers only):

Add DOCKER_MODS=ghcr.io/themepark-dev/theme.park:<app> and TP_THEME=<theme> to your container’s environment block. Restart the container. That’s it. If your stack is built on linuxserver.io images — which is the default recommendation in most arr setup guides — this is the path you should use [README][website].

Hotio scripts (select containers):

Similar simplicity to Docker mods, but only works for apps distributed by Hotio. The supported list is narrower [website].

Web server subfiltering (most flexible, hardest):

This injects the CSS at the reverse-proxy level, which means it works for any app regardless of how it’s containerized. The tradeoff is that you need to understand nginx’s sub_filter module (or equivalent in Caddy/Apache/Traefik), and misconfiguring it can break all proxied traffic to an app. The docs at docs.theme-park.dev include nginx and Caddy examples [website]. Realistic time for someone who’s set up a reverse proxy before: 20–30 minutes per app. For someone learning nginx for the first time: 2–4 hours.

Self-hosting the CSS:

If you want independence from the project’s CDN (legitimate concern for a homelab running air-gapped), the Docker image lets you serve the CSS files yourself. Documentation details available at docs.theme-park.dev [website].

What can go sideways:

• When an upstream app ships a major UI overhaul, themes break. The Radarr v3-to-v4 migration, for example, temporarily rendered some themes broken while the maintainer caught up. This is an inherent limitation of CSS injection — you’re styling a moving target.
• The subfiltering method requires the reverse proxy to decompress and recompress responses if apps serve gzip-compressed HTML. Missing this step means the CSS injection silently fails.
• Self-hosted CSS means you’re responsible for keeping your local image up-to-date when themes are updated upstream.

---

Pros and Cons

Pros

• Free and MIT-licensed. No accounts, no API keys, no vendor lock-in. The CSS files are yours to do whatever you want with [README].
• Docker mod path is genuinely easy. Two environment variables and a container restart. For linuxserver.io users — the majority of the arr stack community — this is as close to zero-friction as it gets [README][website].
• Broad app coverage. ~50 supported apps is enough to cover a complete media-server stack without hitting gaps [README][website].
• Multiple polished themes. Nine official themes is more than most people need. Dracula, Aquamarine, and Space Gray in particular are well-executed [README].
• Community maintained. Community themes via pull request, Discord support, and an active GitHub means niche apps get added when someone cares enough to contribute [website].
• Self-hostable CSS. You can serve the CSS files yourself and remove the external CDN dependency entirely [website][README].

Cons

• Purely cosmetic. If an app has a bad UX — poor navigation, confusing layout, slow performance — theme.park makes it look nicer while remaining equally bad to use. It solves no functional problems.
• Themes break on upstream UI updates. Major app updates can temporarily leave themes broken until the maintainer or community catches up. Depending on how frequently you update your stack, this can be a real annoyance.
• Subfiltering setup requires real knowledge. If you’re not on linuxserver.io images, the web server path demands meaningful nginx or Caddy competency. Non-technical users will struggle.
• CDN dependency by default. Out of the box, the Docker mod pulls CSS from the project’s CDN. If that CDN is down or the project is abandoned, apps revert to their default styling. The self-hosted Docker image mitigates this but adds a maintenance step.
• No app coverage guarantee. The ~50 supported apps cover the popular homelab stack well, but less-common self-hosted apps (Vikunja, Stirling-PDF, Immich, etc.) may not be supported. Check the docs before assuming your specific app is included.
• Not a dashboard. A common misconception from people new to the project — theme.park does not give you a homepage or app launcher. You still need Homarr, Homer, or Organizr for that.

---

Who Should Use This / Who Shouldn’t

Use theme.park if:

• You’re running a media-server stack (the arr apps + Jellyfin/Plex + Overseerr) and the visual inconsistency bothers you.
• Your containers are on linuxserver.io images — the Docker mod path takes minutes.
• You want Dracula or one of the other popular schemes applied uniformly, rather than hunting for per-app CSS on Reddit.
• You’re self-hosting for personal use or a small household and aesthetics matter to you.

Skip it if:

• You’re running apps that aren’t in the supported list. Check docs.theme-park.dev/themes before investing time.
• Your stack is built on non-linuxserver.io, non-Hotio images and you don’t know nginx. The subfiltering path will cost you more time than a slightly ugly interface is worth.
• You’re running a production service for customers. CSS injection at the reverse proxy is clever for a homelab; it’s fragile for anything that someone depends on professionally.
• You want a unified dashboard rather than per-app reskinning. Theme.park is not a homepage.

---

Alternatives Worth Considering

For visual consistency:

• Custom CSS per-app: Most modern apps (Sonarr, Radarr, Overseerr) have a “Custom CSS” field in their settings. You can paste in a Dracula stylesheet directly without any proxy configuration. Less unified but zero infrastructure.
• Heimdall/Homer/Homarr: These are app dashboards that give you a single front door with consistent styling. They don’t theme the underlying apps, but they reduce how often you actually look at those apps’ native UIs.

For the dashboard use case:

• Organizr: Combines dashboard + tab-based navigation, with built-in theme support. Has native theme.park integration, so you can pair both [README].
• Homarr: Modern homelab dashboard with widget support. Visual quality is good out of the box without needing CSS injection.

For the “I just want everything dark” case:

• Browser extensions like Stylus let you apply custom CSS per-site without touching your server at all. Less consistent, but requires zero infrastructure changes.

None of these do what theme.park does — which is apply a consistent theme across the actual app UIs, not just wrap them in a launcher. The project has no real direct competitor.

---

Bottom Line

theme.park solves a real but narrow problem: self-hosted media apps look inconsistent and theme.park makes them not. For linuxserver.io users, the Docker mod installation is the best argument for the project — two environment variables and you’re done. For everyone else, the subfiltering path requires enough nginx knowledge to make the whole thing more friction than it first appears.

The honest use case is a hobbyist running a full arr stack who wants it to look like a product rather than a collection of open-source apps from different eras. For that person, it’s genuinely worth the setup time. It is not a tool for production deployments, non-technical users, or anyone running apps outside the supported list.

If you’re building out a home server and you’ve already spent 40 hours configuring Sonarr, Radarr, and Jellyfin, spending another hour making them look cohesive is a reasonable use of time. theme.park is the tool that makes that hour productive.

---

Sources

Primary sources:

• GitHub repository and README — https://github.com/themepark-dev/theme.park (3,022 stars, MIT license, GilbN maintainer)
• Official website — https://theme-park.dev
• Documentation — https://docs.theme-park.dev

Note: Third-party review articles retrieved during research were unrelated to this software project (web scraping matched on “theme park” as a phrase, returning amusement-park content). This review draws from the project’s primary documentation, README, and website. No third-party article sources were available for citation.