File storage
This page is for administrators. File storage is what holds issue attachments, files uploaded by features, and database dumps.
The built-in storage
TaskFlow ships with one storage backend: the instance volume — a disk volume on the server running TaskFlow. It needs no external service, no accounts and no provider keys, and it works the same in every deployment mode.
Until storage is configured
Storage is a feature like any other: enable it under Administration → Plugins, then assign it (below). Until a backend is configured and assigned, attaching files to issues is unavailable — everything else works normally. An unassigned purpose reporting "storage not configured" is an expected state, not a fault.
Additional storage backends can be connected as separate plugins. They aren't part of the standard delivery and aren't covered here.
Setting it up
- Enable the storage feature under Administration → Plugins (it must also be permitted by your instance configuration — see Features & settings).
- Open Administration → Storage and select the instance volume.
- Adjust its settings if needed — the key prefix files are stored under, and the file size limit.
- Use Check volume to confirm the volume is writable before people start relying on it.
There are no credentials to enter and no cross-origin rules to configure: the volume belongs to the installation itself.
Assigning storage to a purpose
Configuring a backend doesn't route anything to it yet. Assignments are made separately, and in two different places:
| What is stored | Assigned on |
|---|---|
| Issue attachments and feature uploads | Administration → Settings |
| Database dumps | Administration → Backups (see Backups) |
Dumps on the instance volume are not an off-site backup
Storing dumps on the instance volume puts them on the same server as the installation. That protects you from damaging the database; it does not protect you from losing the server. Copy dumps off the machine — or send them to storage that lives elsewhere — if you want a backup worth the name.
How files move
Browsers upload and download file content directly to and from the storage, over links that are signed and expire after a few minutes. The application isn't in the path of the bytes, which keeps large attachments off the application servers.
If you need to invalidate every link that has been handed out — after a suspected leak, say — reissue the signing secret on the storage page. Existing links stop working immediately.
Link lifetimes and the maximum file size are set in Configuration.
Potentially unsafe file types
Files that a browser would happily execute in your users' session — HTML, SVG, XML — are only ever served as downloads, never rendered inline. This is deliberate and not configurable.
Disabling storage
Turning the storage feature off doesn't erase its settings or its assignments. The entry disappears from the list while the feature is off and comes back — with its configuration intact — when you enable it again. Files already stored are untouched; they are simply unreachable while the backend is off.
Switching storage doesn't move existing files
Assigning a different backend only changes where new files go. Everything uploaded earlier stays where it was, so the previous backend needs to remain enabled.
Where to go next
- Backups — where database dumps go.
- Features & settings — enabling features.
- Configuration — attachment size and link lifetime limits.