For the complete documentation index, see /developers/llms.txt Markdown versions: append .md to any /developers/{slug} URL. Browse structure: /developers/sitemap.md This page: /developers/deployment-model.md

Deployment model

In plain terms: Eigen Mesh works the same whether Eigen hosts it for you or you run it on your own server. You always own your memories. The only difference is who manages the infrastructure and billing setup.

Who this is for

  • End users wondering whether managed or self-hosted matters for day-to-day use — it does not change the product you see.
  • Operators deciding how to deploy and who configures servers and API keys.
  • Contributors understanding why there is a single codebase for both modes.

What "deployment model" means for you

Mode Who runs servers Who owns your data Typical user
Managed Eigen You Sign up, capture thoughts, optional BYOK
Self-hosted You (operator) You Operator provisions Docker; users sign in normally

Same features, same behavior, same product contracts. Only operator and infrastructure size differ.


Technical details

Why this document exists

We need a stable product stance before continuing architecture work:

  • Is Eigen primarily self-hosted, managed, or both?
  • Who owns the data/database per user?

Product stance

1) Codebase role

The eigen product repository is the single canonical product for both self-hosted and managed deployment.

  • Same features.
  • Same behavior.
  • Same product contracts.
  • Only operator and infrastructure size differ.

2) Ownership model

User owns data by default in all modes.

  • Self-hosted mode: user/operator owns infrastructure and data plane.
  • Managed mode: we operate infrastructure; user still owns data and must have export/delete guarantees.

3) Tenancy pattern

No product-level split is introduced between deployment types.

  • Tenancy and permissions are implemented once in the shared product logic.
  • Self-hosted and managed run the same code paths.
  • Any future divergence requires an explicit product decision.

Architecture direction

Postgres (Drizzle) for:

  • Better Auth users/sessions/accounts
  • transactional app records and activity/cost logs
  • thought store, embeddings, lexical search (pgvector), and policy enforcement

Apache AGE (same Postgres) for:

  • graph-native memory structure and traversals (OpenCypher via ag_catalog)
  • entity/thought/event nodes and relationship edges
  • graph expansion in retrieval

Decision policy

  1. No feature gating by deployment type at this stage.
  2. No behavior split between self-hosted and managed at this stage.

Troubleshooting

Deployment-mode questions rarely cause runtime errors. For operational issues, see Troubleshooting.

Next steps

Agent Instructions

This documentation is published for humans and AI agents. Prefer .md URLs for structured content.

  • Index: /developers/llms.txt
  • Full export: /developers/llms-full.txt
  • Sitemap: /developers/sitemap.md
  • Raw page: append `.md` to any /developers/{slug} URL
  • Example: GET /developers/mcp-overview.md

Dynamic `?ask=` and `?goal=` query on markdown URLs is planned — see docs/planning/10-docs-query-api-design.md.