Retention and deletion

Reel deletes recordings on its own schedule, based on what its database knows about each session. Every deletion removes the recording from the live Reel deployment: its row and its objects in the private bucket.

The 30-day expiry

When a session closes, Reel schedules it for deletion 30 days after it ended. The session page shows this under Retention as "Scheduled deletion is no earlier than" a date. The hourly reel:retain-sessions job deletes unprotected sessions once that date has passed.

Do not add a lifecycle rule to the bucket to expire recordings. A bucket rule cannot see which recordings are protected and would delete them too.

Protecting a recording

On a session with status Ready, select Protect recording. A protected recording does not expire. The page shows who protected it and when, and the Protection filter on Sessions lists protected or unprotected sessions.

To release it, select Unprotect with 72-hour cooling. Only the person who protected it, an Admin or an Owner can do this. After unprotecting, the recording is deleted no earlier than 72 hours later, or its original expiry date if that is later. You can protect it again during that time.

Protected recordings keep using storage in your bucket for as long as they exist. The dashboard shows how many there are.

Deleting a session now

Select Delete now on the session page. Deletion ignores protection and happens straight away. If some objects could not be removed, Reel reports that the deletion is incomplete and the hourly reel:retry-deletions --apply job finishes it.

Any member can delete a session.

Erasing one user's recordings

To remove every recording of one of your application's users, for example after a data-erasure request:

1. Open Sessions, choose the Application, and enter the user's Application user ID.
2. A Delete this application user history panel appears. Type the same application user ID into Confirm application user ID.
3. Select Delete matching recordings.

Erasure overrides protection and the cooling period. It runs in batches on the queue; if it is interrupted, the reel:resume-erasures --apply job picks it up every five minutes. Reel keeps an audit of the erasure with who ran it, the application, the time, the counts and the outcome, but not the erased user ID.

The application user ID is the value your application's Reel client attached when the session started; see Privacy and capture.

Backups

Deletion and erasure act on the live deployment. They do not reach into database or bucket backups, which follow your own backup retention. If you restore an older backup, apply every relevant deletion and erasure again before you let people use Reel or re-enable ingest.

Back up the database and the bucket together, as one set. Before restoring either one, run php artisan reel:reconcile-storage --suspend on the deployment to pause the daily sweep that deletes bucket objects with no database row. After restoring, run php artisan reel:reconcile-storage to see a dry-run report, and only after reviewing it run php artisan reel:reconcile-storage --apply to resume.

Scheduled jobs

All five change data. They need the Laravel Cloud scheduler to be switched on.