You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Enhancement]: Support running LibreChat with a read-only container filesystem #16521
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
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.
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.
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.
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.
Activity