File Storage

File storage keeps project assets inside the same workspace as tasks, tickets, calendar events, and documents.

Use it for shared files, project folders, task attachments, event attachments, document images, and public assets used on Bnder Pages.

Where files appear

Files can appear in several places:

  • project file storage
  • folders inside project storage
  • task attachments
  • task comment attachments
  • ticket attachments and public ticket replies
  • event attachments
  • public document images

Files attached to tasks, tickets, events, or documents keep their context, so teammates can find the asset from the work item where it is needed.

Workspace admins can open Settings -> Plans & Seats and use storage details to see the largest visible files, task attachments, and ticket attachments. Visible rows include an open action so admins can jump to the underlying file, task, or ticket. Task and ticket rows can be expanded to clean up individual attachments, so admins do not need to delete every attachment from a storage-heavy item. If a cleanup only partially succeeds, Bnder lists the items that could not be cleaned up. Cleanup actions are marked in the related file audit log, task history, or ticket activity so they can be distinguished from ordinary attachment deletes. The detail view follows normal permissions, so storage from restricted work is counted without exposing private item names.

Workspace admins can open Settings -> General -> Upload Security to restrict which file types may be uploaded. The restriction uses MIME types such as image/* or application/pdf. When it is off, all file types are allowed. When it is on, disallowed files are rejected before they are stored and do not count toward workspace storage.

Rejected file-type uploads appear in the workspace audit log with safe metadata, so admins can see which upload surface and MIME type triggered the policy. Inbound ticket email files blocked because public uploads are disabled are also shown in the audit log. When the related file, task, or ticket still exists, admins can open it from the audit detail.

The app narrows the file picker for common allowed-type policies and skips clearly disallowed selected files before upload when it can identify the type from the file name. The upload service still performs the final check, so unsafe or mismatched files are blocked even if a browser cannot identify them before upload.

Upload restrictions

  • The maximum file size is 1 GB.
  • The file size cannot be larger than the remaining workspace storage.
  • Uploading to project file storage requires the MANAGE_FILES permission.
  • Public ticket uploads use stricter public-ingress limits than internal app uploads.
  • Admin file-type restrictions apply to project files, task attachments, ticket attachments, public ticket uploads, and inbound ticket email attachments.
  • Task comment attachments require a Starter or Pro seat.

Folders and access

Project files can be organized into folders.

Access can be granted on a file-by-file basis or by granting access to a folder. Folder access is inherited by the files and subfolders inside it.

People who can access the storage location can open the file from the app. If a file is attached to a task, ticket, event, or document, access also depends on the permissions for that object.

Public files

Files are private by default.

When configured, a file can be made public. Anyone with the public file link can access it, even if they do not have workspace access.

Public files are useful for:

  • images embedded in public documents
  • assets linked from Bnder Pages
  • files that should be shared outside the workspace without creating a user account

Review public files regularly. If a file should no longer be public, turn off public access or delete the file.

Sharing files and folders

When a file or folder is shared with a workspace member, Bnder can notify that member through the normal notification flow. See Notifications for browser push, Slack, Discord, and email behavior.

Deleting files

Deleting a file requires the MANAGE_FILES permission.

Deleted files cannot be restored. Storage space is released and can be used for new files.

If you delete a public file that is embedded in a public document or page, the old public link stops working. Update the document or page to point to a replacement file before deleting the original.