Self-hosted vs managed company brain: how to choose
Self-hosting gives control and costs engineering time. A managed brain gives speed, scoped access and sources. Here is a plain way to decide which fits.
Choose self-hosted if you need control over where data lives or how memory works, and you have people who will run it. Choose managed if you mainly want your agents to know what your team knows and would rather not own the servers. For most small teams already using AI agents, managed is the faster route and saves the most time.
Both are legitimate. This guide lays out when each one wins, so you can decide without a sales pitch.
What "company brain" means here
A company brain is one shared memory that every teammate's agent reads from and writes to: facts from meetings, email and calendar, each with a source. If the term is new, start with what is shared memory for AI agents.
"Self-hosted" means you install and run the software yourself, on your servers, with your own database and model keys. "Managed" means a provider runs it and you connect to it.
When self-hosting makes sense
Self-hosting is the right call in these cases:
- Data control is a requirement. Your policies or customers require data to stay on infrastructure you operate.
- You have engineering capacity. Someone on the team wants to run it and has time for it.
- You need to customise. You want to change how memory is stored, ranked or connected to internal systems.
- You want to pick every model and connector. You are comfortable owning the choices.
- You are experimenting. Tinkering with an open tool teaches you how agent memory works.
If most of these describe you, self-hosting is a good investment, not a burden.
When managed makes sense
Managed is the better choice when:
- Nobody wants an infrastructure project. The goal is working agents, not a service to keep alive.
- You want to start today. Setup is a sign-in, not a deployment.
- You want predictable effort. No hosting, model keys or retries to watch.
- The sources are standard. Your team lives in Google Workspace and meetings.
- Your team is small. Three to twenty-five people rarely justify a dedicated owner.
The hidden part of self-hosting
The decision usually turns on one question: who is on the hook when it breaks? People who run self-hosted memory tools report a recurring set of problems in public issue trackers: fresh installs that need workarounds, upgrades that need manual repair, settings that are ignored, and background jobs that fail without anyone noticing. A public example is a documented configuration being silently ignored.[1] These are common experiences with self-hosted memory layers, and the maintainers of those projects work on them.
That is not an argument against self-hosting. It is the cost of control. If you have the people, it is a fair trade. If you do not, it becomes the founder's weekend. For the details, see shared agent memory without a server-maintenance side project and what agent memory actually costs.
Side-by-side
| Question | Self-hosted | Managed |
|---|---|---|
| Who runs it | You | The provider |
| Time to first value | Hours to days | Minutes |
| Data location | Your infrastructure | Hosted by the provider; your company owns its workspace |
| Customisation | Your code, your changes | Configured through the product |
| Upgrades | Yours | The provider's |
| What you carry | Hosting, model usage, time | Nothing to run |
| Meeting capture | You wire in a notetaker | Built in with Nysa |
A quick decision rule
Answer these four questions honestly.
- Does policy require the data to stay on infrastructure you operate? If yes, self-hosting is built for that.
- Do you have someone who will own it for the next year? If no, go managed.
- Do you need behaviour no product offers? If yes, self-host.
- Is your team on Google Workspace and mainly using meetings, email and calendar? If yes, managed fits.
If you get mixed answers, start managed. It is the reversible choice: you can try it in an afternoon and move to self-hosting later if you outgrow it. Starting self-hosted and walking it back costs more.
Where Nysa fits
Nysa is the managed option. It turns meetings, Gmail and Google Calendar into facts with sources, and serves them to Claude, ChatGPT, Cursor, Codex, OpenClaw, Hermes and other MCP agents. Each agent sees only what its teammate can see, and agents can read and write. Setup takes under 5 minutes.
What you get: Nysa's own notetaker, 180 days of email and calendar history on day one, a page for every person and company, every fact cited to its source, and access scoped so each agent sees only what its teammate can see. Your company owns its workspace, and your data is never sold or used to train AI. Nysa works with Google accounts today. If you are weighing it against a self-hosted tool, the Nysa vs GBrain page goes through it point by point.
FAQ
Can I start managed and move to self-hosted later?
Yes, and it is usually the faster order. Trying a managed service takes an afternoon. If you later need control it cannot give you, you will know exactly what requirements to build for.
Is self-hosted more private than managed?
It gives you more control over where data lives, which some teams require. Privacy also depends on how access is scoped. Nysa scopes every fact: each agent sees only what its teammate can see, raw email stays private to its owner, and your data is never sold or used to train AI.
How do I know if my team has the capacity to self-host?
Ask who will handle upgrades, failed jobs and expired credentials for the next year, and what they will stop doing to make time. If you cannot name a person, you probably do not have the capacity yet.
Sources
- Graphiti GitHub issue 1736, https://github.com/getzep/graphiti/issues/1736, checked Oct 6 2026. ↩