​

Self-hosting overview

​

What you run

• API server — Same REST API as the hosted product (https://api.withfoundry.ai). Auth via API keys; same envelope and endpoints.
• Memory backend — PostgreSQL with pgvector for embeddings and semantic search.
• Security scanner workers — Scan jobs and optional queue (e.g. Redis + workers).
• Embeddings — Optional local embedding model or your own embedding API to avoid sending data out.

​

Architecture (high level)

[Your clients / Cursor MCP / CI]
        |
        v
[Foundry API]  -->  [PostgreSQL + pgvector]
        |
        v
[Scanner workers]   (clone repo, run analysis, store findings)

​

Requirements

• PostgreSQL with pgvector extension.
• Node (or container runtime) for the API and workers.
• Storage for scanner clones and artifacts (or ephemeral clones).
• API keys — Generated and stored by your instance; same key_ prefix and Authorization: Bearer usage.

​

Configuration

• Base URL — Set your instance URL so the API and workers use the same host.
• Database — Connection string and pool settings.
• Embeddings — Point to your embedding service or local model; same interface as hosted.
• Secrets — Store API key signing secrets and any third-party keys in env or secret manager.

​

Using the SDK and MCP against self-hosted

const foundry = new Foundry({
  apiKey: 'key_your_self_hosted_key',
  baseUrl: 'https://foundry.your-company.com',
});

{
  "mcpServers": {
    "foundry": {
      "command": "npx",
      "args": ["-y", "@withfoundry/mcp-server"],
      "env": {
        "FOUNDRY_API_KEY": "key_your_key",
        "FOUNDRY_BASE_URL": "https://foundry.your-company.com"
      }
    }
  }
}

​

Licensing and artifacts

​

Summary