Store Nuxeo renditions in a dedicated S3 bucket

Separate storage according to the output's purpose

A dedicated location for thumbnails, picture views or video outputs can make storage policy easier to reason about. The first step is to identify which outputs are persisted document blobs and which are temporary conversion results. They do not necessarily follow the same storage path.

The original configuration article introduced the question. This guide sets out the configuration decisions and acceptance checks without assuming that one rule covers every rendition.

Map blob properties to an intended provider

Nuxeo separates blob providers from the dispatcher that chooses a provider for a document's binary. Dispatch conditions can refer to a blob XPath as well as other properties. The configuration requires a default provider. Nuxeo file storage

Inventory the actual blob properties written by the conversions in your installation. Then define a dedicated S3 provider and dispatch only the intended properties to it. Check the installed Nuxeo release and S3 package before selecting provider classes or configuration names.

Keep storage locations distinct between providers. The same Nuxeo documentation warns against providers sharing a storage location because it affects garbage collection; use separate buckets or distinct prefixes as appropriate to the design.

Preserve the application's access model

A separate bucket is not a substitute for document-level access controls. Give the running application only the storage operations and locations it requires. If encryption uses a managed key, include the key permissions in the access review.

Test the normal Nuxeo download path with both permitted and denied users. A file that is hidden from an interface should not remain available through an unintended direct-storage path.

Test new and existing content separately

Create one representative asset for each affected conversion and inspect the resulting provider and storage location. Check previews, downloads, reprocessing and deletion behavior in a test environment.

Do not assume that a new dispatch rule has relocated historical binaries. Plan any existing-content move as its own operation with reconciliation and rollback checks. Retain recoverable originals until the migration has been validated.

Make lifecycle policy and cost part of acceptance

Document which outputs can be regenerated, the effort needed to regenerate them, and how quickly consumers need them. Compare storage, request and regeneration costs before assigning lifecycle rules. A cheaper storage class is not useful if the application cannot retrieve the required preview in time.

This is a configuration planning guide; no production bucket or version-specific contribution was exercised for this revision. Pair it with reducing unnecessary conversion work, or discuss the design with Maretha's implementation team.