mirror of
https://github.com/upstash/context7.git
synced 2026-09-14 19:09:34 +08:00
Fahreddin Özcan
305dd3ca10
* docs(enterprise): add multi-container scaling guide Document running On-Premise as multiple replicas with PostgreSQL + object storage. Add the Scaling page under Deployment and cross-reference it from the Kubernetes single-replica notes. * docs(enterprise): migration guide for existing deployments + docker scaling pointer - Scaling page: step-by-step migration using the built-in migrate command (Docker one-shot and Kubernetes Job), vector sync, encryption-key reuse - Docker page: add a Scaling pointer * docs(enterprise): add Settings > Scaling helper screenshots Show the migration helper (single-container) and the multi-replica confirmation in the migration section of the Scaling guide. * docs(enterprise): point Scaling guide at the Helm chart and turnkey compose - Docker Compose: reference the one-command bundled stack (Postgres + MinIO + LB) - Kubernetes: use the Helm chart (single default, scaling.enabled to scale out) - add on-prem / S3-compatible object storage (VECTOR_STORE_ENDPOINT) * docs(enterprise): make Scaling deployment sections self-contained On-prem customers get the image and docs, not the source repo, so inline the full Docker Compose stack (with nginx.conf and .env) and the scaled Kubernetes manifests (Secret + Deployment) instead of referencing repo files. Note the Helm chart ships with the enterprise distribution. * docs(enterprise): pgvector default for scaling, Postgres the only dependency Vectors go to pgvector in the same Postgres, so object storage is no longer required. Update config, compose (pgvector image, no MinIO), k8s secret, and the migration (copies vectors into pgvector, no bucket sync). Object storage is now an optional escape hatch for very large indexes. * docs(enterprise): refresh Settings > Scaling screenshot for pgvector migration command * docs(enterprise): pgvector only, drop the object storage option from the guide Remove the VECTOR_STORE_URI config row and the 'Vectors on object storage' section. Multi-replica uses Postgres + pgvector with no object storage. * docs(enterprise): detailed pgvector provisioning guide Expand the provisioning step with per-provider instructions (RDS/Aurora, Cloud SQL, Azure Flexible Server, self-hosted/Docker), the 0.5.0 HNSW requirement, CREATE EXTENSION, version verification, permission notes, and references. Add a note on how vectors are stored (HNSW cosine, dimension from the model). * docs(enterprise): explain the scaling model in Scale out Every replica serves traffic and indexes; adding replicas grows both. Note how to bound parse-vs-query contention with Max concurrent parses. * docs(enterprise): drop SESSION_SECRET; ENCRYPTION_KEY now signs sessions * docs(enterprise): add scaling sections to docker/kubernetes, link scaling page - kubernetes: new Scaling section (StatefulSet -> Deployment + pgvector, Helm note) - docker: refresh Scaling section (pgvector, turnkey compose) - drop stale object-storage wording, both link to the Scaling guide * docs(enterprise): add architecture diagram and a Helm page - scaling: add an Architecture section with a Mermaid multi-replica diagram - new Helm deployment page (install, scale, ingress, migration, values) - add Helm to deployment nav; link it from the kubernetes and scaling pages * docs(enterprise): move Helm page to its own PR (CTX7-1846) * docs(enterprise): describe per-run Postgres lock instead of leader election Match the code: scheduled jobs take a short advisory lock at fire time so one replica runs each, rather than a persistent elected leader. Drop the leader highlight from the architecture diagram; replicas are interchangeable. * docs(enterprise): add Vector Stores page covering LanceDB, pgvector, and Milvus Dedicated vector-store configuration page: backend comparison, VECTOR_STORE selection, and Milvus / Zilliz Cloud setup. Cross-link from the scaling guide. * docs(enterprise): note library access + SSO groups carry over in migration The migrate command now copies per-library access rules and SSO group memberships (and session epochs) alongside the other tables, so list them in the migration step.