Deployment-Modell
Kurz gesagt: Eigen Mesh funktioniert genau gleich, egal ob Eigen es für dich hostet oder du es auf deinem eigenen Server betreibst. Deine Erinnerungen gehören immer dir. Der einzige Unterschied ist, wer die Infrastruktur und das Billing verwaltet.
Für wen das relevant ist
- Endnutzer, die sich fragen, ob Managed oder Self-hosted für den täglichen Gebrauch einen Unterschied macht — tut es nicht, das Produkt, das du siehst, bleibt gleich.
- Operatoren, die entscheiden, wie deployt wird und wer Server und API-Keys konfiguriert.
- Contributor, die verstehen wollen, warum es für beide Modi eine einzige Codebasis gibt.
Was „Deployment-Modell" für dich bedeutet
| Modus | Wer betreibt die Server | Wem gehören deine Daten | Typischer Nutzer |
|---|---|---|---|
| Managed | Eigen | Dir | Anmelden, Thoughts erfassen, optional BYOK |
| Self-hosted | Du (Operator) | Dir | Operator provisioniert Docker; Nutzer melden sich normal an |
Gleiche Features, gleiches Verhalten, gleiche Produktverträge. Nur Operator und Infrastrukturgröße unterscheiden sich.
Technische Details
Warum dieses Dokument existiert
Wir brauchen eine belastbare Produkthaltung, bevor die Architekturarbeit weitergeht:
- Ist Eigen primär self-hosted, managed oder beides?
- Wem gehören Daten/Datenbank pro Nutzer?
Produkthaltung
1) Rolle der Codebasis
Das eigen-Produkt-Repository ist das einzige kanonische Produkt für Self-hosted- und Managed-Deployment.
- Gleiche Features.
- Gleiches Verhalten.
- Gleiche Produktverträge.
- Nur Operator und Infrastrukturgröße unterscheiden sich.
2) Ownership-Modell
Der Nutzer besitzt die Daten standardmäßig in allen Modi.
- Self-hosted-Modus: Nutzer/Operator besitzt Infrastruktur und Datenebene.
- Managed-Modus: Wir betreiben die Infrastruktur; der Nutzer besitzt weiterhin die Daten und muss Export-/Löschgarantien haben.
3) Tenancy-Muster
Zwischen den Deployment-Typen wird kein produktseitiger Split eingeführt.
- Tenancy und Berechtigungen werden einmal in der gemeinsamen Produktlogik implementiert.
- Self-hosted und Managed durchlaufen dieselben Code-Pfade.
- Jede zukünftige Abweichung erfordert eine explizite Produktentscheidung.
Architekturrichtung
Postgres (Drizzle) für:
- Better-Auth-Nutzer/-Sessions/-Accounts
- transaktionale App-Datensätze sowie Activity-/Kosten-Logs
- Thought-Store, Embeddings, lexikalische Suche (
pgvector) und Policy-Enforcement
Apache AGE (dieselbe Postgres-Instanz) für:
- graph-native Memory-Struktur und Traversierungen (OpenCypher über
ag_catalog) - Entity-/Thought-/Event-Knoten und Beziehungskanten
- Graph-Erweiterung im Retrieval
Entscheidungspolitik
- Kein Feature-Gating nach Deployment-Typ in dieser Phase.
- Kein Verhaltens-Split zwischen Self-hosted und Managed in dieser Phase.
Troubleshooting
Fragen zum Deployment-Modell führen selten zu Laufzeitfehlern. Für operative Probleme siehe Troubleshooting.
Nächste Schritte
- Onboarding & Setup — Managed-Anmeldung oder Provisionierung durch den Operator
- Überblick & Schnellstart — Self-hosted-Docker-Deployment
- Architekturüberblick — Systemdomänen und Datenfluss