Independent AI intelligence Two editions daily · ET
Fervor AI
Menu

Analysis · September 10, 2026 · repo

OpenConnectoroomol-labagent-infrastructuremcpagent-securityagent-identity

OpenConnector Moves Provider Secrets Out of Your Agent, and the 1,490-Provider Catalog Is Not What You Self-Host

A self-hosted connector gateway for AI agents, what the runtime boundary actually buys you, and the OAuth cost the headline number hides

OpenConnector's README describes what it does in one sentence that is doing more work than the benchmark tables most repos lead with: "Provider secrets stay behind the runtime boundary; agents receive the metadata, safe account labels, and execution results needed for the run."

That is a design claim, not a feature list, and it is the correct claim to lead with. The question worth asking about any tool that gives an agent access to Gmail, Slack, Notion, BigQuery, and nine hundred other things is not how many things it can reach. It is where the credentials live while it reaches them. Most agent integrations answer that question badly, by handing a token to the model's process and hoping the prompt holds.

The oomol-lab project answers it by putting a gateway in the path. And then the README puts a number above it that is true of the hosted product and not of the thing you would install.

What it is, concretely

OpenConnector is an open-source connector gateway for AI agents, positioned in its own README as an alternative to Pipedream and Composio. Apache-2.0 licensed, Node.js 22 or newer, about 5,700 stars as of today's cache-busted count, latest tagged release v1.5.0 dated 2026-09-04.

The architecture is a single runtime that sits between your agents and the outside world. Agents talk to it four ways: a TypeScript SDK, the oo CLI as a local relay, MCP over http://localhost:3000/mcp for agent hosts, or plain HTTP against /v1/actions/* with a generated OpenAPI 3.1 document. The gateway holds credentials, resolves scopes, applies allow and block policies per action, mints runtime tokens, and writes redacted run logs.

Getting it up is one command:

docker compose up

That pulls ghcr.io/oomol-lab/open-connector:latest, and the console and generated API reference come up on localhost:3000 and localhost:3000/docs. There is a no-auth action specifically for checking the runtime is alive:

curl -s -X POST http://localhost:3000/v1/actions/hackernews.get_top_stories \
  -H 'content-type: application/json' \
  -d '{"input":{}}'

State is SQLite by default, or PostgreSQL 15 and newer when OOMOL_CONNECT_DATABASE_URL is set. There is a Helm chart with PVC-backed storage, Ingress, autoscaling, and NetworkPolicy toggles for people running clusters, and documented deployments for Cloudflare Workers with D1 and R2, plus Fly.io.

The Postgres migration behavior deserves a sentence on its own, because it is the kind of decision that separates a project that has run in production from one that has not. Migrations are explicit: you run npm run runtime:migrate before starting a version with pending migrations, and per the README, "server startup only checks schema readiness and never applies PostgreSQL DDL." A gateway that ran DDL on boot without telling you would be a gateway that can corrupt your credential store during a rolling deploy. This one refuses to.

The number, and what it is a number about

Two badges at the top of the README read their values live from a catalog endpoint. Fetched today, connector.oomol.com/v1/catalog returns:

{"providerCount":1490,"actionCount":16752,"fusionApiServiceCount":50}

The prose beneath the badges says "1,000+ providers and 10,000+ prebuilt Actions," so the README's static floor actually undersells the live count. Nice problem to have.

Here is the part that matters. That endpoint is on connector.oomol.com, which is the vendor's hosted runtime. The catalog is a catalog of action contracts: request and response schemas, required scopes, and lazily loaded executor source. Contracts are not connections.

The README says this plainly, in a note block directly above the quick start, and I want to be fair to the project by quoting it rather than paraphrasing: "This starts a self-hosted runtime. OAuth providers require OAuth client credentials from apps you register with those providers. To let users authorize supported providers without setting up your own OAuth apps, use OOMOL-hosted connectors."

So on the self-hosted path, the number of providers your users can actually authorize equals the number of OAuth applications you are personally willing to register, verify, and maintain with Google, Slack, Notion, Atlassian, and everyone else. Anyone who has taken a Google OAuth app through verification for sensitive Gmail scopes knows that is not an afternoon. It is a review process, a privacy policy, sometimes a security assessment, and a per-provider ongoing obligation.

The three deployment paths the README lays out are honest about who carries this. OOMOL Hosted gives you "managed OAuth and hosted runtime, ready to use. No deployment or OAuth app setup," with OOMOL-provided OAuth apps and monthly included Connect credits. Self-hosted says "you manage storage and OAuth apps." That is the whole trade, stated in nine words, positioned below a badge reading 1,490.

I do not think this is a bait and switch. I think it is what happens when a project's headline metric is inherited from its hosted sibling. But it means the honest way to size a self-hosted deployment is to ignore the catalog count entirely and instead list the six or eight providers you actually need, then check how many of those use OAuth2 rather than an API key, then multiply by however long your organization takes to register a third-party OAuth app.

The credential path is worth reading before you widen it

The documented way to attach a credentialed provider is a PUT to the local runtime:

curl -s -X PUT http://localhost:3000/api/connections/github \
  -H 'content-type: application/json' \
  -d '{"authType":"api_key","values":{"apiKey":"github_pat_..."}}'

On loopback, over http, that is fine. The concern is what happens next, because the point of this runtime is to be shared. The moment it moves off localhost so more than one agent or one machine can use it, that request is a GitHub personal access token in a plaintext JSON body, and the documented happy path did not stop being the documented happy path. The docs do cover credential encryption, named connections, token refresh, and action policies in docs/credentials.md and docs/configuration.md, which is where you should be before you bind to anything other than a loopback interface. The README's own architecture diagram puts a "Credential & OAuth Boundary" box inside the gateway, and the Helm chart's NetworkPolicy toggles exist for exactly this reason. Use both.

There is also a licensing detail I have started checking on every repo, because it keeps turning up. OpenConnector's license file is at LICENSE.txt rather than plain LICENSE, and the file itself is the unedited Apache 2.0 template, with Copyright [yyyy] [name of copyright owner] never filled in. Plain LICENSE is empty, which is why the README hard-codes a static Apache-2.0 badge pointing at LICENSE.txt instead of relying on GitHub's license detector.

The odd thing is that the project's prose about licensing is more careful than most. There is a full "License Scope" section stating that the Apache-2.0 grant "does not grant rights to third-party products, providers, apps, APIs, trademarks, service marks, trade names, logos, icons, brand assets, documentation, screenshots, or other copyrighted materials owned by their respective holders," plus a request that contributors submit only material they have rights to and prefer linking official assets over copying brand files in. For a project whose entire value is a catalog of other companies' names and icons, that is the right thing to write and most projects do not write it. Somebody thought hard about trademark exposure and nobody typed a name into the copyright line. That is not a legal opinion, it is a signal about which files got read.

Put this into practice

If you want to evaluate this properly rather than starring it, here is the cheapest useful hour.

Bring it up with docker compose up and hit the no-auth Hacker News action to confirm the runtime works. Then pick the one provider you would actually put in front of an agent, and check whether it authenticates by API key or by OAuth2. If it is API key, connect it with the PUT above and you are testing the real thing in about ten minutes. If it is OAuth2, stop and register the OAuth app first, because that step is the actual project and finding out now is the point of the exercise.

Once one connection works, go straight to the controls rather than the catalog. Create a runtime token instead of letting anything talk to the gateway unauthenticated. Set an action allow list so a connection that can read your inbox cannot also send from it. Then read a run log and confirm the redaction is doing what you need, because "redacted run logs" is a claim you should verify against your own definition of sensitive rather than the project's.

For the MCP path, point one agent host at http://localhost:3000/mcp and look at what the agent actually receives. The design claim under test is that the model gets metadata, safe account labels, and results but never the provider secret. That is inspectable in about two minutes and it is the single most important thing to confirm before you trust the boundary.

If you get through all of that and want the connections without the OAuth work, the hosted path exists and the README says the provider ids, action ids, schemas, and contracts are the same across both, which is the sentence that makes trying the hosted version a low-risk way to prototype before committing to self-host.

Honest limitations

I read the README, the live catalog endpoint, the license file, and the release feed. I did not run this. Everything above about behavior comes from the project's own documentation, and documentation and runtime disagree more often than either party intends.

The claims I could not check are the ones that matter most for the security story. Whether credentials are encrypted at rest by default or only when configured, what exactly "redacted run logs" redacts, how runtime tokens are scoped, and whether the action allow and block policy is enforced at the gateway or advisory to the caller are all answered in docs/credentials.md and docs/configuration.md, which I did not fetch this session. If you are putting this in a path that touches real accounts, those two documents are your actual reading list, not this article.

The comparison to Pipedream and Composio is the project's own framing and I have not benchmarked against either, on catalog coverage, on action reliability, or on cost. Treat "alternative to" as a positioning statement.

The star count is a snapshot from cache-busted shields.io cross-checked against ungh.cc, and it moves. The 1,490 and 16,752 figures are a single read of a live vendor endpoint today, and they will be different when you look.

And the version number is real information: v1.5.0 with a tagged release history is further along than most of what trends on a given day, but this is a project whose main branch is published as a tip Docker tag, which tells you the maintainers expect people to run unreleased code. Pin a version.

What to take from it

The pattern worth carrying out of this repo is the runtime boundary itself, whether or not you use OpenConnector to get it. An agent that holds provider credentials in its own context is an agent whose blast radius is every account it can authenticate to, and no amount of prompt discipline changes that. A gateway that holds the secrets and hands back only labels and results makes the blast radius a property of your configuration instead of a property of the model's behavior. That is a better place for it to live.

Just size the work honestly. The catalog number tells you what the vendor's OAuth apps can reach. The number you get is the number of OAuth apps you are willing to own.

Sources: oomol-lab/open-connector README; the live catalog endpoint at connector.oomol.com/v1/catalog; the repository's LICENSE.txt and releases.atom, both read cache-busted on 2026-09-10.

Medium metadata

  • Title: OpenConnector Moves Provider Secrets Out of Your Agent, and the 1,490-Provider Catalog Is Not What You Self-Host
  • Subtitle: A self-hosted connector gateway for AI agents, what the runtime boundary actually buys you, and the OAuth cost the headline number hides
  • Tags: AI Agents, MCP, Open Source, Self Hosted, API Security
  • Suggested kicker image: a single ethernet patch panel photographed straight on, most ports empty, three cabled, no logos
  • Canonical: import from the fervorai.dev URL