Deployment

BridgeMCP is self-hosted. It runs as a SvelteKit frontend and an F# / .NET backend, backed by PostgreSQL and Redis, with S3-compatible object storage for agent workspaces.

Services

ServiceRole
Web (SvelteKit)Console UI, consent pages, identity.
Backend (F# / Giraffe)MCP gateway, management API, OAuth server.
PostgreSQLApplication and identity data.
RedisOAuth state and token storage.
S3-compatible storageAgent job workspaces and artifacts.

Run with Docker Compose

# Clone the repository
git clone https://github.com/kubebridges/bridge-mcp.git
cd bridge-mcp

# Start the dependencies (PostgreSQL, Redis, and friends)
docker compose up -d infrastructure

# Start the application
docker compose up -d

Database migrations run automatically on backend startup, so a fresh database is provisioned on first boot.

Configuration

The backend reads configuration from YAML with environment-variable overrides. The frontend reads environment variables. At minimum, configure:

  • Database and Redis connection strings.
  • Object storage endpoint and credentials.
  • A signing secret for the frontend session and identity layer.
  • OAuth provider credentials (optional) to enable social login.

Never ship default or placeholder credentials to production. Generate fresh secrets and supply them through your deployment’s secret management, not source control.

Kubernetes

For production, deploy the backend and frontend as separate workloads with Kubernetes manifests, and run PostgreSQL, Redis, and object storage as managed or in-cluster services. Point the frontend at the backend’s internal service address, and expose only the public endpoints (the console and the MCP gateway) through your ingress.

Use readiness and liveness probes so the platform only receives traffic once migrations have completed and dependencies are reachable.

Next steps