Release review · July 9, 2026
GoodMem is built with security as a foundation, not an afterthought—combining signed image verification, automated security scanning, and a hardened nonroot server image.
See how GoodMem compares with popular alternatives on the security features that matter most to enterprise teams.
Built for secure deployment
GoodMem combines signed image verification, a hardened runtime, built-in TLS, and automated supply-chain analysis.
The CLI verifies the server image’s signed SLSA attestation and digest before launch by default. The bootstrap still relies on HTTPS delivery for the CLI and Cosign verifier.
Reviewed
The server runs as nonroot UID 65532 on a distroless Java 21 image with no shell or package manager, reducing its runtime attack surface.
Reviewed
REST and gRPC use TLS by default, with custom, self-signed, or ACME-issued certificates, automatic renewal, and hot reload.
Reviewed
Release workflows generate SBOMs and run Grype, OSV-Scanner, and FOSSA. Monthly patch updates are automated; scan findings are not a universal release gate.
Reviewed
Release-pinned comparison
Latest stable self-hosted releases reviewed July 9, 2026. Hosted offerings may add features beyond the releases compared here.
Swipe horizontally to inspect every pinned release.
| Security feature | GoodMem Server server-v1.0.288 · 3f5e8cd Released 2026-07-03 | Mem0 Memory server v2.0.11 · f2532f0 Released 2026-07-01 | Supermemory Memory server server-v0.0.3 · 39ef7e1 Released 2026-06-13 | Cognee Memory platform v1.2.2 · ce4a935 Released 2026-06-26 | OpenViking Context database v0.4.8 · 07113f8 Released 2026-07-08 | Graphiti Context graph engine v0.29.2 · ff7e29c Released 2026-06-08 |
|---|---|---|---|---|---|---|
| Secure installationDoes the supported install path verify released artifacts? | Scoped or conditional The CLI verifies the server image’s signed SLSA attestation and digest by default. The bootstrap script and auto-installed Cosign binary are not independently verified; --skip-verify disables image verification. GoodMem install verificationSLSA generator v1.0.12Private server-v1.0.288 CLI bootstrap reviewedPrivate server-v1.0.288 Cosign bootstrap reviewed Reviewed | Not located The supported Compose path builds locally, then force-reinstalls unpinned mem0ai from PyPI at startup. It performs no signature or provenance check and is not reproducibly tied to v2.0.11. | Scoped or conditional The installer checks SHA-256 against an unsigned co-hosted manifest. On macOS it replaces a failed vendor signature with a local ad-hoc signature, which does not authenticate the publisher. | Not located Source, package, and container installation are documented; no signature or provenance verification is performed by the supported install paths. | Not located Pip, uv, and container installation are documented; no built-in consumer verification step was located. | Not located The server guide pulls stale latest (currently 0.22.0), while Compose builds locally and installs unpinned graphiti-core unless a version argument is supplied. Neither path verifies artifact identity. |
| Verifiable provenanceCan a consumer verify who built the released artifact? | Directly evidenced The CLI verifies signed SLSA Build L3 provenance and the digest for the server image by default. | Scoped or conditional The 2.0.11 Python files have signed PyPI Trusted Publisher attestations. The supported server has no signed image, and its Compose path installs an unpinned package. | Not located The release provides checksums, but no publisher signature, attestation, or public server build workflow was located for the native binaries. | Scoped or conditional The 1.2.2 image carries unsigned BuildKit provenance but no publisher signature or consumer verification policy. Its provenance references post-tag commit 1913271 rather than tagged ce4a935; runtime files were unchanged. | Scoped or conditional PyPI files have signed Trusted Publisher attestations. The container is published by digest with unsigned BuildKit provenance, but no publisher signature or consumer verification policy. | Scoped or conditional graphiti-core 0.29.2 has a signed PyPI Trusted Publisher attestation. No matching 0.29.2 server image exists; Docker Hub latest remains 0.22.0. |
| Hardened server imageWhat attack-surface and privilege baseline does the released image use? | Directly evidenced Distroless Java 21 runtime with no shell or package manager; runs as nonroot UID 65532. Private server-v1.0.288 Dockerfile reviewedGoodMem public image configurationGoodMem public server image Reviewed | Scoped or conditional The source-built API development image uses a general Python base, runs as root, and enables Uvicorn reload; only the dashboard image switches to nonroot. | Not applicable The self-hosted server is distributed as a native binary rather than a container image and runs with the invoking user’s privileges. | Scoped or conditional The runtime uses a general Python slim image and does not set USER, leaving the server at the image’s root default. Reviewed | Scoped or conditional The runtime uses a general Python slim image with development utilities and does not switch away from the root default. Reviewed | Scoped or conditional The v0.29.2 source Dockerfile creates a nonroot app user on Python slim, but no matching 0.29.2 image is published; Docker Hub latest is the older 0.22.0 build. |
| Security automationWhat automated scanning or update control is visible? | Scoped or conditional SBOM, Grype, OSV-Scanner, and FOSSA jobs are present, with monthly patch-only Dependabot updates and checked auto-merge. Vulnerability findings are not a universal release gate. Private server-v1.0.288 scan workflow reviewedPrivate server-v1.0.288 Dependabot policy reviewedPAIR Systems Trust Center Reviewed | Not located The pinned workflows run tests and packaging; no dedicated code, dependency, or container vulnerability scanner was located. Reviewed | Not located The pinned CI runs formatting, lint, and type checks; no dedicated vulnerability scanner or public server build workflow was located. | Scoped or conditional An OpenSSF Scorecard workflow uploads repository security analysis; no dedicated dependency or container CVE scan was located. | Directly evidenced CodeQL scans Python and C++ with security-and-quality queries in CI and on schedule; Dependabot updates Python and GitHub Actions dependencies weekly. | Directly evidenced CodeQL scans Python and GitHub Actions on pushes, pull requests, and weekly; Dependabot updates root, server, and MCP Python dependencies weekly. |
| TLS boundaryDoes the project terminate TLS, or does the operator/host? | Directly evidenced REST and gRPC use TLS by default; custom, self-signed, and ACME-issued certificates are supported. No mTLS. Reviewed | Not located The supported server and dashboard are documented over HTTP; no native TLS configuration was located. | Scoped or conditional Vendor documentation exposes an HTTP listener and no TLS setting. The server implementation is absent from the public tag, so this cannot be independently verified in source. | Not located The supported Uvicorn and Compose paths expose HTTP; no native TLS termination configuration was located. | Scoped or conditional OpenViking listens over HTTP. Its supported Compose stack includes Caddy for HTTPS termination and automatic ACME issuance and renewal after the operator enables a domain and ports 80/443. | Not located The FastAPI server is documented over HTTP on port 8000; no native TLS termination configuration was located. |
| Access controlWhat authorization boundary is supplied by the project? | Scoped or conditional API-key authentication protects normal API operations; health, bootstrap initialization, and server-info endpoints are intentionally exempt. Every authenticated user is assigned the all-permissions ADMIN role, so differentiated RBAC is not enforced. Private server-v1.0.288 authentication path reviewed Reviewed | Scoped or conditional JWT and API-key authentication is enabled by default, and admin checks are enforced. The supported flow provisions one admin and exposes no regular-user or role-management endpoint. | Scoped or conditional Vendor documentation describes one generated bearer key and a single-tenant server, with no roles or scoped permissions. The server implementation is absent from the public tag. | Directly evidenced JWT/API-key authentication, dataset permissions, tenant roles, and scoping are implemented; API keys are stored unhashed unless HASH_API_KEY is enabled. | Directly evidenced ROOT, ADMIN, and USER roles plus tenant-scoped keys are implemented, and unauthenticated dev mode is restricted to loopback. File encryption and Argon2id API-key hashing are off by default. | Not located No request authentication or authorization middleware was located in the pinned FastAPI server. |
| Persistence dependenciesWhich stateful services are required or optional? | Directly evidenced The supported local stack includes PostgreSQL; a remote PostgreSQL database can be configured. | Directly evidenced The supported self-hosted stack requires PostgreSQL with pgvector. | Scoped or conditional Vendor documentation says the graph engine is embedded and persists to local disk with no external database. The server implementation is absent from the public tag. | Directly evidenced Embedded SQLite, graph, and vector stores are the defaults; PostgreSQL, Neo4j, and Redis are optional profiles. | Directly evidenced Local embedded storage is the default; remote vector, object, and metadata stores are optional deployment choices. | Directly evidenced The server requires a graph database, with Neo4j and FalkorDB as the documented Compose options. |
| FIPS postureIs there a documented, scoped FIPS cryptographic boundary? | Scoped or conditional Server JCE/TLS runs through BCFIPS and BCJSSE in approved-only mode, but the deployed BC-FJA 2.1.2 patch is still under submission; database and CLI paths remain outside the boundary. GoodMem FIPS boundaryPrivate server-v1.0.288 FIPS bootstrap reviewedBouncy Castle Java FIPS releasesNIST CMVP certificate 4943 Reviewed | Not located No documented FIPS mode or scoped cryptographic boundary was located in the pinned public source tree. Reviewed | Not located No documented FIPS mode or scoped cryptographic boundary was located in the pinned release or self-hosting documentation. | Not located No documented FIPS mode or scoped cryptographic boundary was located in the pinned public source tree. Reviewed | Not located Encryption and KMS options are documented, but no FIPS mode or scoped validated cryptographic boundary was located. | Not located No documented FIPS mode or scoped cryptographic boundary was located in the pinned public source tree. Reviewed |
Methodology and limits
We inspected the latest stable release available on July 9, 2026, not a moving default branch. Tags, short commit hashes, and release dates appear in every project header.
“Not located” means the audited public release did not expose an explicit artifact or workflow. When server source is absent, vendor-documented runtime claims are marked scoped or conditional instead of directly evidenced. Neither status rules out a private or commercial feature.
We selected active, self-hostable memory and context systems. Hosted-only controls are excluded; image hardening is marked not applicable when a project distributes a native server binary instead of a container.
Projects change. Treat this as a reproducible snapshot, re-check the linked source before procurement, and report a stale finding so we can correct it.
Review our security documentation and Trust Center, or contact us with the controls your team needs to validate.