File storage
This page is for administrators. File storage is what holds issue attachments, files uploaded by features, and database dumps.
S3-compatible storage
TaskFlow has no built-in storage — files live in external object storage with an S3 API. Any provider with an S3-compatible interface works: Amazon S3, Selectel, VK Cloud, Yandex Object Storage and others.
Cloud instances arrive with storage already set up
An instance hosted in the cloud ships with storage already connected: a dedicated bucket is provisioned for it, its size determined by the plan, and attachments and dumps are assigned to it out of the box — there is nothing to configure. If you prefer, you can replace it with your own S3-compatible storage: the credentials go on the same page described below.
Until storage is configured
Storage is a feature like any other: enable it under Administration → Plugins, then configure and 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.
Setting it up
- Enable the storage feature under Administration → Plugins (it must also be permitted by your instance configuration — see Features & settings).
- Create a bucket in your storage provider's console — the product does not create buckets itself. The name is 3–63 characters: lowercase latin letters, digits and hyphens, no dots.
- Open Administration → Storage → S3-compatible storage and fill in the credentials: region, bucket name and access keys; if needed — the service endpoint (for providers other than Amazon), the prefix object keys are stored under, and path-style addressing.
- Use Check access to confirm the bucket is reachable before people start relying on it.
- If the storage will hold issue attachments, apply the cross-origin rules — see CORS.
- Assign the storage to its purposes — see Assignments.
Once saved, the secret key is never handed back out: the interface only shows that a key has been set. The key prefix lets several instances share one bucket without mixing their files.
CORS: required for attachments
Browsers upload attachments straight to the bucket, bypassing the application servers — so the bucket must accept requests from the instance's pages. The Apply CORS button on the storage page sets this up in one step: list the address(es) your instance is served from.
Your provider must actually serve CORS
With some providers CORS only works under virtual-hosted bucket addressing (<bucket>.<storage-domain>). If the configuration is accepted but attachment uploads still fail in the browser with a CORS error — untick path-style in the settings and enable virtual-hosted addressing for the bucket in the provider's console.
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) |
More than one storage backend can be configured — each purpose is assigned independently, so attachments and dumps can live in different buckets or even with different providers.
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.
Links are signed with the storage access keys. If you need to invalidate every link that has been handed out — after a suspected leak, say — reissue the access keys with your provider and enter the new ones in the storage settings.
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 in the previous bucket and won't be found in the new one, so switch storage on an empty instance — or move the objects with your provider's tooling, preserving their keys.
The full data wipe erases the credentials
Wiping all data resets the storage settings too: assignments survive the wipe, but the credentials have to be entered again. The files in the bucket themselves are untouched.
Where to go next
- Backups — where database dumps go.
- Features & settings — enabling features.
- Configuration — attachment size and link lifetime limits.