Skip to content

[recipes] Local Docker Open Brain (Qdrant) — multi-tenancy-primed vector store with ACL#334

Open
tomotvos wants to merge 1 commit into
NateBJones-Projects:mainfrom
tomotvos:contrib/tomotvos/local-docker-qdrant
Open

[recipes] Local Docker Open Brain (Qdrant) — multi-tenancy-primed vector store with ACL#334
tomotvos wants to merge 1 commit into
NateBJones-Projects:mainfrom
tomotvos:contrib/tomotvos/local-docker-qdrant

Conversation

@tomotvos
Copy link
Copy Markdown

Contribution Type

  • Recipe (/recipes)
  • Schema (/schemas)
  • Dashboard (/dashboards)
  • Integration (/integrations)
  • Skill (/skills)
  • Repo improvement (docs, CI, templates)

What does this do?

Adds a Qdrant-backed variant of the local-docker recipe that builds the groundwork for an eventual multi-user deployment without sacrificing the single-user local experience.

Why the extra machinery? A single-user pgvector recipe works fine for one person, but as soon as you want to share an Open Brain with teammates — or deploy it as a hosted service — you need user isolation and sharing semantics baked into the data model. Retrofitting that later means a painful data migration. By introducing owner_id, visibility, and shared_with fields on every thought now, and routing every read through a single buildAclFilter() enforcement point, the same code path that runs trivially in local mode (where owner_id is always local-user) is ready to enforce real user isolation when IDENTITY_MODE flips from local to entra (Entra OIDC) in Stage 2 of the multi-tenant roadmap. No data migration is needed at that point — the ACL fields are already on every thought.

What's new compared to the pgvector recipe?

  • 6th MCP tool: share_thought — flips a thought's visibility between private and shared
  • search_thoughts gains a scope parameter (private / shared / all)
  • capture_thought gains a visibility parameter
  • Runs side-by-side with the pgvector stack on different ports (3100 vs 3000) — no conflict
  • A standalone migration script (scripts/migrate-pgvector-to-qdrant.mjs) copies existing pgvector thoughts into Qdrant without re-embedding (same Titan V2 model, vectors are directly portable)

Requirements

  • Docker Desktop
  • AWS account with Bedrock model access for amazon.titan-embed-text-v2:0 and us.anthropic.claude-haiku-4-5-20251001-v1:0
  • AWS CLI configured with a profile that has bedrock:InvokeModel permissions
  • An AI client that supports HTTP-based MCP servers
  • For the migration script only: npm install postgres in the script's directory (the dependency is not in the server's package.json since the server itself never talks to Postgres)

The recipe ARCHITECTURE.md documents the AWS credential handling, ACL filter design, identity modes (local vs entra stub), Qdrant collection schema and payload indexes, and the Stage 1 → Stage 2 migration path.

Notes

Companion to [recipes] Local Docker Open Brain (separate PR). The two recipes are independent — you can run either, neither, or both. The Qdrant recipe does not modify any file in the pgvector recipe.

Checklist

  • I've read CONTRIBUTING.md
  • My contribution has a README.md with prerequisites, step-by-step instructions, and expected outcome
  • My metadata.json has all required fields
  • If my contribution depends on a skill or primitive, I declared it in metadata.json and linked it in the README (no such dependency in this recipe)
  • I tested this on my own Open Brain instance
  • No credentials, API keys, or secrets are included

@github-actions github-actions Bot added the recipe Contribution: step-by-step recipe label May 27, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

recipe Contribution: step-by-step recipe

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant