Deployment
Four ways to run a memory.
The same memory runs in four postures — the application is identical in all four. What changes is where your knowledge physically sits, which is usually the question a security review actually cares about.
Shared memory Live
The SaaS tier. Many organisations share one set of engines, separated by a scope applied to every single query.
Why choose it. Nothing to operate, lowest cost per unit of knowledge, and no migration risk later — the integration surface is identical across all four types, so starting here locks you out of nothing.
The trade-off. Isolation is logical, not physical. It is enforced on every query and proven in CI, but it is enforced in software.
Dedicated memory Live
Your own engines, in your own namespace, still operated by Chordian.
Why choose it. Physical separation without operational burden — different databases, not different rows — plus predictable performance with no noisy neighbour.
The trade-off. Your content is still on Chordian’s infrastructure. This reduces blast radius, not vendor access.
Own server Validated
The memory engine runs on a Linux server you own. Chordian orchestrates it and never stores your knowledge.
Why choose it. “Where does our data live?” gets a physical answer. A vendor breach exposes nothing, a subpoena to us produces nothing, and compliance becomes structural rather than procedural — while still feeling like SaaS to operate.
The trade-off. Backup is currently your responsibility — a built-in backup and restore flow is not shipped. Connector credentials also stay platform-side, because the OAuth redirect completes there.
Own cloud AWS · DO GCP · Azure
The same sovereignty, provisioned into your own cloud account.
Why choose it. Sovereignty without a data centre, landing inside your existing cloud governance — your tagging, your budgets, your security tooling, your existing cloud agreement. Own-infrastructure memories also carry a reduced per-operation rate, because you already pay your own cloud bill.
The trade-off. AWS and DigitalOcean are live-validated; GCP and Azure are available on request but not yet self-serve-proven. The same backup caveat applies.
Side by side
Choosing.
| Shared | Dedicated | Own server | Own cloud | |
|---|---|---|---|---|
| Content on Chordian | Yes | Yes | No | No |
| Isolation | Logical | Physical | Off-premises | Your account |
| You operate infrastructure | No | No | The host | The account |
| Vendor can read content | Yes | Yes | No | No |
| Survives a vendor breach | — | — | Yes | Yes |
| Residency guarantee | Region | Region | Physical | Your region |
| Per-operation cost | Standard | Standard | Reduced | Reduced |
| Backup included | Yes | Yes | Not yet | Not yet |
Start shared
Unless something forces otherwise. It costs least and you are not painting yourself into a corner.
Move to dedicated
For noisy-neighbour or blast-radius concerns. Separate engines, still operated by us.
Move to own-infrastructure
When the answer to “where does our data live” must be “here”.
Processing
Where the reasoning happens.
Storage sovereignty and processing sovereignty are different guarantees. Conflating them is the most common way this conversation goes wrong.
| Mode | Where inference runs | Does content leave the box? |
|---|---|---|
| Chordian proxy (default) | Our proxy, reached only over the tunnel | Yes — it transits Chordian to reach the model vendor |
| Bring your own | Your own endpoint or key | No — only to the provider you already trust |
| In-box model Roadmap | Inside the box | Never leaves |
A sovereign box with no egress configured fails loud. It refuses to process rather than quietly falling back to a public API — the failure mode that would otherwise turn a sovereignty guarantee into a sovereignty claim.
Not sure which one you need?
Most organisations know their constraint but not which deployment satisfies it. Tell us the constraint and we will tell you the answer — including when it is the cheapest one.