Agent Memory

Deployment options

Supported ways to run Agent Memory yourself, and the prerequisites for each.

Agent Memory is a single .NET 10 application (API + console + MCP) plus two infrastructure components (PostgreSQL 17 + pgvector, Redis 7). This page summarizes the supported ways to run it and the prerequisites for each.

Components

ComponentRole
API host (AgentMemory.Api)REST /v1/*, MCP /v1/mcp*, console /app/, OAuth, scheduled jobs (Hangfire). Port 8080 in the container.
Console/background host (AgentMemory)Commands such as --migrate; maintenance of idle runs with Runtime:Mode=service.
MCP stdio server (AgentMemory.Mcp)Optional; runs on the client machine.
PostgreSQL 17 + pgvectorThree databases: control plane (agentmemory), shared tenant data (tenant_shared), platform rules (agentmemory_platform). Additional databases for tenants on a dedicated tier.
Redis 7Run (session) layer, replay protection, caches.
OptionalLLM (Anthropic or OpenAI-compatible), embedding provider, email, object storage (erasure ledger archive), OpenTelemetry.

Health endpoints: /health/live, /health/ready (databases, Redis, schema up to date, startup state, OAuth certificates).

1. Local development

scripts/start-dev.sh starts the infrastructure with docker compose (PostgreSQL 5442, Redis 6389), runs migrations and seed data, and serves the API at http://localhost:5199. See Quickstart.

2. Docker image

The repo's Dockerfile builds the console UI and packages the API and the console host in a single image:

  • The entry point is the API; ASPNETCORE_URLS=http://0.0.0.0:8080, unprivileged user.
  • Migrations run with the console host in the same image: dotnet /app/console/AgentMemory.dll --migrate.
  • The development settings file is not included in the image; all configuration is supplied through environment variables (see Configuration).

3. Single server + docker-compose (current production path)

deploy/vm contains a production profile that runs with docker-compose on a virtual machine: PostgreSQL, Redis, a migration job, the API and a log shipper. A reverse proxy/CDN that terminates TLS is expected in front of it. It comes with an environment variable template (env.template) and scripts for backups, alerts, configuration drift checks and tenant restore; incident response and restore runbooks are in the same folder.

For production in this profile you need:

  • Role passwords (APP_RUNTIME_PASSWORD, CONTROL_PLANE_PASSWORD).
  • The built-in OAuth server (issuer + persistent signing/encryption certificates) or an external identity provider.
  • Google/OIDC or email delivery for console sign-in.

4. Azure Container Apps

deploy/azure contains Bicep templates: a Container Apps environment, a registry, PostgreSQL Flexible Server (pgvector), Redis, the API app, a migration job and an optional maintenance app. This path is ready in the repo, but the current production path is the VM profile; before using it, compare the template parameters and database names against the current release.

5. Air-gapped install

The deploy/airgap profile defines an environment with no outbound network access: PostgreSQL, Redis, a local model server (Ollama), migrations, the API, the background host and an nginx as the single entry point. All services sit on a Docker network closed to the outside.

  • With Deployment__AirGapped=true, the service refuses to start if a dependency that would leave the perimeter is configured, and lists the offending keys.
  • The LLM and embeddings come from a local OpenAI-compatible server (Llm__OpenAI__BaseUrl, Embedding__OpenAI__BaseUrl).
  • Authentication is by API key only. For initial access, dotnet AgentMemory.Api.dll --bootstrap-key mints a key inside the perimeter.
  • acceptance.sh is an acceptance script that verifies the install.

Tenant placement

TierWhere the data lives
StandardShared tenant_shared database, row-level security. Default.
Dedicated databaseA tenant-specific database on the same PostgreSQL server; created by the platform.
Dedicated serverA tenant-specific database on another PostgreSQL server; the connection is supplied via configuration and registered by the operator.

Operations notes

  • Run migrations after every release.
  • The erasure ledger is archived off the server (to the configured object storage); after restoring from a backup, --replay-erasures re-applies the deletions.
  • Maintenance of idle runs must run in only one place: either the background host (Runtime__Mode=service) or the API (MemoryMaintenance__Host=api).

Out of scope

There are no Helm/Kubernetes packages, Terraform modules, or customer-managed encryption key (CMK/HSM) integration.

On this page