{"key":"self_hosted_ai_memory_platform_project_outline_2026_03_19","title":"Self-Hosted AI Memory Platform Project Outline","content":"Project outline for a self-hosted AI memory and context platform with a web UI, MCP server access for Codex/Gemini/Claude, and a relational database backend.\n\nCore goal:\nBuild a self-hosted platform that can store memories, notes, prompt templates, and project context; let humans manage them through a clean web UI; let AI tools access them through MCP; use PostgreSQL as the system of record; and support future expansion into search, relationships, and automations.\n\nPrimary use cases:\n- store reusable prompt templates\n- store project notes and decisions\n- store homelab documentation and known fixes\n- let Codex retrieve and update memory during sessions\n- let other AI tools use the same memory base\n- search memories by title, tags, content, and later semantic meaning\n- manage memory records from a browser instead of raw files\n\nNon-goals for MVP:\n- multi-tenant SaaS\n- internet-facing public service\n- complex RBAC\n- billing\n- advanced vector search on day one\n- mobile app\n- polished collaboration features\n\nHigh-level architecture:\n1. Frontend\n- React web app\n- memory list/search page\n- memory detail/edit page\n- template library page\n- settings/admin page\n\n2. Backend API\n- REST or JSON API\n- CRUD for memories\n- CRUD for tags\n- CRUD for templates\n- search/filter endpoints\n- health/status endpoints\n\n3. MCP Server\n- list memories\n- retrieve memory\n- search memories\n- store/update memory\n- list templates\n- retrieve template\n- maybe create/update templates\n\n4. Database\n- PostgreSQL\n- normalized schema for memories, tags, templates, revisions, and relationships\n\n5. Deployment\n- Docker Compose first\n- reverse proxy optional\n- local-only or VPN-only exposure\n- regular DB backups\n\nMVP feature set:\nMemories\n- create memory\n- update memory\n- delete/archive memory\n- title\n- key\n- body/content\n- tags\n- created/updated timestamps\n\nTemplates\n- create prompt templates\n- store by title/key/category\n- render as reusable text blocks\n- separate template records from normal memories\n\nSearch\n- keyword search\n- filter by tags\n- filter by type\n- sort by updated date\n\nMCP tools\n- list_memories\n- get_memory\n- search_memories\n- store_memory\n- list_templates\n- get_template\n\nWeb UI\n- search bar\n- memory table/list\n- tag filters\n- create/edit forms\n- template browser\n- memory detail page\n\nSuggested data model:\nmemories\n- id\n- key unique\n- title\n- content\n- type (memory, template, maybe note)\n- status (active, archived)\n- created_at\n- updated_at\n\ntags\n- id\n- name\n\nmemory_tags\n- memory_id\n- tag_id\n\nmemory_links\n- id\n- source_memory_id\n- target_memory_id\n- relationship_type\n\nrevisions\n- id\n- memory_id\n- content\n- created_at\n- change_note\n\nOptional later:\n- collections\n- workspaces\n- attachments\n- embeddings\n\nAPI outline:\n- GET /health\n- GET /memories\n- POST /memories\n- GET /memories/{key}\n- PUT /memories/{key}\n- DELETE /memories/{key}\n- GET /templates\n- GET /templates/{key}\n- POST /templates\n- PUT /templates/{key}\n- GET /tags\n\nMCP tool outline:\n- list_memories()\n- retrieve_memory(key)\n- search_memories(query)\n- store_memory(key, title, content, tags)\n- list_templates()\n- retrieve_template(key)\nLater:\n- update_template\n- link_memories\n- get_related_memories\n\nFrontend pages:\n- Dashboard\n- Memory Library\n- Memory Detail\n- Template Library\n- Admin / Settings\n\nTech stack recommendation:\n- backend: FastAPI\n- frontend: React\n- database: PostgreSQL\n- ORM: SQLAlchemy + Alembic\n- auth: none for MVP or simple local auth if needed\n- deployment: Docker Compose\n\nPhased build plan:\nPhase 1: Foundation\n- choose project name\n- create repo\n- define schema\n- stand up PostgreSQL\n- build backend skeleton\n- add health endpoint\n- add migrations\n\nPhase 2: Core Memory API\n- create memory model\n- CRUD endpoints\n- tag support\n- basic search\n- archive support\n\nPhase 3: MCP Server\n- expose core memory tools\n- test with Codex\n- test with other MCP clients\n\nPhase 4: Basic Web UI\n- memory list\n- search\n- create/edit form\n- template list\n\nPhase 5: Templates\n- separate template type/category\n- template management in UI\n- MCP template retrieval\n\nPhase 6: Hardening\n- backup strategy\n- audit logging\n- revision history\n- input validation\n- deployment cleanup\n\nPhase 7: Nice-to-Haves\n- semantic search\n- relationships/graph view\n- import/export\n- markdown rendering\n- attachments\n\nOperational requirements:\n- local or VPN-only access\n- daily PostgreSQL backups\n- .env-based config\n- health checks\n- logs\n- migration support\n- restore procedure\n\nKey risks:\n- overbuilding the MVP\n- weak search relevance\n- unclear separation between memories and templates\n- MCP layer drifting from API behavior\n- turning the data model into a dumping ground\n\nSuccess criteria:\n- Codex can retrieve and store memories reliably\n- templates can be managed from UI and retrieved by MCP\n- PostgreSQL is the single source of truth\n- searching is fast and useful\n- the UI is good enough that you actually use it\n- backup/restore is straightforward\n\nRecommended first deliverable:\nBuild the smallest usable slice:\n- PostgreSQL schema\n- backend CRUD for memories\n- MCP tools for list/get/search/store\n- minimal web UI for viewing and editing memories\n\nThat is enough to prove the system.\n\n---\n**2026-03-19 22:32:43 UTC | Created via MCP**","summary":"Project outline for a self-hosted AI memory and context platform with a web UI, MCP server access for Codex/Gemini/Claude, and a relational database backend.\n\nCore goal:\nBuild a self-hosted platform that can store memories, notes, prompt templates, and project context; let humans manage them through a clean web UI; let AI tools access them through MCP; use PostgreSQL as the system of record; and support future expansion into search, relationships, and automations.\n\nPrimary use cases:\n- store reusable prompt templates\n- store project notes and decisions\n- store homelab documentation and known fixes\n- let Codex retrieve and update memory during sessions\n- let other AI tools use the same memory base\n- search memories by title, tags, content, and later semantic meaning\n- manage memory records from a browser instead of raw files\n\nNon-goals for MVP:\n- multi-tenant SaaS\n- internet-facing public service\n- complex RBAC\n- billing\n- advanced vector search on day one\n- mobile app\n- polished collaboration features\n\nHigh-level architecture:\n1. Frontend\n- React web app\n- memory list/search page\n- memory detail/edit page\n- template library page\n- settings/admin page\n\n2. Backend API\n- REST or JSON API\n- CRUD for memories\n- CRUD for tags\n- CRUD for templates\n- search/filter endpoints\n- health/status endpoints\n\n3. MCP Server\n- list memories\n- retrieve memory\n- search memories\n- store/update memory\n- list templates\n- retrieve template\n- maybe create/update templates\n\n4. Database\n- PostgreSQL\n- normalized schema for memories, tags, templates, revisions, and relationships\n\n5. Deployment\n- Docker Compose first\n- reverse proxy optional\n- local-only or VPN-only exposure\n- regular DB backups\n\nMVP feature set:\nMemories\n- create memory\n- update memory\n- delete/archive memory\n- title\n- key\n- body/content\n- tags\n- created/updated timestamps\n\nTemplates\n- create prompt templates\n- store by title/key/category\n- render as reusable text blocks\n- separate template records from normal memories\n\nSearch\n- keyword search\n- filter by tags\n- filter by type\n- sort by updated date\n\nMCP tools\n- list_memories\n- get_memory\n- search_memories\n- store_memory\n- list_templates\n- get_template\n\nWeb UI\n- search bar\n- memory table/list\n- tag filters\n- create/edit forms\n- template browser\n- memory detail page\n\nSuggested data model:\nmemories\n- id\n- key unique\n- title\n- content\n- type (memory, template, maybe note)\n- status (active, archived)\n- created_at\n- updated_at\n\ntags\n- id\n- name\n\nmemory_tags\n- memory_id\n- tag_id\n\nmemory_links\n- id\n- source_memory_id\n- target_memory_id\n- relationship_type\n\nrevisions\n- id\n- memory_id\n- content\n- created_at\n- change_note\n\nOptional later:\n- collections\n- workspaces\n- attachments\n- embeddings\n\nAPI outline:\n- GET /health\n- GET /memories\n- POST /memories\n- GET /memories/{key}\n- PUT /memories/{key}\n- DELETE /memories/{key}\n- GET /templates\n- GET /templates/{key}\n- POST /templates\n- PUT /templates/{key}\n- GET /tags\n\nMCP tool outline:\n- list_memories()\n- retrieve_memory(key)\n- search_memories(query)\n- store_memory(key, title, content, tags)\n- list_templates()\n- retrieve_template(key)\nLater:\n- update_template\n- link_memories\n- get_related_memories\n\nFrontend pages:\n- Dashboard\n- Memory Library\n- Memory Detail\n- Template Library\n- Admin / Settings\n\nTech stack recommendation:\n- backend: FastAPI\n- frontend: React\n- database: PostgreSQL\n- ORM: SQLAlchemy + Alembic\n- auth: none for MVP or simple local auth if needed\n- deployment: Docker Compose\n\nPhased build plan:\nPhase 1: Foundation\n- choose project name\n- create repo\n- define schema\n- stand up PostgreSQL\n- build backend skeleton\n- add health endpoint\n- add migrations\n\nPhase 2: Core Memory API\n- create memory model\n- CRUD endpoints\n- tag support\n- basic search\n- archive support\n\nPhase 3: MCP Server\n- expose core memory tools\n- test with Codex\n- test with other MCP clients\n\nPhase 4: Basic Web UI\n- memory list\n- search\n- create/edit form\n- template list\n\nPhase 5: Templates\n- separate template type/category\n- template management in UI\n- MCP template retrieval\n\nPhase 6: Hardening\n- backup strategy\n- audit logging\n- revision history\n- input validation\n- deployment cleanup\n\nPhase 7: Nice-to-Haves\n- semantic search\n- relationships/graph view\n- import/export\n- markdown rendering\n- attachments\n\nOperational requirements:\n- local or VPN-only access\n- daily PostgreSQL backups\n- .env-based config\n- health checks\n- logs\n- migration support\n- restore procedure\n\nKey risks:\n- overbuilding the MVP\n- weak search relevance\n- unclear separation between memories and templates\n- MCP layer drifting from API behavior\n- turning the data model into a dumping ground\n\nSuccess criteria:\n- Codex can retrieve and store memories reliably\n- templates can be managed from UI and retrieved by MCP\n- PostgreSQL is the single source of truth\n- searching is fast and useful\n- the UI is good enough that you actually use it\n- backup/restore is straightforward\n\nRecommended first deliverable:\nBuild the smallest usable slice:\n- PostgreSQL schema\n- backend CRUD for memories\n- MCP tools for list/get/search/store\n- minimal web UI for viewing and editing memories\n\nThat is enough to prove the system.\n\n---\n**2026-03-19 22:32:43 UTC | Created via MCP**","status":"active","namespace":"general","namespace_name":"general","namespace_tier":"shared","tags":[]}