[Question]: How to configure session storage properly? #1840
-
What is your question?When I enable social login and registration using OpenID, I notice the following warning in my logs upon startup: Warning: connect.session() MemoryStore is not designed for a production environment, as it will leak memory, and will not scale past a single process. My interpretation of this is that if I'm running multiple LibreChat containers behind a load balancer without sticky sessions, then users will not necessarily hit the container with their session, and will therefore get an error. Is that correct? Redis seems to be the alternative to MemoryStore. However, the LibreChat documentation says: "Redis support is experimental, you may encounter some problems when using it." So my question boils down to: How would I best run LibreChat with OpenID enabled, behind a load balancer that doesn't use sticky sessions? More DetailsN/A What is the main subject of your question?User System/OAuth ScreenshotsNo response Code of Conduct
|
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 2 replies
-
|
The main "problem" you encounter when enabling Redis is needing to manually flush your cache as needed. If you can manage this, you should enable it for your use case so that sessions can be shared across instances. It's marked as experimental because I haven't personally configured a setup like this yet. Also, right now the redis cache is also coupled with other values aside from sessions. This needs to be decoupled at some point as you wouldn't necessarily want to flush sessions but may want to flush values such as models fetched from OpenAI, etc. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you, @danny-avila. I will give it a shot with Redis. |
Beta Was this translation helpful? Give feedback.
-
|
thanks for asking! |
Beta Was this translation helpful? Give feedback.
The main "problem" you encounter when enabling Redis is needing to manually flush your cache as needed.
If you can manage this, you should enable it for your use case so that sessions can be shared across instances.
It's marked as experimental because I haven't personally configured a setup like this yet.
Also, right now the redis cache is also coupled with other values aside from sessions. This needs to be decoupled at some point as you wouldn't necessarily want to flush sessions but may want to flush values such as models fetched from OpenAI, etc.