Jellysweep

Self-hosted media management, honestly reviewed. What you get when you stop deleting files manually.

TL;DR

• What it is: Open-source (GPL-3.0) automated cleanup daemon for Jellyfin — scans your library, identifies old unwatched content, and deletes it after a grace period with user override support [README].
• Who it’s for: Self-hosters running Jellyfin with Sonarr and Radarr who are losing the disk space war and are tired of manually pruning their libraries [README][4].
• Cost savings: Disk space isn’t free — cloud storage at scale or larger NAS drives cost real money. Jellysweep itself is free to run; it reduces ongoing storage costs by automating the cleanup you’d otherwise skip [README].
• Key strength: Deep integration with the *arr stack and Jellyseerr — it knows what was requested, what’s been watched, and what’s safe to delete. User keep-request system means you don’t have to be the bad guy when someone’s mid-season binge gets flagged [README].
• Key weakness: 213 GitHub stars puts this squarely in “enthusiast project” territory. No third-party benchmarks, no mature community documentation, and the tool literally deletes your media — a misconfigured filter means permanent data loss [README].

---

What is Jellysweep

Jellysweep is a Go-based automation daemon that sits alongside your Jellyfin media server and handles the cleanup work you’ve been putting off. The core idea is simple: media libraries grow until they run out of disk space. Manually deciding what to delete is tedious. Jellysweep automates the decision by cross-referencing viewing history, request status, and configurable age thresholds, then handling the actual deletion through Sonarr and Radarr rather than reaching into the filesystem directly [README].

The workflow is more thoughtful than a simple “delete if unwatched for X days.” Jellysweep queries Jellyseerr to check whether content was originally requested by a user before flagging it for deletion. It pulls viewing stats from Jellystat or Streamystats rather than guessing. It tags media in Sonarr and Radarr rather than deleting immediately, which creates an observable paper trail. There’s a configurable grace period before anything actually disappears. And critically, it exposes a web interface where your users can submit “keep” requests — so the person halfway through a series they haven’t touched in two months can flag it before it’s gone [README].

The project is written by jon4hz, ships as a Docker container, and has 213 stars on GitHub as of this writing. It is not backed by a company, there is no SaaS version, and there is no managed hosting option. It is a solo-developer open-source tool for people who run their own media infrastructure [README][github_url].

One thing the README is admirably upfront about: test in dry-run mode first, then review the dashboard before you let it delete anything. That’s a healthy caution notice for a tool whose failure mode is permanent data loss.

---

Why people choose it

The third-party review sources available for this article don’t specifically cover Jellysweep — it’s new enough (213 stars) that it hasn’t attracted dedicated write-ups yet. But the problem it solves is well-documented in the Jellyfin community.

Self-hosters running the standard Jellyfin + Sonarr + Radarr + Jellyseerr stack [4] eventually hit the same wall: the stack is excellent at acquiring media and nearly useless at retiring it. Sonarr and Radarr have no built-in “this show has been unwatched for six months, delete it” logic. Jellyseerr queues up requests but has no concept of a media lifecycle. The result is a library that grows indefinitely until you run a du -sh command and have a bad afternoon.

The alternatives are: buy more storage, delete things manually (requires periodic intervention and someone to be the decision-maker), or write your own scripts. Jellysweep is the third option pre-built. Its integration points — Jellystat/Streamystats for real view counts, Jellyseerr for request history, Sonarr/Radarr tags for exclusions — address the specific failure modes of naive “delete by age” scripts. You don’t want to delete a movie someone just requested. You don’t want to delete the one episode of a series your partner is mid-way through. Jellysweep has explicit handling for both.

The user keep-request system is the feature that makes this deployable in a shared household or friend group rather than just a solo setup. Rather than the admin manually fielding “hey did you delete X?” complaints, users log in and submit a keep request before the grace period expires. Admins can review and approve. It’s a small UX detail that makes the difference between a tool you can actually run and one you quietly disable after the first angry message [README].

---

Features

Based on the README and merged profile:

Cleanup engine:

• Configurable filters per library: content age threshold, days since last stream, minimum file size, Sonarr/Radarr tag exclusions [README]
• Three cleanup modes for TV series — controlling whether entire series, specific seasons, or individual episodes are targeted [README]
• Disk usage-based adaptive cleanup: triggers more aggressive deletion when storage hits defined thresholds [README]
• Grace period between flagging and actual deletion [README]
• Dry-run mode for testing filter configuration before live use [README]
• Media flagged via Sonarr/Radarr tags, not direct filesystem deletion — your *arr stack handles the actual removal [README]

Smart integrations:

• Jellyseerr: checks whether content was originally requested before flagging for deletion [README]
• Jellystat / Streamystats: pulls real view count data for watch history [README]
• Tunarr: optional protection for content used in live TV channels [README]
• Sonarr and Radarr: tag-based control, bidirectional — both to exclude content and to trigger deletion [README]

User-facing features:

• Web interface for browsing what’s scheduled for deletion [README]
• User keep-request system: users can request that specific content be preserved [README]
• Admin panel for reviewing and approving keep requests [README]
• “Leaving Collections” in Jellyfin: automatically creates a Jellyfin collection showing all media pending deletion, so users can see what’s going away [README]
• Push notifications to users and admins [README]
• Progressive Web App (PWA) — installable on mobile [README]

Auth and deployment:

• OIDC/SSO authentication support [README][merged profile]
• Jellyfin-native authentication as an alternative [README]
• Docker Compose deployment [README]
• Optional Valkey (Redis-compatible) cache for improved performance [README]
• Scheduler panel for configuring when cleanup runs [README]

---

Pricing: SaaS vs self-hosted math

Jellysweep has no SaaS tier, no freemium, and no paid version. The GPL-3.0 license means the source code is fully open and self-hosting is the only option [README]. The cost model is purely infrastructure.

Running Jellysweep itself:

• Software: $0
• Compute: Negligible. It’s a Go binary running periodic scans. Any machine already running Jellyfin can host this daemon without measurable overhead.
• No database required beyond the optional Valkey cache

The real cost math is about storage:

A typical self-hoster running a full media stack [4] accumulates content faster than they retire it. A 4TB NAS drive runs $80–$100. Replacing it with an 8TB drive costs $150–$200. Cloud backup of a multi-terabyte library at Backblaze B2 rates ($6/TB/month) adds up fast. Jellysweep is the tool that keeps you from needing the upgrade.

There’s no pricing comparison to a SaaS equivalent because no SaaS equivalent exists in this specific niche. The closest you get is Plex’s watchlist management features — but Plex is a different media server ecosystem entirely and has no automated deletion based on view stats and disk usage. Manual library curation is the baseline you’re comparing against: a weekend afternoon every few months spent deciding what to delete, or a misconfigured scheduled task that nukes the wrong things.

---

Deployment reality check

What you need before you start:

• A working Jellyfin instance [README]
• Sonarr and/or Radarr managing your library — Jellysweep routes deletions through these, so they’re required, not optional [README]
• At minimum one of: Jellystat or Streamystats for viewing stats (without these, Jellysweep can’t make intelligent decisions about what’s actually been watched) [README]
• Optionally: Jellyseerr for request-aware protection, Tunarr for live TV channel protection [README]
• Docker and docker-compose on your host

Installation path: Docker Compose is the primary deployment method. The README provides a standard compose file and a variant with Valkey cache. If you’re already running a multi-container media stack [4], adding another container is a known workflow.

What can go wrong:

The main risk vector is filter misconfiguration. A content_age_threshold set too aggressively, or a missing exclude_tags entry for a library you meant to protect, can result in content being queued for deletion that you didn’t intend to touch. The dry-run mode and dashboard review exist specifically to catch this — the README’s caution to “always test with dry-run mode first” is not boilerplate, it’s the most important thing in the documentation.

The grace period between tagging and deletion is your second safety net. If you have notifications configured and users actively using the keep-request system, content should never disappear without at least one person knowing it’s going away.

Filter behavior has one notable quirk documented in the README: once a media item is marked for deletion, it won’t go through the filters again. If you tighten your filters after the fact, already-flagged items stay flagged. This is important to understand before you start adjusting thresholds mid-run.

SSO and auth setup requires OIDC configuration if you want single sign-on. Jellyfin-native auth is simpler and requires no additional infrastructure. For a household deployment, Jellyfin auth is the path of least resistance.

Realistic time estimate for someone already running a full Jellyfin + Sonarr + Radarr + Jellyseerr stack: 30–60 minutes to a functioning Jellysweep instance in dry-run mode. Another session to review the dry-run output, tune your filters, and enable live deletion. Don’t rush this second part.

---

Pros and cons

Pros

• Solves a real, specific problem. Library bloat is the universal pain point for Jellyfin self-hosters, and none of the standard stack components address it. Jellysweep fills an actual gap [README][4].
• Deletion via Sonarr/Radarr, not raw filesystem. This is the right architecture — it respects your *arr stack’s awareness of what it’s managing and keeps your library metadata consistent [README].
• User keep-request system. Shared deployments with family or friends become manageable. Users get agency before their content disappears [README].
• Jellyseerr awareness. Cross-referencing request history before flagging for deletion is exactly the right heuristic. Content someone recently asked for shouldn’t be the first thing that goes [README].
• Disk usage-based adaptive cleanup. Thresholds that scale cleanup aggressiveness with actual disk pressure are more useful than a fixed schedule [README].
• PWA + web UI. Users don’t need to SSH into anything to check what’s being deleted or submit keep requests [README].
• SSO support. OIDC integration means you can gate the keep-request UI behind your existing auth stack [README].
• Dry-run mode with dashboard review. The safety tooling exists and is documented prominently [README].

Cons

• 213 GitHub stars means you’re an early adopter. This is a young project with limited community documentation, no dedicated forum, and no established track record. Edge cases in your specific library configuration may surface bugs that haven’t been encountered by others yet [README].
• Failure mode is data loss. Wrong filter configuration + no dry-run review = deleted media. Unlike most self-hosted tool failures (service goes down, UI is broken), this one is irreversible if you don’t have a backup [README].
• GPL-3.0, not MIT. If you want to embed this in a product or resell it, the GPL-3.0 license has stronger copyleft requirements than MIT. For personal use, this doesn’t matter at all.
• Requires Jellystat or Streamystats. If you’re not already running view stats tracking, you need to add another service to your stack before Jellysweep’s watch-history filters are meaningful [README].
• No cloud backup integration. Jellysweep deletes via Sonarr/Radarr without any knowledge of whether you have a backup. That’s your responsibility to manage separately.
• No third-party reviews to validate real-world reliability. Every claim in this article comes from the README and project documentation. There’s no independent stress test to cite [all sources].
• Filter immutability quirk. Items already flagged for deletion don’t get re-evaluated if you change filters — requires awareness when tuning configuration mid-run [README].

---

Who should use this / who shouldn’t

Use Jellysweep if:

• You’re running Jellyfin + Sonarr + Radarr and your disk space is a recurring problem.
• You’re already using Jellyseerr for request management and want deletion to respect that request history.
• You have a shared deployment (household, friends) and want users to have a keep-request mechanism rather than discovering their shows have disappeared.
• You have Jellystat or Streamystats already running for view analytics.
• You’re comfortable with Docker Compose deployments and will actually run dry-run mode before enabling live deletion.

Skip it (manage manually) if:

• Your library is small enough that occasional manual pruning takes under 30 minutes a year. Adding a daemon for a problem that doesn’t exist yet is overhead, not optimization.
• You don’t have Sonarr/Radarr managing your library — Jellysweep’s deletion pipeline goes through these, so without them it doesn’t function.

Skip it (wait for maturity) if:

• You run a large multi-user instance where a misconfigured deletion would be a serious incident. At 213 stars, this tool doesn’t have the production track record that warrants betting a significant shared library on it without thorough testing.
• You want dedicated forum support and extensive community documentation. That community doesn’t exist yet for this tool.

Skip it (Plex users) if:

• This is Jellyfin-specific. Plex users have their own ecosystem of management tools and Jellysweep doesn’t integrate with Plex at all [README].

---

Alternatives worth considering

No direct equivalent for the Jellyfin ecosystem has the same breadth of integration as Jellysweep, but adjacent tools exist:

• Manual scripts (bash/Python) — some self-hosters write find + sonarr-api scripts to handle deletion. Fully customizable but you own the bugs entirely.
• Sonarr’s built-in series management — Sonarr has some capacity for marking series as ended and managing disk quotas, but no watch-history awareness. It’s a partial solution for the TV shows use case only.
• Radarr’s collection management — similarly, Radarr can flag movies but has no integration with viewing stats.
• Tdarr — often mentioned alongside Jellyfin stacks [4] for media transcoding and file management. It handles codec optimization and file size reduction rather than deletion, so it’s complementary rather than competitive.
• Manual review with Jellystat — if you’re already running Jellystat for viewing analytics, you can pull “unwatched for 180+ days” reports manually and delete from there. More control, more effort.

The honest picture is that Jellysweep is currently the most purpose-built tool for this specific problem in the Jellyfin ecosystem. The alternatives are either more manual or solve a different part of the problem.

---

Bottom line

Jellysweep is a well-designed solution to a problem that every Jellyfin self-hoster eventually faces: the library that never shrinks. The integration architecture is correct — it works with Sonarr, Radarr, Jellyseerr, and your stats tracker rather than bypassing them. The user keep-request system is a genuinely useful addition for shared deployments. The disk-usage-adaptive cleanup is smarter than a fixed schedule.

The honest caveats: this is a young project with limited production track record, and its failure mode — data loss — is the worst kind. Run dry-run mode. Review the dashboard. Make sure your filters are what you intend before you enable live deletion. If you do those things, it’s a useful piece of infrastructure for a real gap in the Jellyfin ecosystem. If you skip them, the README’s caution note exists for a reason.

At 213 stars, you’re adopting this before the community has fully stress-tested it. That might mean hitting an edge case nobody has reported yet. It also means you’re getting a tool that solves a real problem for free, deployed in an afternoon, by someone who clearly thought through the right integration points. For a home lab, that’s a reasonable trade.

---

Sources

1. Ayush Pande, XDA Developers — “I uninstalled these 4 self-hosted services within a week” (Feb 1, 2026). https://www.xda-developers.com/4-self-hosted-services-i-tried-and-then-uninstalled-within-a-week/
2. Gardiner Bryant, The Bryant Review — “Self-Hosted” (tag archive). https://gardinerbryant.com/tag/self-hosted/
3. Theena Kumaragurunathan, It’s FOSS — “The Self-Hosting Starter Pack: 5 Simple Tools I Recommend To Get Started With Your Homelab” (Nov 12, 2025). https://itsfoss.com/self-hosting-starting-projects/
4. Zerodya — “Self-host an automated Jellyfin media streaming stack”. https://zerodya.net/self-host-jellyfin-media-streaming-stack/

Primary sources:

• GitHub repository and README: https://github.com/jon4hz/jellysweep (213 stars, GPL-3.0 license)