feat(neo4j): evaluate Neo4j Enterprise or dedicated instance for per-consumer isolation (Community edition blocks RBAC)

[izzywdev]

@claude — Neo4j consumer isolation: assess + implement declarative per-consumer provisioning

Context

The shared Neo4j is Community edition (5.26.27), which supports exactly one database (
eo4j) and no \CREATE USER/RBAC (both Enterprise-only). As a result, FuzePlan was wired to the shared
eo4j\ database using the shared
eo4j\ admin credentials — functional but completely unisolated. Every consuming repo shares the same admin credentials and the same single database. This is a security and multi-tenancy gap.

Ask

Research, decide, and implement the right path for per-consumer Neo4j isolation:

Option A — Neo4j Enterprise license (preferred if cost is acceptable)

• Enterprise adds multi-database (\CREATE DATABASE fuzeplan) + RBAC (\CREATE USER fuzeplan_user)
• Update the Helm chart to run Enterprise image
• Add a provisioning Job (same pattern as Mongo ask) that creates per-consumer DB + user from a
  eo4j.consumers\ values list
• Check Neo4j Enterprise licensing (AuraDB Enterprise? Self-hosted Enterprise? Community is Apache 2 → Enterprise is commercial)

Option B — Dedicated Neo4j instance per tenant (if Enterprise cost is prohibitive)

• Add a second Neo4j StatefulSet in the chart (e.g.
  eo4j-fuzeplan) alongside the shared one
• Each consuming repo gets its own instance (full isolation, no license cost)
• Assess resource overhead (Neo4j is heavy — ~1-2 GiB heap per instance)

Option C — Namespace-scoped credentials + prefix convention (stopgap only)

• Keep Community, document that all consumers share the
  eo4j\ DB
• Enforce a node/relationship label prefix per consumer (e.g. \FuzePlan_Task) to avoid collisions
• Accept the security limitation; revisit when Enterprise is justified

Acceptance

• A clear recommendation with cost/resource tradeoff for Options A/B/C
• Whichever option is chosen: implemented as a Helm chart change + provisioning Job, declarative and Git-backed
• FuzePlan wired to its isolated Neo4j DB+user (or documented prefix if Option C)
• All FuzeInfra gate checks pass
• \docs/CONSUMER_ONBOARDING_SHARED_CLUSTER.md\ updated with the Neo4j consumer pattern

Reference

• Current Neo4j StatefulSet: \helm/fuzeinfra/templates/databases.yaml\ (search for neo4j section)
• Current credentials: \uzeinfra-secrets\ (\NEO4J_AUTH\ key, format
  eo4j/)
• FuzePlan's current connection: \�olt://fuzeinfra-neo4j.fuzeinfra.svc.cluster.local:7687, user=
  eo4j, password from fuzeplan-secrets SealedSecret
• Mongo provisioning issue (parallel): see companion issue in this repo (feat(mongo) declarative provisioning)

STATE

• Originating context: FuzePlan deploy; Neo4j isolation was impossible on Community edition — patched with shared admin as stopgap (@claude: provision FuzePlan data-tier (Mongo+Neo4j) + seal fuzeplan-secrets (backend 502, no DB creds) #144)
• Done: FuzePlan connects to Neo4j (shared admin, single DB) — functional but not isolated
• Remaining: proper isolation via one of Options A/B/C above
• If blocked, reply @izzywdev BLOCKED: \ + updated STATE; end with \DONE: .

[claude]

Claude finished @izzywdev's task in 0s —— View job

---

I'll analyze this and get back to you.

[izzywdev]

@claude — your previous run finished in 0s without doing any work. Please retry the Neo4j consumer isolation assessment. Read the original request carefully. Check current state of helm/fuzeinfra/ for any Neo4j isolation work already landed. If the assessment + recommendation was already done in a later PR or issue, summarize the current state and close this issue.

[izzywdev]

⚠️ Claude responder did not run to completion

The responder errored before finishing your request, so no changes were made and no branch was created.

• Reason: Anthropic API rejected preflight (HTTP 400): Your credit balance is too low to access the Anthropic API. Please go to Plans & Billing to upgrade or purchase credits.
• Run log: https://github.com/izzywdev/FuzeInfra/actions/runs/29936788316

This notice is automated and will not retry on its own — the responder stops after one failure and waits. If this looks like an API-side problem (key revoked / out of credits / model or 1M-context beta not entitled / Anthropic outage), an operator should check the ANTHROPIC_API_KEY secret and fund/repair the Anthropic account first, then re-trigger by posting a new comment mentioning the responder.

[izzywdev]

Current state assessment (2026-08-02):

Neo4j is still running Community edition. FuzePlan connects with shared admin credentials as documented in the STATE block. None of Options A/B/C has been implemented yet.

Recommendation for prioritisation: Option B (dedicated instance per tenant) is the pragmatic choice given:

• Neo4j Community is Apache-licensed and free
• Each additional instance costs ~1-2 GiB heap, which is significant but manageable on the current durable nodes
• Enterprise licensing is commercial and cost-uncertain

The Helm chart already runs a StatefulSet for the shared neo4j. Adding a neo4j-fuzeplan StatefulSet with separate credentials is straightforward to implement when prioritised.

Blocking concern: The current durable node OOM situation (per recent incident) means adding another 1-2 GiB heap load before node capacity is resolved would be risky. Recommend scheduling this after the Longhorn/VLAN cutover stabilises capacity.

Leaving open as a valid backlog item.