Postgram

A self-hosted productivity and knowledge backend for humans and AI agents.

Website · Quick start · MCP guide · REST API · Demo

Postgram keeps the data you and your agents work from in one inspectable place: notes, documents, tasks, people, projects, interactions, decisions, and agent memory. Humans use the browser UI and CLI; agents use the same corpus over MCP, REST, or the CLI.

It is more than an agent-memory layer. Postgram preserves typed source objects, supports GTD-style task management and Markdown folder sync, combines full-text and vector retrieval with a knowledge graph, and separates short-lived agent working context from durable memory.

Watch the demo

Search across memories, documents, people, projects, and tasks

Why Postgram

• One private corpus across tools. Give different agents and devices access to the same data without tying it to one editor or hosted memory provider.
• Inspectable source data. Store typed entities instead of opaque chat summaries, then search, edit, link, archive, or delete them yourself.
• Search before graph expansion. Hybrid retrieval finds relevant entities; edge summaries tell an agent when related graph context is worth following.
• Working context is not durable memory. Session context has its own scope and lifecycle; grooming can archive it or distill selected context into durable memory.
• Operator control. Choose where PostgreSQL runs, which embedding and extraction providers are allowed, who receives API keys, and what is kept.

Postgram is built for one person or a small trusted team running a local or single-VM deployment. It is not a hosted service or a multi-tenant SaaS platform. Knowledge extraction is optional, and the provided Docker Compose setup binds the raw API and UI ports to loopback by default.

Quick Start (Docker Compose)

You need Git, Docker, and Docker Compose. Node.js 22+ is needed only for local development or for installing the pgm CLI; gpg is needed only for encrypted CLI backups.

1. Clone Postgram:

   bash

   Copy

   git clone https://github.com/ivo-toby/postgram.git
   cd postgram
   

2. Choose an embedding path before the first start. For the local default, install and start Ollama on the Docker host, then pull Postgram's default embedding model:

   bash

   Copy

   ollama pull bge-m3
   

   For hosted OpenAI embeddings instead, create a .env file containing a real key before starting Compose:

   dotenv

   Copy

   OPENAI_API_KEY=<your-openai-key>
   

3. Start the stack:

   Terminal

   Copy

   docker compose up -d --build
   

   The first run creates persistent Docker volumes for PostgreSQL and installation secrets. No .env file is required for the default Compose path.

4. Read the one-time bootstrap token:

   Terminal

   Copy

   docker compose logs mcp-server \
     | grep 'Bootstrap token:' \
     | tail -n 1
   

   The plaintext appears only in the original first-start logs. Capture it before recreating the API container or discarding those logs.

5. Open http://127.0.0.1:3000/admin, paste the token, create the first admin, enroll MFA, and follow the onboarding flow.

6. Confirm the selected provider in the Admin Config tab. If you add or change staged settings, save, validate, and apply them, then restart mcp-server when Admin marks a restart as required:

   Terminal

   Copy

   docker compose restart mcp-server
   

   When Ollama runs on the Docker host, its base URL is http://host.docker.internal:11434. Optional LLM relationship extraction is disabled by default and can use OpenAI, Anthropic, Ollama, or an OpenAI-compatible endpoint. Changing the embedding provider, model, or dimensions after the first start is migration work and is blocked from a simple config apply.

7. Check health, then create an API key in the Admin Overview tab. For the smoke test below, allow read and write, the memory entity type, and personal visibility:

   Terminal

   Copy

   curl -fsS http://127.0.0.1:3100/health
   

   The response should include "status":"ok" and "postgres":"connected".

8. Install the CLI and verify an authenticated write and search. Enrichment is asynchronous, so wait for pgm queue to report no pending work before the search:

   Terminal

   Copy

   npm install -g @ivotoby/postgram-cli
   export PGM_API_URL=http://127.0.0.1:3100
   export PGM_API_KEY='<plaintext-api-key>'
   
   pgm store "Postgram quick start is working" \
     --type memory \
     --visibility personal \
     --tags quickstart
   pgm queue
   pgm search "quick start"
   

If embeddings are unreachable, Postgram still starts and accepts writes, but enrichment and search will fail until the provider is available. See the full quick start and troubleshooting guide for the longer path.

For access from ChatGPT, Claude, or another remote MCP client, put Postgram behind HTTPS, enable OAuth, and follow the MCP integration guide. Do not publish the loopback development ports directly to the internet.

What It Does

Postgram provides:

• durable storage for typed entities: memory, person, project, task, interaction, document
• hybrid BM25 + vector search with asynchronous enrichment
• knowledge graph with typed directional edges between entities
• LLM-powered relationship extraction (OpenAI, Anthropic, or Ollama)
• document sync from local markdown repos via manifest comparison
• browser interfaces for knowledge work and guarded administration
• UMAP and PCA projections of embedded entities
• GTD-style capture, task organization, and Kanban views
• scoped API-key authentication and visibility restrictions
• a REST API for application and automation access
• a Streamable HTTP MCP endpoint for agent-native tool access
• a CLI (pgm) for humans and agents
• a container-local admin CLI (pgm-admin)
• Talon SQLite migration tooling
• encrypted backup support
• audit logging for mutating and privileged operations

How It Works

Postgram is a TypeScript Node.js application built around a service layer.

Main components:

• PostgreSQL + pgvector for persistence and vector search
• Hono for the HTTP server
• MCP over Streamable HTTP for agent-facing tool access
• CLI/admin CLIs built with Commander
• background enrichment worker for chunking, embeddings, and LLM extraction

High-level flow:

1. a client stores or updates an entity
2. the entity is written immediately
3. enrichment runs asynchronously: chunking, embedding, and optionally LLM extraction
4. chunks and embeddings are produced in the background
5. edges are created from extracted relationships (if extraction is enabled)
6. search queries use hybrid BM25 + vector scoring, with optional graph expansion

Main Features

1. Typed Knowledge Storage

Store structured knowledge objects with:

• type (memory, person, project, task, interaction, document)
• content
• tags
• visibility (personal, work, shared)
• status
• arbitrary JSON metadata

Memory Roles

Postgram supports two roles for memory entities:

• durable_memory: long-term memory future agents should trust, such as decisions, preferences, constraints, root causes, and completed-work summaries.
• session_context: working context for resuming recent conversations. Session context is scoped to the calling client, embedded for semantic recall, and skipped by graph extraction.

Use session context for "where were we in this thread?" Use durable memory for "what should future agents remember as true?"

CLI users can write session context with pgm memory session-context and search it with pgm search --memory-role session_context.

Operators can groom stale session context with pgm-admin memory groom. Use --client-id <client-id> for one client or --all-clients to batch over every session-context scope. --all-clients keeps each client scope separate; it is operational batching, not cross-client consolidation. --older-than <duration> defaults to 7d and accepts values like 30m, 4h, 7d, or 0d. --dry-run previews eligible memories without calling the LLM. Grooming has no default candidate cap; pass --limit <n> when you want to process a bounded batch. --mode archive --yes archives eligible working context directly. --mode promote --yes uses the configured extraction LLM to decide whether each session-context memory should be promoted; promoted memories are distilled into new durable_memory entities, the source context is archived, and provenance is recorded with metadata.promoted_to plus a promoted_to edge.

Authenticated users and agents can self-groom only their own client-scoped session context:

pgm memory groom --dry-run --older-than 7d
pgm memory groom --older-than 14d --topic postgram --tag session-context --yes