File System Binary Storage

Cloud CMS supports store binary files to a direct file system volume or mount by by allowing it to serve as a backend provider for the storage of binary files within Cloud CMS.

When files are uploaded to Cloud CMS, they are parsed and worked with and then eventually written down to the file system for persistence. When users seek to download those binary files, they are streamed back from disk.

Depending on how you elect to configure your binary storage providers, Cloud CMS may employ an TTL cache in between to avoid going back to the binary storage provider on repeated invocations.

Configuring

Adjusting the Binary Storage Provider used by Cloud CMS is a system-wide change and will therefore require that you run Cloud CMS on-premise. SaaS subscribers do not have the ability to adjust the Binary Storage provider.

For information on how to adjust the Binary Storage Provider within an On-Premise or Docker installation, please see our documentation on Configuring the File System Binary Storage Provider.

Notes and Recommendations

The File System binary storage provider is useful for two cases:

1. When you have a cluster of API servers that work with a common file storage location. This is typically a network addressable shared volume mount (as you might find with NFS or Amazon EFS).
2. When you are running a single API server on a development box.

It is important to note that if you have a cluster of API servers and they do NOT share a common file storage location, then each server will effectively be storing to a separate place and things will not work. It is required that each API server must be able to access the files that are stored from a different API server. They must all be reading and writing from the same place.

For the latter development case, the most common binary storage providers are either GridFS (which is the default) or the file system binary storage provider. Both work very well.