Deploy Mem0 | (Just Updated) Agent Memory REST API, Key Login On From Boot

Mem0 agent-memory REST API on pgvector, API key generated

Deploy Mem0 | (Just Updated) Agent Memory REST API, Key Login On From Boot

Just deployed

/data

Just deployed

/var/lib/postgresql

Deploy and Host Mem0 on Railway

Mem0 is an open-source memory layer for AI agents: it extracts facts from conversations, stores them as vectors, and returns the relevant ones on search. This template runs the Mem0 self-hosted REST server on a pgvector Postgres database with an API key that is generated on deploy, so an agent can store and recall memories over HTTP.

About Hosting Mem0

This template deploys two services: the Mem0 REST server (FastAPI, built from the upstream server/ directory at release 2.2.1 and published as ghcr.io/bon5co/mem0-railway) and pgvector/pgvector:pg17, both pinned by digest. Upstream's own Docker Hub image stopped updating in 2025, so this image is built from the release tag against the matching mem0ai package. Memories are stored in Postgres on a volume at /var/lib/postgresql; the server's history database lives on a second volume at /data, so a redeploy loses nothing.

Authentication is on from the first request. ADMIN_API_KEY is generated on deploy and enforced by the server, so every /memories, /search and /configure call without the X-API-Key header gets 401. On boot the wrapper waits for Postgres, creates the mem0_app auth database and the vector extension if they are missing, and runs the migrations before the server listens, so there is no manual setup step. Telemetry is off. The one value only you can supply is OPENAI_API_KEY: Mem0 calls an OpenAI-compatible API to extract facts and to embed them, and the container refuses to start with a clear log line if the key is empty. The defaults are gpt-5-mini and text-embedding-3-small. To use a gateway or another provider, add OPENAI_BASE_URL, MEM0_DEFAULT_LLM_MODEL and MEM0_DEFAULT_EMBEDDER_MODEL as service variables and redeploy.

Agent contract

  • Public URL: https:// followed by the service domain RAILWAY_PUBLIC_DOMAIN (variable MEM0_PUBLIC_URL holds the full URL)
  • Private URL: http://mem0.railway.internal:8080 (variable MEM0_PRIVATE_URL)
  • Credentials: variable ADMIN_API_KEY (generated); OPENAI_API_KEY is the one value you provide in the deploy form
  • Auth: X-API-Key: $ADMIN_API_KEY on every call except the docs
  • Health: GET /docs returns 200 with no credentials (the server has no separate health route)
  • API: POST /memories, POST /search, GET /memories, GET /memories/{id}, PUT /memories/{id}, DELETE /memories/{id}; interactive reference at /docs
# wait for readiness, then check auth, store a memory and search for it
until curl -fs -o /dev/null "$MEM0_PUBLIC_URL/docs"; do sleep 10; done
curl -s -o /dev/null -w "anonymous: %{http_code}\n" "$MEM0_PUBLIC_URL/memories?user_id=agent1"
curl -s -H "X-API-Key: $ADMIN_API_KEY" -H "Content-Type: application/json" \
  -d '{"messages":[{"role":"user","content":"My name is Raphael and I prefer dark mode."}],"user_id":"agent1"}' \
  "$MEM0_PUBLIC_URL/memories"
curl -s -H "X-API-Key: $ADMIN_API_KEY" -H "Content-Type: application/json" \
  -d '{"query":"what theme does the user like","user_id":"agent1"}' \
  "$MEM0_PUBLIC_URL/search"

Why Deploy Mem0 on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying Mem0 on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.

  • Locked from the first request — a generated API key is enforced by the server; nothing is open to the internet.
  • Memories survive redeploys — both volumes are preconfigured and credentials stay stable.
  • Boots without setup — database, extension and migrations are handled by the container.
  • Private-network ready — other Railway services reach it at the private URL with the same key.

Common Use Cases

  • Long-term memory for coding and chat agents — store user preferences and project facts, search them in the next session.
  • Personalised assistants — one memory store per user id, queried on every turn.
  • Shared memory across agents — several services call the same private URL with one key.

Dependencies for Mem0 Hosting

  • A pgvector Postgres service with a volume at /var/lib/postgresql (included in this template).
  • A volume at /data on the Mem0 service (included in this template).
  • An OpenAI-compatible API key for fact extraction and embeddings.

Deployment Dependencies


Template Content

More templates in this category

View Template
Chat Chat
Chat Chat, your own unified chat and search to AI platform.

okisdev
117
View Template
NEW
Möbius v0.1 Personal AI OS
Self-hosted AI agent that builds and runs apps for you, with memory.

bento
1
View Template
stella
Self-host stella with web, API, Postgres, Redis, and object storage.

Jan Kubica
7