Skip to content

Profiles and Team Usage

Jump to bottom
Doug Gerard edited this page May 14, 2026 · 1 revision

Profiles and Team Usage

SaddleRAG supports both individual developer setups and shared team deployments. The mechanism that makes both work is the profiles system — named MongoDB connection configurations that let a single SaddleRAG instance serve multiple independent databases simultaneously.

Single developer setup (default)

Out of the box, SaddleRAG connects to a single MongoDB database on localhost. No profiles configuration is needed. The default profile is called local:

"MongoDB": {
  "ActiveProfile": "local",
  "Profiles": {
    "local": {
      "ConnectionString": "mongodb://localhost:27017",
      "DatabaseName": "SaddleRAG"
    }
  }
}

All libraries you index are stored in this database. All MCP tool calls without a profile parameter use this database.

This is the right setup for a single developer who doesn't need to share their documentation index with anyone.

Shared team setup

When multiple developers want to share a documentation index, the setup adds a shared MongoDB instance and a named profile pointing to it.

Architecture

Developer A (laptop)                Developer B (laptop)
┌──────────────────┐               ┌──────────────────┐
│ Claude Code      │               │ VS Code Copilot  │
│   profile=local  │               │   profile=team   │
└────────┬─────────┘               └────────┬─────────┘
         │ MCP                              │ MCP
         ▼                                  ▼
┌──────────────────────────────────────────────────────┐
│              SaddleRAG MCP Server                    │
│         (running on shared server or one dev machine)│
└──────────────────┬───────────────────────────────────┘
                   │
        ┌──────────┴───────────┐
        ▼                      ▼
┌──────────────┐      ┌──────────────────┐
│  local DB    │      │  team DB         │
│ localhost    │      │ db.internal:27017│
│ (dev's own)  │      │ (shared)         │
└──────────────┘      └──────────────────┘

Configuration

Add the shared profile to appsettings.json:

"MongoDB": {
  "ActiveProfile": "local",
  "BootstrapAllProfilesAtStartup": true,
  "Profiles": {
    "local": {
      "ConnectionString": "mongodb://localhost:27017",
      "DatabaseName": "SaddleRAG",
      "Description": "Local development index"
    },
    "team": {
      "ConnectionString": "mongodb://db.internal:27017",
      "DatabaseName": "SaddleRAG",
      "Description": "Shared team index"
    }
  }
}

BootstrapAllProfilesAtStartup: true causes the warmup sequence to load vector indexes for all profiles into memory, not just the active one. This means the first search_docs(profile="team") call is fast rather than triggering a cold load.

Using the shared profile

Any MCP tool call accepts a profile parameter:

search_docs(query="retry policies", library="polly", profile="team")
list_libraries(profile="team")
scrape_docs(url="...", library="polly", version="8.2.0", profile="team")

Switching the default profile

Use the SADDLERAG_MONGODB_PROFILE environment variable to change which profile is used for calls that don't specify one:

$env:SADDLERAG_MONGODB_PROFILE = "team"

This is useful in CI/CD pipelines that should always operate against the shared database.

Team workflow

Recommended approach

  1. One team member (or CI/CD) owns indexing. Only one person or automated pipeline should trigger scrape_docs against the shared profile. Multiple concurrent scrapes against the same (library, version) can produce duplicate chunks.

  2. Everyone can search. Any number of developers can query the shared profile simultaneously. Searches are read-only and don't contend with each other.

  3. Automate indexing for new library versions. Add a CI step that runs saddlerag scan against the project's dependency files and queues new scrapes when versions change. See the CLI reference for the scan command.

Adding a library to the shared index

Have the designated team member (or your CI pipeline) run:

scrape_docs(
  url="https://docs.example.com/",
  library="example-lib",
  version="3.0.0",
  profile="team"
)

Or via CLI:

saddlerag ingest --url https://docs.example.com/ --library example-lib --version 3.0.0 --profile team

Once the scrape completes, all team members' AI assistants will find results when they query with profile="team".

Licensing

The free (single-developer) tier covers one authorized user. If multiple people are querying the same SaddleRAG instance — even for read-only searches — the deployment requires a commercial license at $100 per authorized user per year.

The profile system is the technical mechanism; the license is the legal one. A team of five developers all querying profile="team" is a 5-user deployment.

Profile isolation guarantees

Each profile is completely isolated:

  • Libraries, pages, chunks, BM25 indexes, profiles, job history — all scoped to the profile's MongoDB database
  • A delete_library(profile="team") call cannot affect the local profile
  • Scrape jobs are tracked per profile and don't appear in other profiles' job lists
  • Vector indexes in memory are keyed by {profile}/{libraryId}/{version} — they never overlap

The only shared resource is the running SaddleRAG process itself (and the ONNX model sessions, which are stateless and thread-safe).

Profile management via MCP

list_profiles               → lists all configured profiles
reload_profile              → re-reads appsettings.json and reconnects
reload_profile(profile=X)   → reconnects a specific profile

Use reload_profile after manually editing appsettings.json to add or change a profile — no restart required.

Clone this wiki locally