Memory Sidecar v3.5.1 is here, and it’s all about operational hardening. This release tightens the sidecar’s behavior in production, eliminating the edge cases that plague distributed memory systems. If you’re running agents on a shared memory layer, this is the version you’ve been waiting for. The focus is purely on reliability, security, and performance—no new APIs, no feature bloat.
For context, Memory Sidecar provides a persistent, agent-agnostic memory store. It runs as a separate process, decoupling memory from your agent runtime. v3.5.1 marks the first dedicated hardening release, and it addresses the pain points we’ve seen in real deployments: data corruption under load, race conditions, and configuration drift.
Data Integrity and Recovery
The core change is a revamped write-ahead log (WAL). Previously, crash recovery relied on best-effort replay. In v3.5.1, every WAL entry includes a checksum and a monotonic sequence number. If the sidecar crashes mid-write, it replays only vetted entries and discards partial writes. This eliminates silent corruption, a frequent issue with concurrent agent writes. Additionally, automatic compaction now triggers based on a configurable ratio of stale entries, reducing disk bloat without manual intervention.
Concurrency Safety
Multi-agent access to the same memory namespace used to be a source of contention. v3.5.1 replaces coarse-grained locks with a sharded lock manager. Each memory key belongs to a shard, and operations on different shards proceed in parallel. In stress tests with 50 concurrent agents, this reduced tail latency by 35% compared to v3.4.x. The lock manager also implements an adaptive backoff for hot keys—if a key sees contention, the sidecar automatically queues retries instead of spinning.
Security Hardening
TLS 1.3 is now mandatory for all client connections. The sidecar refuses to start if a valid certificate bundle isn’t present. The installer streamlines this: hermes-memory-installer generates self-signed certificates during setup and rotates them every 24 hours. For production, you can inject your own CA-signed certs via environment variables. In-transit encryption uses AES-256-GCM, but the real news is at-rest encryption: memory snapshots are now encrypted with a key derived from the sidecar’s identity token. This prevents data leaks if disk volumes are scavenged.
Performance Optimizations
The serialization layer switched from JSON to MessagePack for internal operations. This cuts payload size by nearly 50% and reduces deserialization overhead. The eviction policy also got a lift—LRU is now backed by a concurrent hash map with O(1) access for most operations. We also added a generational cache: frequently accessed keys survive compaction cycles longer, which improves hit rates for hot data. Benchmarking with a typical agent workload shows a 40% reduction in p99 latency for read operations.
Installation via hermes-memory-installer
The hermes-memory-installer package is the recommended path for deploying v3.5.1. It handles binary downloads, checksum verification, and configuration scaffolding. Here’s a minimal setup:
npm install -g hermes-memory-installer
hermes memory install --version 3.5.1 --config /etc/hermes/sidecar.yaml
The installer generates a config file with sensible defaults—TLS enabled, WAL in /var/lib/hermes/wal, and metrics exposed on port 9090. For upgrades from v3.4.x, use:
hermes memory upgrade --version 3.5.1
This runs any required database migrations automatically. Note that v3.5.1 deprecates the legacy file backend in favor of RocksDB. If your existing store uses the file backend, the upgrade command will initiate a background migration. For large stores (over 50 GB), budget some downtime—the migration is atomic but can be slow.
What Experienced Developers Should Watch
The new health endpoint at /v1/metrics exposes Prometheus-compatible stats: hit rate, latency p50/p99, compaction progress, and active WAL size. Wire this into your alerting immediately. Also, the config option memory.eviction.generational is enabled by default. If your access pattern is extremely uniform (no hot keys), you may see slightly higher memory usage. Tune it via memory.eviction.generational.ttl if needed.
One breaking change: the backend field in the config now required rocksdb as the value. Remove any references to file in your config file before upgrading. The installer catches this and warns you, but it’s worth a manual check.
Memory Sidecar v3.5.1 is a mature, production-hardened release. The focus on operational stability makes it a solid foundation for agent-agnostic memory. Deploy it via hermes-memory-installer, lock down your config, and let your agents run without surprise.
SOCIAL SHARE CARD GENERATOR