Seperate Storage Types for Images and Attachments #1064

New Issue

OVERLORD · 2026-02-04T23:39:24+03:00

OVERLORD commented

2026-02-04 23:39:24 +03:00

Originally created by @Zeigren on GitHub (Feb 28, 2019).

In setting up a secure Bookstack instance there's a bit of a wrinkle when it comes to secure images. Since secure images are only available with STORAGE_TYPE=local_secure you're stuck with hosting all attachments locally as well.

I don't know if it's possible to do secure images over S3 so the next best thing would be to have separate storage types.

arigathanks gozaimuch

Originally created by @Zeigren on GitHub (Feb 28, 2019). In setting up a secure Bookstack instance there's a bit of a wrinkle when it comes to secure images. Since secure images are only available with `STORAGE_TYPE=local_secure` you're stuck with hosting all attachments locally as well. I don't know if it's possible to do secure images over S3 so the next best thing would be to have separate storage types. arigathanks gozaimuch

OVERLORD added the 🛠️ Enhancement 📖 Docs Update 🏭 Back-End labels 2026-02-04 23:39:24 +03:00

OVERLORD closed this issue

2026-02-04 23:39:26 +03:00

OVERLORD commented

2026-02-04 23:39:30 +03:00

@ssddanbrown commented on GitHub (Feb 28, 2019):

Thanks @Zeigren for the suggestion.

I think secure images over a network call (to S3) would cause trouble due to the rapid nature of image access when using the system.

Being able to define a separate storage system for attachments is a good idea though, and something I imagine would be useful to many others.
Shouldn't be too hard to implement so have marked it for the next feature release. I'm going to update the issue title to focus on the separate storage types, Hope that's okay.

@ssddanbrown commented on GitHub (Feb 28, 2019): Thanks @Zeigren for the suggestion. I think secure images over a network call (to S3) would cause trouble due to the rapid nature of image access when using the system. Being able to define a separate storage system for attachments is a good idea though, and something I imagine would be useful to many others. Shouldn't be too hard to implement so have marked it for the next feature release. I'm going to update the issue title to focus on the separate storage types, Hope that's okay.

OVERLORD commented

2026-02-04 23:39:37 +03:00

@ssddanbrown commented on GitHub (May 5, 2019):

Moving this out by a feature release, Due to the current release already being overdue and large in scope. Next release cycle should be a fair bit quicker than the current though.

@ssddanbrown commented on GitHub (May 5, 2019): Moving this out by a feature release, Due to the current release already being overdue and large in scope. Next release cycle should be a fair bit quicker than the current though.

OVERLORD commented

2026-02-04 23:39:39 +03:00

@ssddanbrown commented on GitHub (Jun 23, 2019):

Now included in master to be in the next release.
Variables will be as per the below example .env snippet.

If you're changing an existing storage_type in use, you'll need to migrate your content first to the new storage system. The docs detail locations of files for various storage systems:
https://www.bookstackapp.com/docs/admin/upload-config/

762d1d7595/.env.example.complete (L98-L106)

Thanks again for the feature request.

@ssddanbrown commented on GitHub (Jun 23, 2019): Now included in master to be in the next release. Variables will be as per the below example .env snippet. If you're changing an existing storage_type in use, you'll need to migrate your content first to the new storage system. The docs detail locations of files for various storage systems: https://www.bookstackapp.com/docs/admin/upload-config/ https://github.com/BookStackApp/BookStack/blob/762d1d759590aa25466c3702279baff92c09e854/.env.example.complete#L98-L106 Thanks again for the feature request.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/BookStack#1064