Roadmap: Multi-Tenancy Posture and Fleet Provisioning

Gap statement: no tenancy story at all — and a decision before an engineering program

Wikantik is single-tenant per install, deployed on a single Docker host, with no hosted offering. "RAG as a service" implies serving multiple customers. The question is not whether to have a tenancy story but which one: shared-store logical multi-tenancy (deep schema surgery across every table and index) or silo-per-tenant (one isolated deployment per customer, automated into a fleet). This brief argues for the silo posture and defines the fleet-engineering program it implies.

Owner gate: the posture commitment itself is an [OWNER] decision. An agent may draft the ADR with the argument below; only the owner ratifies it. Nothing beyond the cost-floor measurement should be built before ratification.

AWS states its metadata-filter multi-tenant pattern provides only logical isolation; for a compliance boundary between customers it recommends a dedicated knowledge base per tenant (AWS multi-tenant RAG).
Microsoft's multitenant RAG reference architecture defines store-per-tenant vs shared stores, warns store-per-tenant off only for very large numbers of small tenants (B2C), and requires: identity flowing through the entire request chain, a gatekeeper API in front of all tenant data access (no direct store queries), and audit logs of grounding data access (Azure secure multitenant RAG guide).
Pinecone's documented pattern is namespace-per-tenant physical partitioning; metadata-filter isolation hits hard limits ($in capped ~10,000 values) (Truto on multi-tenant RAG isolation). The silo counter-argument: per-tenant indexes waste infrastructure at scale because most sit idle.
Enforcing isolation via the LLM or application-layer filtering is an anti-pattern; isolation must be deterministic at the data layer (same source).

The strategic read: Wikantik's Docker deployment already is the hard-isolation unit AWS tells enterprises to buy. For a single-maintainer project targeting B2B (not B2C-scale tenant counts), silo-per-tenant converts the biggest architectural liability (single-host, single-tenant) into the compliance-friendly product shape — if provisioning is automated.

Current Wikantik state

One production deployment (docker1) driven by bin/remote.sh + remote.env; .env-templated config; bin/deploy-local.sh renders config from templates.
Idempotent database bootstrap (bin/db/install-fresh.sh) and versioned migrations (bin/db/migrate.sh) — per-tenant DB provisioning is already scripted in embryo.
Off-box backup (3-2-1 NAS pull) exists for the single prod host.
No control plane, no per-tenant secrets management, no centralized upgrade orchestration, no per-tenant monitoring rollup (monitoring lives in the separate jakemon repo).

Proposed direction

Draft the posture ADR for owner ratification ([OWNER] gate above): silo-per-tenant for hard isolation; shared-store multi-tenancy explicitly out of scope until tenant count demands it.
Tenant-in-a-box artifact: a versioned compose/stack definition (app + PostgreSQL + pgvector + optional Ollama) with one-command spin-up, templated secrets, and health verification.
Fleet control plane (minimal): inventory of tenants, orchestrated rolling upgrades (image pin per tenant), central backup scheduling, per-tenant monitoring scrape into one dashboard.
Shared inference pool: Ollama is the heaviest per-tenant cost; investigate one shared GPU inference host serving many tenant instances with per-tenant rate limits.
Gatekeeper alignment: per-tenant API keys and MCP tokens already exist; ensure they are provisioned/rotated by the control plane, not by hand.

Phase 1 scope and acceptance criteria

First session scope (pre-ratification, measurement only): measure the per-tenant cost floor — idle and loaded footprint of one full stack. No provisioning code.

Measurement phase is done when: a committed script (under bin/ or eval/) reproducibly reports JVM heap under idle/loaded profiles, PostgreSQL size for a reference corpus, dense-index memory, Docker image sizes, and idle CPU — and the numbers are written up beside RoadmapPackagingAndPricing's unit-economics input.

Phase 2 (post-ratification) is done when: tenant-in-a-box spin-up on a clean host is one command; the health-check suite passes against the fresh instance; a smoke IT creates/retrieves a page through the full stack; teardown leaves no residue; and secrets are templated, never committed.

Verify before designing on these

The AWS and Azure recommendations describe their products' isolation models; they support the silo argument by analogy, not as authority over this codebase.
The $in ~10,000 cap (shared with RoadmapExternalAclInheritance) — verify against current documentation before it appears in the ADR.
"Per-tenant silos waste idle infrastructure at scale" — quantify with the measured cost floor before treating it as a real constraint at the tenant counts actually expected.

Non-goals

No shared-store multi-tenancy, no tenant_id columns, no row-level-security retrofit — anywhere (see the RoadmapTargetArchitecture tenancy invariant).
No billing/entitlement machinery — that is RoadmapPackagingAndPricing, owner-gated.
No B2C-scale tenant-count engineering.

Investigation starting points

[MEASURE] Per-tenant cost floor: the Phase-1 measurement above. This number drives pricing (RoadmapPackagingAndPricing) and the silo-vs-shared breakeven.
[OWNER] Control-plane build vs buy (plain Ansible/Terraform vs a small purpose-built service) — spend and operational-commitment decision; agent prepares the comparison for 10- and 50-tenant scenarios.
[AGENT] Upgrade path mechanics: schema migrations across a fleet where tenants pin different versions; canary-tenant pattern.
[AGENT] Multi-tenant Ollama design (isolation of embedding/extraction queues per tenant; failure blast radius — the fail-closed BM25 fallback already bounds retrieval damage); [MEASURE] the contention behavior under concurrent tenant load.
[OWNER] Data residency as a marketed feature — a positioning decision for the marketing site, not an engineering task.