Memory Sidecar v3.5.1 is now public, and with it comes a focused set of operational hardening improvements for teams running agent-agnostic memory infrastructure. If you've been using the sidecar to decouple memory management from your AI agents, this release is about making that setup more resilient, secure, and production-ready without introducing new surface features. The hermes-memory-installer has been updated to streamline deployment of this version, so let's look at what changed and why it matters.
Operational Hardening in Practice
The headline for v3.5.1 is "operational hardening" – not a new protocol, not a new storage backend, but a deep cleanup of how the sidecar behaves under load, during failures, and when handling sensitive data. The team addressed several pain points that emerged from real-world deployments:
TLS by default: All internal communication between the sidecar and memory providers is now encrypted. The installer generates a self-signed certificate on first run, but also exposes --tls-cert and --tls-key flags for bring-your-own-cert. No more accidental plaintext memory dumps over the wire.
Connection pooling with backpressure: The sidecar previously opened a new connection per agent request. v3.5.1 introduces configurable pool sizes and a circuit-breaker that stops accepting new memory operations if the store layer is unresponsive for more than --backpressure-timeout (default 10s). This prevents cascading failures when the backing database stalls.
