Memory Sidecar v3.5.1 is now available as the operational hardening release for the hermes-memory-installer ecosystem. This version targets production readiness for the agent-agnostic memory sidecar, addressing stability, security, and observability. Experienced developers building multi-agent architectures or deploying memory services at scale will find critical improvements in resource management, fault recovery, and isolation.
Agent-Agnostic Memory at Production Scale
The core premise of the Memory Sidecar remains unchanged: it provides a standalone, persistent memory layer that any agent—LLM, API gateway, or custom service—can access via a uniform HTTP interface. v3.5.1 hardens this interface against real-world operational stress. No agent-specific modifications are required, meaning existing clients continue to work with zero code changes. The focus here is not on new features but on ensuring the sidecar behaves predictably under load, network partitions, and resource contention.
What “Operational Hardening” Actually Means
Hardening in this release covers three pillars: reliability, security, and operational visibility.
Reliability comes from automatic retry‑and‑backoff for transient database and network failures, circuit breakers that trip after repeated timeouts, and controlled memory pruning. The sidecar now monitors its own RSS and will proactively release idle segments when the system reports memory pressure. Connection pooling has been reworked: the default pool size scales with available CPU cores, and idle connections are recycled every 60 seconds to prevent stale sockets. Graceful shutdown also improved—SIGTERM triggers a flush of all pending writes and a clean close of the store.
Security hardens the transport and access layers. TLS 1.3 is mandatory for all incoming requests; older TLS versions are rejected at the handshake level. API keys must now be presented as an Authorization: Bearer <token> header, and each key is scoped to a specific memory pool. Audit logging records every GET, PUT, and DELETE operation along with the key ID, timestamp, and payload size.
Operational visibility includes structured JSON logging (levels: info, warn, error) and a metrics endpoint at /metrics exposing Prometheus counters for request latency, error rates, and pool utilization.
Configuration Example
The sidecar is configured via a single YAML file. Below is a minimal production configuration highlighting the new hardening options:
sidecar:
listen: ":8080"
tls:
enforce: true
cert_file: /etc/tls/memory.crt
key_file: /etc/tls/memory.key
store:
engine: "rocksdb"
path: "/data/memory"
memory_pool:
max_size: "2048MB"
pruning_interval: "300s"
min_free: "256MB"
eviction: "lru"
client:
timeout: "10s"
retry:
max_attempts: 3
backoff: "exponential"
logging:
level: "warn"
format: "json"
metrics:
enabled: true
path: "/metrics"
This configuration enables TLS, limits memory consumption to 2 GB with LRU eviction, sets a 10‑second client timeout with exponential backoff retries, and enables Prometheus metrics.
Installation with hermes-memory-installer
Deployment is handled by hermes-memory-installer, which now performs dependency validation, checksum verification, and can apply the configuration as a sidecar container or systemd unit. The installer downloads a pre‑built binary from the official repository and verifies its SHA‑256 before unpacking.
hermes-memory-installer --deploy memory-sidecar --version 3.5.1 \
--config /etc/hermes/sidecar.yaml \
--check-updates
The --check-updates flag enables automatic notification when a new hardening release is available. For containerized environments, the installer can generate a Docker‑compatible layer or prepare the binary for direct injection.
Breaking Changes and Migration
v3.5.1 removes the deprecated /v2/* API endpoints. All clients must migrate to /v1/memory/... patterns. Additionally, TLS 1.3 enforcement means any client pinned to older TLS versions will need to be updated. The installer provides a compatibility flag (--no-tls13) for staging environments, but this must not be used in production.
To migrate, update your client code to use the /v1/ prefix and ensure your TLS library supports 1.3. No data migration is required; on‑disk storage format is backward compatible.
Why Upgrade
This release is for teams already running Memory Sidecar in staging or light production. It eliminates the fragile edge cases that surface at scale—stale connections, unbounded memory growth, and silent request failures. The circuit breaker alone can prevent a single misbehaving agent from exhausting the connection pool, and the structured logs slash debugging time.
If you’re new to the hermes-memory-installer project, v3.5.1 is the recommended starting point. It offers a stable, security‑hardened foundation for agent‑agnostic memory, ready for demanding workloads. Deploy it, configure your memory pool, and let your agents talk to a memory layer that won’t buckle under pressure.