[Enhancement]: Support running LibreChat with a read-only container filesystem

[peeeteeer]

What features would you like to see added?

Problem

LibreChat still writes to the local container filesystem in several runtime paths. This makes it difficult or impossible to run the application with a read-only root filesystem, which is a common hardening requirement for Kubernetes/OpenShift/containerized production deployments.

Operators can configure external storage such as S3 for uploaded files, but some code paths still create local files or directories for logs, uploads, avatars, or generated assets.

Desired behavior

LibreChat should be able to run with the application container filesystem mounted read-only, provided that persistent file storage is configured through an external backend.

Why this matters

Read-only containers reduce the blast radius of application compromise and are required by many enterprise/container security baselines. Supporting this mode would make LibreChat easier to run in hardened Kubernetes and OpenShift environments without downstream patches.

More details

Known write paths / areas to address

1. Log file transports

   • Winston loggers currently create file transports / log directories.
   • File logging should be optional and disabled through configuration/env, while preserving current behavior by default.
   • Console logging should continue to work in read-only deployments.

2. Uploads

   • Some upload paths still depend on local disk storage, for example via multer.diskStorage.
   • When S3 or another object-storage backend is configured, upload handling should stream directly to that backend instead of writing temporary files to the local filesystem.
   • Avoid using multer.memoryStorage for large uploads unless there is no streaming-compatible alternative.

3. Avatars

   • Avatar upload/storage should support the configured object-storage backend.
   • Persisted avatar URLs must remain resolvable over time. If S3 pre-signed URLs are used for display, the database should not store short-lived signed URLs as permanent avatar links.

4. LLM-generated files

   • Files generated by tools/models, such as generated images or other artifacts, should use the configured persistent storage backend instead of writing only to local disk.

Which components are impacted by your request?

No response

Pictures

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[danny-avila]

@peeeteeer misread your post, I think these are reasonable asks, will add to our roadmap.

[peeeteeer]

ok, super - gracias