How a delete is kept safe
Reaper removes irreplaceable files from a server other people depend on, so the app keeps any file that's unclear.
The path a delete takes
Each step has its own gate. You can stop it at any point.
Two locks keep it off
Every request to your servers goes through a guarded connection. It carries a deletion only when both of these are true.
- Deletion is armed. This is the switch you set in Policy, Deletion. It's stored in the database and defaults to off.
- Every delete is written down before it is sent. Reaper records the removal first, and the connection refuses anything that arrives without that record, even while armed.
The two are independent, so either one alone still refuses the delete. A brand-new feature is safe by existing, because it travels through that same guarded connection. Reaper reaches Plex through a separate connection with the same two locks, and it holds back even a library refresh, because on some servers a refresh empties the trash.
Judged on frozen, complete evidence
Everything's gathered and frozen before the scoring starts. This means no item's fate depends on a source timing out halfway through a scan. If a source that could condemn something was unreachable, the scan is marked incomplete. You can look at it, but you can't run anything against it.
Checked again at the moment of deletion
You can reverse everything above, but the reap isn't reversible. Each file runs one last set of checks live right before it goes. Every check keeps the file when it's unsure.
- the file is kept
- the run stops
- The test file goes first. The smallest file with a known size goes alone and is verified before any other is touched. If it doesn't behave exactly as expected, the whole run halts. Files spared or still being watched are skipped first. If a later file misbehaves, it's recorded and the run carries on.
- Removed so it stays gone. Turn on the import exclusion for a Radarr instance so a movie it removes stays off your lists and won't quietly re-download. It's off by default until you set it per instance. Reaper unmonitors the season and checks that it worked before it touches a file, so Sonarr cannot pull it back.
- The caps hold, while they are on. A run over its per-run or 30-day limit stops before any file goes. Switching off "Limit how much each run removes" in Policy leaves the password, your typed confirmation, and every live check standing.
Grace: a window to catch it before it's gone
When a title is first condemned, a countdown starts. It's 14 days by default. Turn on the Leaving Soon shelf and Reaper marks it in Plex so your users can keep a title they still want by simply watching it. You can also send a Discord message.
Sharp edges
- A scripted deploy can start armed. The password gate covers the switch in the app. You can turn deletion on at first boot without a password by setting
REAPER_DESTRUCTIVE_ACTIONS_ENABLED=truein the environment. This is meant for infrastructure-as-code installs. - That environment setting is the default until you use the switch. Once you turn deletion on or off in the app, the app's switch wins for good. Use Policy, Deletion to return a running install to read-only.
- A few read failures keep files, and the scan carries on. If Reaper can't list a service's folders, it won't match the items it's unsure about, so those files are kept. A small hiccup does not always raise an incomplete-scan banner. Check the logs if you think something is missing.
- The Leaving Soon shelf is off until you turn it on. To update it in Plex, you need deletion armed unless you also turn on "Update while read-only" in Settings, Plex. It only reaches people who browse or pinned that library. Wire up the Discord webhook to warn everyone else.