How a delete is kept safe
Reaper removes irreplaceable files from a server other people depend on, so every time something is unclear, the file is kept. The path gets deliberately harder at each step.
The path a delete takes
Each step has its own gate. You can stop at any point, and most of them change nothing on disk.
Two locks keep it off
The connection every request to your servers travels through carries a deletion only when both of these are true.
- Deletion is armed. The switch you set in Policy, Deletion. It lives in the database and defaults to off.
- The delete was declared first. Every removal is written to a record before it is sent. A request that skipped that step is refused, even while armed.
The two are independent on purpose, so either one alone still refuses the delete. A brand-new feature is safe by existing, because it travels through that same guarded connection. Plex is reached 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 is gathered and frozen before anything is scored, so no item's fate depends on a source timing out partway through a scan. If a source that could condemn something was unreachable, the scan is marked incomplete. You can look at it, but nothing can be run against it. Acting on half the evidence is how a tool deletes a loved film during an outage.
Checked again at the moment of deletion
Everything above is reversible; the reap is not. So each file runs one last set of checks, live, right before it goes, and every check keeps the file when it is 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 does not behave exactly as expected, the whole run halts. Files spared or still being watched are skipped first. A later file misbehaving is recorded and the run carries on.
- Removed so it stays gone. Turn on the import exclusion for a Radarr instance and a movie it removes is kept off your lists, so it will not quietly re-download. It is off until you set it, and you set it per instance. A season is unmonitored first, and Reaper confirms that took before touching a file, so Sonarr will not pull it back.
- The caps hold, while they are on. A run over its per-run or 30-day limit stops the whole run. It never removes just the part that fits. 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, 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. A Discord heads-up can go out too.
Sharp edges
- A scripted deploy can start armed. The password gate covers the switch in the app. Setting
REAPER_DESTRUCTIVE_ACTIONS_ENABLED=truein the environment turns deletion on at first boot with no password. That is meant for infrastructure-as-code installs. - That environment setting is the default until you use the switch. The moment you turn deletion on or off in the app, the app's switch wins for good. To return a running install to read-only, use Policy, Deletion.
- A few read failures keep files, and the scan carries on. If Reaper cannot list a service's folders, it refuses to match the items it is unsure about, and those files are kept. Not every hiccup shows as an incomplete-scan banner.
- The Leaving Soon shelf is off until you turn it on, and updating it in Plex needs 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.