For teams
All your company context, in one place.
Everything your team knows about how its systems work currently lives in individual people's copilots, individual people's chat history, and individual people's heads. mem-port gives a team one shared memory graph instead: several people, each running whatever copilot they prefer, all reading and writing the same organizational context.
Several people. One workspace. One graph.
A workspace is one isolated knowledge graph, and its name is exactly what a client sends as its library-id header. Everyone whose copilot sends the same library-id reads and writes the same context — regardless of which copilot it is, or whose machine it runs on.
The new teammate's copilot is the point. It connects with the same library-id as everyone else's and starts with the team's accumulated context rather than from zero.
Right now, your company's context is a per-person silo.
Each developer's copilot learns their corner of the system and keeps what it learns to itself. The person who worked out why the checkout service can't use the shared staging database explained it once, to their own copilot, in a session nobody else can read. Next week someone else asks the same question, and their copilot has no idea.
The usual patch is a markdown file in the repo. That helps, until it goes stale — nothing writes to it automatically, everyone has to remember to, and it can't answer a question that was never written down in the exact words you're searching. It is documentation, and documentation decays at the speed of everyone's good intentions.
mem-port is not a document. It is a graph that every connected copilot writes to as a side effect of doing the work, and searches by meaning rather than by keyword. The context accumulates because using it is what maintains it.
What “organizational context” actually means here
It is not a vague pile of company knowledge. mem-port stores five record types, and three of them are the ones a team feels the absence of most sharply.
Decision records
Why is it built this way?
The consequential technical choices, each holding the context that forced the decision, the decision itself, its consequences, and the alternatives that lost. Reversals supersede rather than overwrite, so a year later the log reads as a chain rather than a pile of contradictions. This is the record that most reliably leaves with the person who made it.
Skills
How do we do this here?
Reusable procedures: the deploy steps for a service, how to debug the flaky test in this repo, the release checklist. A skill saved by one person's Claude Code is visible to everyone else's Cursor the moment they connect to the same workspace, with no file format to convert and nothing to copy.
Memories and entities
What is true about this project?
Durable facts, preferences and constraints, each linkable to the projects, services and people they concern. Asking for everything relevant to checkout-service becomes one lookup rather than several searches across several tools.
Episodes, the fifth type, hold the raw sessions the rest gets derived from. All five live in the same graph and travel together in one export.
Who can reach which workspace
A deployed mem-port requires authentication — it switches on automatically the moment the daemon binds anything other than loopback, so a team deployment is closed by default rather than depending on whoever wrote the config.
An admin signs in at /admin and creates workspaces, adds users, issues each of them an API key, and grants those users access to specific workspaces. Clients then send two headers and nothing else about them changes: their key, and the workspace they were granted.
- A workspace is a hard isolation boundary, not a filter. Each maps to its own database, so there is no cross-workspace leakage to get wrong.
- API keys are shown once and stored only as a hash. Revoke and reissue when someone leaves or a key needs rotating.
- Being an admin is not data access. Admins decide who may reach what, which is a different power from reading it — so a stolen admin password exposes the account model rather than every knowledge graph, and an admin who wants a workspace has to grant it to themselves, visibly.
- Each workspace has a read-only graph explorer, which is the quickest way to see what a workspace actually holds and whether a newly connected client is writing anything.
Personal memory stays out of the company graph
This is usually the first objection, and it has a clean answer: library-id is the isolation boundary, so register a separate connection per scope. Same daemon, separate graphs, and your copilot sees each connection's tools separately.
- library-id: personal
- How you like to work — your own preferences, your own background
- Only you
- library-id: org-acme
- Facts, decisions and procedures that apply across the team
- Everyone granted the workspace
- library-id: project-checkout-service
- Context scoped to one project or service
- Whoever works on it
MEMORY_GUIDE.md in the repo carries the per-scope instructions to paste into your copilot's own rules file, so it knows which connection to reach for and what belongs in each.
Running it for a team
A team deployment means two changes from the personal setup, and both are covered in full on the deployment page: a networked database instead of the embedded one, and the accounts above. A container image, a Compose stack per database engine, and Cloud Run manifests all ship in the repo, defaulting to closed.
- Storage is either hosted SurrealDB or Postgres with pgvector — interchangeable, and enforced rather than claimed by a test that asserts both return byte-identical output.
- The embedded default is deliberately not an option here: it writes to local disk, so it loses data on an ephemeral filesystem and lets replicas diverge.
- Nothing about the client side changes. Same tools, same headers, same commands — only the URL differs.
Free, MIT licensed, and yours to run
There is no team tier, no per-seat pricing, and no account to create with anyone. mem-port is MIT-licensed open source that you host, which for an organization matters for a specific reason: your company's accumulated context never sits on someone else's infrastructure, and never becomes leverage in a renewal conversation.
- No pricing, no usage metering, no seat count. The running cost is the database and the host you already chose.
- Read the source before you trust it with your context — the daemon, the tool surface, the admin panel and the tests are all public.
- export_library writes an entire workspace to one portable JSON bundle, so leaving is a file copy rather than a migration project. That is the same namesake portability the personal version has, applied to a team's graph.
What it does not do yet
Stated plainly, because this audience will ask and would find out anyway.
No SSO
There is no OIDC or SAML integration. Admins sign in to the panel with a username and password, and clients authenticate with issued API keys. If your organization requires SSO for anything holding internal context, this is the blocker to weigh first.
No audit log
There is no record of who read or wrote what. The graph explorer shows you a workspace's current contents, not its history of access.
Access is per workspace
A grant gives a user a whole workspace. There are no per-record or per-record-type permissions, so anything one person can reach in a workspace, everyone granted it can reach. Split by workspace where that matters.
Admin logins are not rate limited
Nothing throttles repeated sign-in attempts against the admin panel yet. Put it behind whatever your infrastructure already uses for that, as the supplied manifests do by keeping it closed at the network layer too.
Try it as one person first.
The fastest way to evaluate this for a team is to run it locally for yourself for a week — no database, no accounts, no configuration — and see what your own copilots accumulate. The team setup is the same product with a networked database and accounts in front of it.
MIT licensed · no paid tier · no account