FolderHost is excellent for temporary file sharing and collaborative work, but there is currently no built-in way to enforce a retention policy on uploaded files. Every file stays in the host folder indefinitely until a user manually deletes it (and even then it moves to the recovery bin, not actually freeing disk space until the bin limit or a manual purge).
For administrators running FolderHost as a public or semi-public drop-box (e.g. a temporary file exchange for a team, a CI artifact store, a "share a build" endpoint), this creates two practical problems:
Unbounded disk growth. The storage_limit per-user helps, but a single shared folder or the admin account can still fill up the disk. There is no way to say "everything older than N days in this folder is garbage."
Data retention / privacy. Administrators may have a legal or policy obligation to delete uploaded data after a fixed period (GDPR-style "storage limitation" principle, internal security policies, etc.). Doing this today requires an external cron job with find ... -mtime +7 -delete pointed at the host directory — which is fragile, invisible from the panel, and dangerous if the path is wrong.
An external cron is a workaround, not a feature. It bypasses FolderHost entirely: it doesn't show up in logs, doesn't respect the recovery bin, and doesn't interact with the storage accounting. A native TTL would make FolderHost self-managing.
Solution
Add an optional per-folder (and optionally per-user) TTL / retention policy for files, configurable in config.yml, that automatically deletes files older than a configured duration after upload.
Proposed configuration surface (non-breaking, disabled by default):
yaml
# Optional TTL / retention policy for uploaded files.
# Disabled if not present or if enabled: false.
ttl:
enabled: false
# Default retention for folders that don't override it.
# Examples: "7d", "24h", "30d". Set to 0 to disable globally.
default: "7d"
# Cron-like or interval-based sweep, in minutes. Default: 60.
sweep_interval: 60
# What to do with expired files:
# "delete" -> move to recovery bin (if enabled), then purge after bin retention
# "purge" -> delete permanently, bypassing recovery bin
action: "delete"
# Per-folder overrides. Paths are relative to the host folder.
overrides:
- path: "/public-drops"
ttl: "24h"
- path: "/archive"
ttl: "0" # never expire
- path: "/tmp-share"
ttl: "7d"
action: "purge"
Behavior:
On a configurable interval (or a daily cron, at the admin's choice), FolderHost walks the host folder, looks at each file's upload/modification timestamp (stored in SQLite, or mtime as a fallback), and applies the effective TTL for the folder it lives in.
Expired files respect the configured action:
delete — move to the recovery bin, so an admin can restore within the bin retention window. This makes the feature non-destructive by default.
purge — permanently delete and reclaim disk space immediately.
The sweep must update FolderHost's storage accounting and audit logs (log_activities), so admins see TTL deletions in the same place as manual ones.
Users with delete permission can see that a file is scheduled for expiry (e.g. a small "expires in N days" badge in the file list) — this is optional but strongly recommended to avoid surprise data loss.
Per-user TTL should be possible in the same way storage_limit and scope are set per user, so a user account can be given a shorter retention than the global default.
Because services in FolderHost are designed for long-running processes (game servers, web servers) and are explicitly not scheduled tasks, this should be a native FolderHost feature, not something shoehorned into services.yml. It needs to integrate with the recovery bin, the SQLite DB, and the logs.
Alternatives
External cron job with find ... -mtime +7 -delete on the host folder.
This is what I currently do, but it is a workaround:
It bypasses the recovery bin entirely, so accidental expiry is unrecoverable.
It doesn't update FolderHost's storage accounting, so the panel's numbers drift from reality.
It doesn't show up in log_activities, so there's no audit trail.
It's fragile — a wrong path in the script can delete unrelated data, and the admin has to remember it exists outside the app.
It can't be scoped per user or per folder.
Running the cleanup as a FolderHost "service" (services.yml).
Technically possible by wrapping the script in a while true; do ...; sleep 86400; done loop, but this misuses the services feature. Services are long-running server processes with terminal access and RAM limits, not periodic maintenance jobs. A daemon-style wrapper also means the cleanup stops if FolderHost restarts incorrectly, and it consumes resources permanently just to sleep 99.9% of the time.
Doing nothing / manual cleanup.
Acceptable for tiny personal instances, but not for anyone running FolderHost as a shared drop-box or in a compliance-sensitive context. Manual cleanup also relies on users actually deleting their own files, which never happens in practice.
Third-party tooling (logrotate, systemd timers, Ansible, etc.).
All of these are external to FolderHost and share the same downsides as option 1: no recovery bin integration, no audit log, no storage accounting, no per-folder/per-user granularity.
A simple "delete after upload" checkbox on the upload form.
This is a nice complement, but it doesn't solve the admin-side problem of enforcing a retention policy on data uploaded by other users. The TTL feature above can exist independently and, if desired, be combined with an optional per-upload override later.
FolderHost is excellent for temporary file sharing and collaborative work, but there is currently no built-in way to enforce a retention policy on uploaded files. Every file stays in the host folder indefinitely until a user manually deletes it (and even then it moves to the recovery bin, not actually freeing disk space until the bin limit or a manual purge).
For administrators running FolderHost as a public or semi-public drop-box (e.g. a temporary file exchange for a team, a CI artifact store, a "share a build" endpoint), this creates two practical problems:
Unbounded disk growth. The storage_limit per-user helps, but a single shared folder or the admin account can still fill up the disk. There is no way to say "everything older than N days in this folder is garbage."
Data retention / privacy. Administrators may have a legal or policy obligation to delete uploaded data after a fixed period (GDPR-style "storage limitation" principle, internal security policies, etc.). Doing this today requires an external cron job with find ... -mtime +7 -delete pointed at the host directory — which is fragile, invisible from the panel, and dangerous if the path is wrong.
An external cron is a workaround, not a feature. It bypasses FolderHost entirely: it doesn't show up in logs, doesn't respect the recovery bin, and doesn't interact with the storage accounting. A native TTL would make FolderHost self-managing.
Solution
Add an optional per-folder (and optionally per-user) TTL / retention policy for files, configurable in config.yml, that automatically deletes files older than a configured duration after upload.
Proposed configuration surface (non-breaking, disabled by default):
yaml
Behavior:
On a configurable interval (or a daily cron, at the admin's choice), FolderHost walks the host folder, looks at each file's upload/modification timestamp (stored in SQLite, or mtime as a fallback), and applies the effective TTL for the folder it lives in.
Expired files respect the configured action:
delete — move to the recovery bin, so an admin can restore within the bin retention window. This makes the feature non-destructive by default.
purge — permanently delete and reclaim disk space immediately.
The sweep must update FolderHost's storage accounting and audit logs (log_activities), so admins see TTL deletions in the same place as manual ones.
Users with delete permission can see that a file is scheduled for expiry (e.g. a small "expires in N days" badge in the file list) — this is optional but strongly recommended to avoid surprise data loss.
Per-user TTL should be possible in the same way storage_limit and scope are set per user, so a user account can be given a shorter retention than the global default.
Because services in FolderHost are designed for long-running processes (game servers, web servers) and are explicitly not scheduled tasks, this should be a native FolderHost feature, not something shoehorned into services.yml. It needs to integrate with the recovery bin, the SQLite DB, and the logs.
Alternatives
External cron job with find ... -mtime +7 -delete on the host folder.
This is what I currently do, but it is a workaround:
It bypasses the recovery bin entirely, so accidental expiry is unrecoverable.
It doesn't update FolderHost's storage accounting, so the panel's numbers drift from reality.
It doesn't show up in log_activities, so there's no audit trail.
It's fragile — a wrong path in the script can delete unrelated data, and the admin has to remember it exists outside the app.
It can't be scoped per user or per folder.
Running the cleanup as a FolderHost "service" (services.yml).
Technically possible by wrapping the script in a while true; do ...; sleep 86400; done loop, but this misuses the services feature. Services are long-running server processes with terminal access and RAM limits, not periodic maintenance jobs. A daemon-style wrapper also means the cleanup stops if FolderHost restarts incorrectly, and it consumes resources permanently just to sleep 99.9% of the time.
Doing nothing / manual cleanup.
Acceptable for tiny personal instances, but not for anyone running FolderHost as a shared drop-box or in a compliance-sensitive context. Manual cleanup also relies on users actually deleting their own files, which never happens in practice.
Third-party tooling (logrotate, systemd timers, Ansible, etc.).
All of these are external to FolderHost and share the same downsides as option 1: no recovery bin integration, no audit log, no storage accounting, no per-folder/per-user granularity.
A simple "delete after upload" checkbox on the upload form.
This is a nice complement, but it doesn't solve the admin-side problem of enforcing a retention policy on data uploaded by other users. The TTL feature above can exist independently and, if desired, be combined with an optional per-upload override later.