oomol-lab/open-connector

docker compose up (pulls ghcr.io/oomol-lab/open-connector:latest)
npm install && npm run dev (local Node.js development, Node.js 22+)
Deploy to Cloudflare Workers (D1/R2/Static Assets) via npm run deploy:cloudflare, or to Fly.io with SQLite storage

Usage

• •Open the local console at http://localhost:3000 and API reference at /docs
• •Connect a provider: curl -X PUT http://localhost:3000/api/connections/github with an API key, then run actions via POST /v1/actions/<provider>.<action>
• •Expose app Actions to MCP-capable agent hosts via http://localhost:3000/mcp
• •Use the Connector SDK (TypeScript HTTP client) from app code, or the oo CLI as a local agent relay
• •OAuth providers require OAuth client credentials you register - use OOMOL-hosted connectors to let users authorize without setting up OAuth apps

Key features

• ✓Connector catalog across GitHub, Gmail, Notion, BigQuery, Google Analytics, Supabase, Airtable, Slack, and more
• ✓Credential handling for API keys, OAuth2, custom credentials, and no-auth providers; provider secrets stay behind the runtime boundary
• ✓Inspectable Action contracts: request/response schemas, required scopes, lazy-loaded executor source
• ✓Runtime controls: connection identity, scopes, runtime tokens, allow/block policies, temp file transit, redacted run logs
• ✓Web Console dashboard for browsing providers, configuring credentials, creating tokens, and inspecting usage; deployment on local Docker, Fly.io, Cloudflare, or OOMOL hosted

Best for

Agent products that need durable, reusable access to a user's existing SaaS apps without handing provider credentials to the agent process.

Caveats

• ⚠Self-hosted runtimes need you to register your own OAuth apps with each provider; hosted OAuth requires the OOMOL service
• ⚠Requires Node.js 22+ for development/source builds
• ⚠Apache-2.0 license covers the repo's own code only; provider names/assets remain with their owners