Changelog

RSS

All notable changes to Remem.

  1. 0.5.3Release notes ↗

    Background work that stays out of the way of searches and expiry, and a new Operations page for the Business console.

    What’s new

    • Background work keeps its place in line — every background job now belongs to a class of work with its own share of the workers, so memory expiry no longer waits behind a backlog of discovery or an index rebuild.
    • Searches wait less behind background embedding — re-embedding and imports now take a limited share of model time, in bounded passes.
    • More visibility on /metrics — job backlog and claim delay, the running jobs in each class, and how long embedding requests wait.
    • Limits you can see and set — limits on stored work and on model usage are now settings with documented defaults. A value of zero or below is refused by name, and the limits in force are logged at startup.
    • Rate limiting fix — the limiter’s refill clock no longer moves backwards under concurrent requests.
    • Operations page in the console (Business) — check index health and start rebuilds, follow migrations, edit retention policies, and manage Remem’s users and tokens. Queued and running jobs can now be cancelled from the System Admin page.
    • A more truthful console (Business) — the health page shows a section as unavailable rather than failing the whole page or showing a zero, and corpus walks take a bounded share of the tenant’s request allowance, so agents keep the rest. A read-only Vocabulary view is new as well.
    • Groundwork for maintained memory — this release includes the storage for observations and focused memory versions. It is not active in a shipped server yet, and existing memory behaviour does not change.

    Upgrading

    The first start migrates the data directory, and a directory that has been migrated cannot be opened by an older binary. To roll back, start the old binary on the backup.

    • Queued jobs are re-keyed before the server listens. A backup is taken first in <data_dir>/.backups/. This is quick: 0.20 s for 10,000 queued jobs.
    • The keyword index is rebuilt once, in the background. Until it finishes, keyword and hybrid searches return no keyword matches and report truncated: true. A directory of 3,000 memories took under a second, and the time grows with the corpus. To finish this before serving, run remem-admin text rebuild --data-dir ./data on the stopped server. This step takes no backup of its own, so make one first if you want a way back.
  2. 0.5.2Release notes ↗

    Passage-based retrieval for long memories, tenant users with individual tokens, and deployment fixes.

    What’s new

    • Retrieve relevant passages from long memories — the built-in embedding model now processes the whole memory as contextual passages. Search returns each memory once. Semantic and hybrid results with vector evidence identify the passage that contributed to the ranking by its index and UTF-8 byte offsets.
    • Tenant users and individual access tokens — create users, issue and revoke their tokens, and attribute memory actions to the authenticated user. Users travel with snapshot exports; access tokens do not.
    • A smaller server image — the embedding model is no longer baked into the image. A one-shot remem-model service installs the model into its own directory on first start, from Hugging Face with no account needed or from the rememorg/remem-model image on Docker Hub, and checks every file.
    • Docker deployment fixes — corrected data-directory permissions and build exclusions for the default data directory.

    Upgrading

    The built-in model is now pplx-embed-context-v1-0.6b, with 1,024-dimensional vectors from the Perplexity team. It adds contextual passage embeddings and multilingual retrieval. Existing model-backed data directories are re-embedded before the server starts accepting requests. Allow time for this upgrade; the admin tool also supports checkpointed offline passage upgrades. Caller-supplied embeddings remain in their configured model space.

    The first start after upgrading downloads the model (about 2.4 GB) into REMEM_MODEL_DIR, ./remem-model by default, before the server starts. Set REMEM_MODEL_IMAGE=rememorg/remem-model:pplx-embed-context-v1-0.6b-b42df969 in .env to install it from Docker Hub instead of Hugging Face.

  3. 0.5.1Release notes ↗

    Faster memory writes and retrieval, and support for caller-supplied embeddings.

    What’s new

    • Faster writes and retrieval — improvements to vector indexing, keyword search, embedding dispatch, and storage reduce work on each request. A cache for memory attributes also avoids repeated reads during search.
    • Optional external embeddings — applications can supply their own vectors for memory storage and search, with a configured model identity and dimension. The built-in embedding model remains the default.
    • Optional background vector indexing — deployments can move vector index updates behind the write response. Accepted updates are tracked through shutdown, and a failed update schedules a durable index repair. This option is off by default.
  4. 0.5.0Release notes ↗

    A new Go-based Remem built on stable Pebble storage, with more reliable memory operations, stronger search, and a foundation for future scale.

    What’s new

    • Rewritten in Go — Remem 0.5 is a new implementation focused on the product capabilities that matter most for persistent memory.
    • Apache 2.0 Community license — the Community build is now available under a permissive license so developers can build on Remem, including commercial applications, without the previous source-available service restriction.
    • Stable, reliable storage — Remem now uses Pebble for durable storage, letting the project focus on memory, retrieval, lifecycle, and relationship features instead of building and maintaining another storage engine.
    • A foundation for future scale — the new architecture supports tenant-aware operation today and leaves a clear path toward multi-tenancy, horizontal scaling, and distributed deployments.
    • Better search and retrieval — semantic, keyword, and hybrid search are more consistent, with stronger ranking, filtering, pagination, and graph connections.
    • More dependable operations — durable background jobs, lifecycle management, repair workflows, snapshots, migrations, and administrative tools make everyday operation safer and easier to recover.
    • Quality improvements — this release fixes several bugs carried forward from the earlier implementation and strengthens reliability across writes, indexing, tenancy, and deployment.
  5. 0.4.0Release notes ↗

    Reliability and scale release: safer upgrades, partition-aware retrieval, bounded operations, and more transparent, resilient memory access.

    What’s new

    • More transparent search — search responses now expose relevance and source provenance when requested. Semantic, keyword, and text-based search follow a single query path, producing more consistent ranking and behavior.
    • Safer upgrades and stronger data integrity — the storage engine now tracks on-disk format versions, supports ordered recovery with backups, and refuses to start from corrupt persisted indexes rather than risking silent data loss.
    • Flexible filtering and predictable listing — typed memory attributes, indexed selection, and storage-level filter handling improve filtering while keeping large listings and lifecycle work bounded to the requested scope.
    • Partition-aware operation at scale — storage, indexes, migrations, and query paths now preserve partition boundaries, reducing cross-tenant work and making resource use proportional to authorised data.
    • Improved durability and read consistency — concurrent writes can share a durable WAL flush; read tracking avoids unnecessary full-record writes; and archived memories no longer consume similarity-index capacity.
    • More resilient MCP and operational workflows — expired MCP sessions now recover cleanly, recent memories are returned in the expected order, and expanded benchmarks and CI coverage strengthen performance and release confidence.
    • Better high-load behavior — vector search reuses candidate work during widening, per-partition index residency is bounded, and continuation-based APIs avoid full scans for listing, connection, and background maintenance tasks.
  6. 0.3.4Release notes ↗

    Internal cleanup release: dead-code removal, WAL/durability refactoring, and lint fixes — no user-facing behavior changes.

    What’s new

    • Code hygiene sweep — removed dead code and unused allow attributes across the storage engine (index, storage, query, and utility modules), and pruned an unreachable query-planner layer.
    • Durability refactoring — collapsed duplicate WAL checkpoint logic into a shared helper, extracted common WAL/memtable retry handling, and fixed edge-creation timestamps to reflect real write time instead of read time.
    • Lint and formatting — the entire workspace now passes cargo fmt --all and cargo clippy -- -D warnings cleanly on both feature sets.
  7. 0.3.3Release notes ↗

    Fixed a crash-loop in the published Docker image when no config.toml is mounted, so the quickstart's config-less path actually works now.

    What’s new

    • Fixed: config-less startup crash-looped — the image’s default CMD baked in --config /etc/remem/config.toml unconditionally, so following the quickstart’s own suggestion to skip mounting a config file caused remem-server to crash-loop on a missing-file error instead of running on built-in defaults. entrypoint.sh now wires up --config only when a file is actually mounted at that path, so both paths work: zero-config out of the box, or drop in remem-server.toml to customize.
  8. 0.3.2Release notes ↗

    remem-mcp now ships inside the same server-latest image, so Claude Desktop and Claude Code users can run it with just Docker — no Rust toolchain required.

    What’s new

    • remem-mcp bundled into the published image — after last release’s MCP container merge, running the remem-mcp stdio binary meant cloning the source and building it with Rust. It’s now compiled into rememorg/remem-community:server-latest alongside remem-server, so docker run --rm -i --network remem-network rememorg/remem-community:server-latest remem-mcp --server-url http://remem-server:4545 works out of the box.
    • Claude Desktop and Claude Code setup docs updated to this Docker-based command as the primary path.
  9. 0.3.1Release notes ↗

    MCP now runs in-process inside remem-server over Streamable HTTP — one container to deploy instead of two, with the standalone remem-mcp binary staying available as a stdio client.

    What’s new

    • MCP moved in-process — remem-server now mounts a full MCP (Streamable HTTP) endpoint at /mcp, replacing the separate remem-mcp container and its SSE transport. Same 8 tools and 3 resources, same auth, one fewer service to run and monitor.
    • One container instead of two — docker-compose.yml no longer starts a remem-mcp service, and the standalone docker/remem-mcp.Dockerfile and its Docker Hub image (:mcp-* tags) are retired. remem-mcp remains a stdio-only binary for clients that need it — run it directly, or point a Streamable-HTTP client straight at remem-server’s /mcp route. Prebuilt images now ship as a single rememorg/remem-community:server-* tag. MCP_TRANSPORT/MCP_PORT/MCP_HOST env vars, and Claude Desktop configs that docker exec into the old remem-mcp-server container, are gone — see crates/remem-mcp/CLAUDE.md for current client-config examples.
    • Session cap on the new endpoint — /mcp refuses new sessions past 1,000 concurrent, returning 503 instead of growing the session table without bound.
    • Two MCP tool bugs fixed in the stdio path: update_memory now forwards emotional_valence/arousal fields, and sort_by on search_memories/list_recent_memories is forwarded correctly instead of being silently dropped.
    • search_memories and list_recent_memories gained sort_by=accessed_at as a listing option, and results are now streamed rather than buffered in full for sort_by=created_at.
  10. 0.2.0Release notes ↗

    Durability hardening across the storage engine — crash-safe WAL replay, a checkpoint write barrier, per-memory write locking — plus a new on-demand backup endpoint and a safer default for active forgetting.

    What’s new

    • Crash-safe WAL replay — a process kill mid-write no longer fails to boot. On restart, replay recovers every complete record before a torn write and truncates the WAL there automatically; this previously required manual WAL surgery.
    • Correct write ordering under concurrency — the WAL’s on-disk order now always matches the order writes are applied in memory, so replay can no longer resurrect the loser of a race between two writes to the same key. Removing a connection is now WAL-first too, closing the same class of gap for deletes.
    • Checkpoint write barrier — the WAL is only truncated after every index (vector, graph, time-series, tag) and the in-memory write buffer have actually been flushed to disk. A failed checkpoint skips truncation and retries promptly instead of waiting out a full interval on the same cadence as a healthy one.
    • Durable vector deletions — hard-deleting a memory’s embedding now survives a checkpoint and restart; previously a deleted vector could resurrect as a search result after a restart.
    • Safer file replacement — segment manifest, chunk, and SSTable files are fsynced before rename and their parent directory fsynced after, so renames survive a crash on journaling filesystems like ext4. Any .tmp files a crash leaves behind are now swept away automatically at startup.
    • Flush backpressure — if a memtable flush keeps failing (e.g. disk full), new writes are now rejected past 4 queued flushes instead of letting memory usage grow without bound.
    • Per-memory write locking — concurrent reads/updates/deletes/promotions on the same memory are now serialized, so two operations racing on the same memory can no longer silently drop one’s update.
    • Active forgetting now archives by default instead of hard-deleting — memories that decay to zero health are archived unless you explicitly opt in to hard-delete via TaskConfig.
    • New: on-demand backups — POST /api/v1/backup triggers a checkpoint and streams a consistent tar.gz snapshot of the data directory, with memory usage bounded regardless of dataset size.
    • sync_writes now defaults to true, matching the shipped remem-server.toml — closes a gap where constructing the engine config directly (rather than through the config file) could silently run without durability.
  11. 0.1.2Release notes ↗

    Security hardening: a production-mode startup guard, rate limiting on by default, constant-time API key checks with rotation support, and safer error responses.

    What’s new

    • Production startup guard — set REMEM_ENV=production and remem-server now refuses to start if auth is disabled, the API key is missing or looks like a placeholder, or CORS is left permissive. Catches an insecure config before it goes live instead of serving unsafely.
    • Rate limiting on by default — 100 requests/sec with a burst of 50, out of the box. Previously off unless you opted in; the embedding endpoints are CPU-bound, so an unlimited deployment was a cheap denial-of-service target. Set REMEM_RATE_LIMIT_RPS=0 to disable.
    • API key rotation — a new REMEM_API_KEY_SECONDARY is accepted alongside the primary key, so you can roll a key without a downtime window where no key is valid.
    • Constant-time API key comparison — closes a timing side-channel in the auth check.
    • Safer error responses — internal errors (storage paths, I/O detail) now return a generic message to the client and log the detail server-side, instead of echoing internals back in the response body.
    • REMEM_ALLOW_AUTH_DISABLED now defaults to false in .env.example.
  12. 0.1.1Release notes ↗

    Docker image fix: remem-server now builds correctly for arm64 (Apple Silicon), not just x86_64.

    What’s new

    • Fixed multi-arch Docker builds — the remem-server image now detects the target platform and downloads the matching ONNX Runtime build (x64 or aarch64), instead of always linking the x64 binary. arm64 hosts (Apple Silicon, AWS Graviton) previously got a foreign-arch .so that broke silently at runtime.
  13. 0.1.0Release notes ↗

    Initial public release. Single-node Rust-based server and MCP with HNSW + CSR + LSM storage, 8 MCP tools, and full memory lifecycle.

    What’s new

    • Two Docker images: remem-server and remem-mcp
    • HNSW vector index with All-MiniLM-L6-v2 embeddings
    • CSR relationship graph with auto-discovery
    • Full memory lifecycle: TTL expiration, importance decay, promotion, archiving
    • 8 MCP tools + 3 MCP resources
    • REST API with OpenAPI docs at /docs
    • Bearer auth