Additional storage option: s3_secure #5003

New Issue

OVERLORD · 2026-02-05T09:32:41+03:00

OVERLORD commented

2026-02-05 09:32:41 +03:00

Originally created by @wdwinslow on GitHub (Oct 14, 2024).

Describe the feature you'd like

An additional storage option that used S3 for image / attachment storage like the existing s3 option does, with the addition of causing the application itself to pull images from S3 and serve them to clients directly would be hugely helpful.

An alternative way to explain this is that an option like this would cause BookStack to treat images, the way it treats attachments stored in S3 now.

Reference: Current Storage Options

Describe the benefits this would bring to existing BookStack users

This would allow users to use S3 storage for BookStack without needing to allow public access to the bucket itself.
This would allow users who wish to restrict access to BookStack (and images used in BookStack) by source IP address a viable way to do that, without having to build out complicated infrastructure to also restrict access to the images hosted in S3.
This would allow users who wish to run the containerized version on a hyper-scale cloud provider where volume mounts don't currently appears to work well with BookStack a great way to do that.

Can the goal of this request already be achieved via other means?

Yes - The signed URL approach mentioned in #763 would be a potentially viable alternative. However, given the way BookStack already pulls attachments from S3, this approach might be easier to implement.

Have you searched for an existing open/closed issue?

I have searched for existing issues and none cover my fundamental request

How long have you been using BookStack?

Under 3 months

Additional context

I have been asked to deploy BookStack for an organization that requires a high level of security. The organization wishes to deploy this in containerized form as it does with it's other applications. We attempted to deploy the LinuxServer.io containers on Google Cloud Platform (Cloud Run) using an attached Cloud Storage volume with the storage option set to local_secure. We ran into the exact same errors mentioned in #4226. We expect this is caused by the way the mounted object storage appears to the container. Thanks for your consideration.

Originally created by @wdwinslow on GitHub (Oct 14, 2024). ### Describe the feature you'd like An additional storage option that used S3 for image / attachment storage like the existing s3 option does, with the addition of causing the application itself to pull images from S3 and serve them to clients directly would be hugely helpful. An alternative way to explain this is that an option like this would cause BookStack to treat **images**, the way it treats **attachments** stored in S3 now. Reference: [Current Storage Options](https://www.bookstackapp.com/docs/admin/upload-config/) ### Describe the benefits this would bring to existing BookStack users - This would allow users to use S3 storage for BookStack without needing to allow public access to the bucket itself. - This would allow users who wish to restrict access to BookStack (and images used in BookStack) by source IP address a viable way to do that, without having to build out complicated infrastructure to also restrict access to the images hosted in S3. - This would allow users who wish to run the containerized version on a hyper-scale cloud provider where volume mounts don't currently appears to work well with BookStack a great way to do that. ### Can the goal of this request already be achieved via other means? Yes - The signed URL approach mentioned in #763 would be a potentially viable alternative. However, given the way BookStack already pulls attachments from S3, this approach might be easier to implement. ### Have you searched for an existing open/closed issue? - [X] I have searched for existing issues and none cover my fundamental request ### How long have you been using BookStack? Under 3 months ### Additional context I have been asked to deploy BookStack for an organization that requires a high level of security. The organization wishes to deploy this in containerized form as it does with it's other applications. We attempted to deploy the LinuxServer.io containers on Google Cloud Platform (Cloud Run) using an attached Cloud Storage volume with the storage option set to local_secure. We ran into the exact same errors mentioned in #4226. We expect this is caused by the way the mounted object storage appears to the container. Thanks for your consideration.

OVERLORD added the 🔨 Feature Request :cat2:🐈 Possible duplicate labels 2026-02-05 09:32:41 +03:00

OVERLORD closed this issue

2026-02-05 09:32:43 +03:00

OVERLORD commented

2026-02-05 09:32:46 +03:00

@ssddanbrown commented on GitHub (Sep 7, 2025):

Thanks for the request @wdwinslow, but I'm going to close this off as a duplicate of #763 since the fundamental request is the same (albeit via different implementation detail).

@ssddanbrown commented on GitHub (Sep 7, 2025): Thanks for the request @wdwinslow, but I'm going to close this off as a duplicate of #763 since the fundamental request is the same (albeit via different implementation detail).

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/BookStack#5003