Self-hosting and migration

The two tiers

Storage is an adapter, and the same schema and SQL run on both.

Tier	Storage	Select with
Embedded (default)	PGLite, a folder at `~/.memloom/data`	Nothing
Server	Real Postgres with pgvector, pooled	`MEMLOOM_PG_URL`

Embedded is the right default: nothing to run, and backup is copying a folder. Move to server when you want concurrent database access, a store too big for one folder, or one shared across machines.

Backing up the embedded store

memloom stop
cp -r ~/.memloom/data ~/backups/memloom-2026-07-12

Stop first so the directory is quiescent. Restoring is the reverse. config.env travels separately.

Running on Docker Postgres

Start Postgres with pgvector

services:
  db:
    image: pgvector/pgvector:pg17
    environment:
      POSTGRES_PASSWORD: memloom
    ports:
      - "5432:5432"
    volumes:
      - memloom-data:/var/lib/postgresql/data
volumes:
  memloom-data:

Point memloom at it

One line in ~/.memloom/config.env:

MEMLOOM_PG_URL=postgresql://postgres:memloom@localhost:5432/postgres

Start

memloom serve. The first init() creates the whole schema on an empty database, so there is no provisioning step. The CLI, MCP and viewer all follow the same config.

Two differences from embedded: the data-directory lock is unused, since Postgres handles concurrency, and the daemon does not start the wire bridge. Inspect the server directly.

Embedding memloom as a library

import { Memloom, PgAdapter } from "@memloom/core";

const storage = await PgAdapter.connect(
  "postgresql://postgres:memloom@localhost:5432/postgres",
);
const memloom = new Memloom({ storage, embedding, llm });
await memloom.init();

pg is an optional dependency, so run pnpm add pg in the project that uses this.

Migrating existing data

Re-ingest is the simple path and loses history. Point the new store at the same embedding config and replay your sources. For a store that is mostly ingested documents this is usually enough, since documents are mirrors and re-ingesting reproduces them exactly. Copy the rows keeps everything. With the daemon running, pull through the wire and load into the target:

pg_dump -h 127.0.0.1 -p 54329 -U postgres -d postgres --data-only > memloom-dump.sql
psql   -h 127.0.0.1 -p 5432  -U postgres -d postgres -f memloom-dump.sql

Create the target schema first by starting memloom serve once with MEMLOOM_PG_URL set, then load data-only.

If pg_dump trips over the wire bridge

The bridge is a single-connection path into PGLite. Fall back to per-table COPY ... TO STDOUT through psql, in dependency order:_memloom_meta, memory_objects, memory_schema, memory_entities, memory_edges, memory_dedup_decisions, context_documents, context_chunks, memory_index_runs, memory_index_events, assistant_sessions, assistant_messages.Skipping the later tables silently drops your schema vocabulary, indexing history and assistant chats.

The embedding fingerprint travels with the data. The engine you run against a migrated store must use the same embedding provider, model and dims, or init() refuses to open it. See Configuration.

What stays local

Whichever tier you run, the HTTP API binds to 127.0.0.1, CORS admits only localhost origins, and the only outbound traffic goes to the provider you configured. Self-hosting the database in Docker does not expose memloom to the network unless you publish the ports yourself.

Getting Started

Concepts

Guides

Self-hosting and migration

The two tiers

Backing up the embedded store

Running on Docker Postgres

Migrating existing data

What stays local

​The two tiers

​Backing up the embedded store

​Running on Docker Postgres

​Migrating existing data

​What stays local

The two tiers

Backing up the embedded store

Running on Docker Postgres

Migrating existing data

What stays local