OpenConnector is an open-source TypeScript gateway from OOMOL Lab that sits between AI agents and the SaaS services those agents call. The maintainers describe it as a connector gateway and an alternative to Pipedream or Composio: users authorize an account once, and agents reach a shared catalog of 1,000+ providers and 10,000+ prebuilt actions through the SDK, CLI, MCP, HTTP, or OpenAPI. Version 1.4.0, published on 20 August 2026, adds PostgreSQL runtime storage, S3-compatible transit files, connection-scoped OAuth apps, and support for the 2026-07-28 MCP protocol.

This is a source and documentation review (verification level: observed); no local installation or runtime testing was performed. The short answer: OpenConnector is worth evaluating for teams that want a credential boundary in front of agent tool calls and the option to start hosted and self-host later, but production readiness depends on your OAuth app management, migration discipline, and ability to track a fast release cadence.

What OpenConnector is and who it fits

OpenConnector is an auth and execution gateway. Providers expose Actions with inspectable contracts, including request and response schemas, required scopes, and executor source, while the runtime applies credentials, scopes, allow and block policies, runtime tokens, temporary file transit, and redacted run logs. According to the repository README, provider secrets stay behind the runtime boundary; agents receive the metadata, safe account labels, and execution results needed for a run.

Deployment options cover most server shapes: local Docker or Node.js with SQLite or PostgreSQL state, S3-compatible transit storage, Fly.io, Cloudflare Workers with D1/R2/Static Assets, Kubernetes via a Helm chart, or the OOMOL hosted runtime.

Who fits:

• Agent products that need durable access to the user’s existing apps without handing provider credentials to the agent process.
• Teams that want hosted OAuth now but a path to private or self-hosted runtime control later.
• Teams that need a common Action contract and policy layer across many SaaS providers rather than one-off integrations.

What changed in v1.4.0

According to the v1.4.0 release notes and README, this release is mostly about storage, OAuth control, and hardening:

• PostgreSQL runtime storage: the Node runtime uses SQLite by default and can use PostgreSQL 15 or newer when OOMOL_CONNECT_DATABASE_URL is configured. Migrations are explicit: run npm run runtime:migrate before starting a version with pending migrations, because startup only checks schema readiness and never applies DDL.
• S3 transit files, plus new transit download actions for providers such as R2, Supabase, Dropbox, OneDrive, Aliyun OSS, and AWS S3.
• Connection-scoped OAuth apps and the ability for clients to request a scope subset, with fixes to keep stored scope subsets readable after scope removals.
• MCP support for the 2026-07-28 protocol.
• SSRF hardening: shared provider egress is pinned to the provider origin, and run logs redact credentials in malformed or non-HTTP URLs.
• New providers and OAuth coverage, including Microsoft To Do, Google Chat, Xero, Okta, Datadog, Shopify, Mailchimp, Miro, Confluence, GitLab, Webflow, and WordPress.

The condition to note: these are repository claims from release notes and the README, not results of an installation or runtime test. If you depend on a specific provider or Action, verify it in the catalog before planning around it.

Deployment and upgrade concerns to check first

Self-hosting this project is mostly an operations problem. The README is explicit about the parts that are not automatic:

• OAuth apps are yours to register. The quickstart notes that OAuth providers require client credentials from apps you register with those providers, and the OOMOL-hosted path is how to avoid setting up your own OAuth apps. Plan a per-provider credential registry and rotation process.
• Pin versions. The README recommends latest for the newest release, a pinned released version for production, and tip for the latest main build. Production deployments should pin a released version.
• PostgreSQL migrations are manual. Add the migration command to your deploy pipeline and run it before starting a version with pending migrations; do not assume startup will fix the schema.
• Storage choices matter. SQLite is the default, PostgreSQL 15+ is the multi-instance option, and transit files can be local or S3-compatible. Cloudflare deployments use D1 and R2 instead.
• Private-network egress is opt-in. Earlier releases added allow-private-network toggles for Home Assistant, n8n, and Gitea, plus trust for selected egress hosts behind corporate VPNs. If your agents need LAN or VPN targets, configure those allowances deliberately; v1.4.0 pinned shared provider egress to provider origins.
• Scope changes mean re-authorization. An open issue (#413) audits OAuth scopes requested beyond current action requirements for providers such as Strava, Harvest, Bitbucket, and Gist. If scopes are trimmed, existing connections keep the old grant until the user re-authorizes, so consent screens and re-auth flows are part of upgrades.

Maintenance signals from the repository

As of the 25 August 2026 snapshot, the repository shows 5,228 stars and 434 forks, which is a snapshot, not a quality verdict, and 4 open issues. More relevant signals:

• Fast cadence. Releases shipped roughly weekly between v1.3.2 (27 July 2026) and v1.4.0 (20 August 2026), with dozens of merged changes per release and many first-time contributors. That is good for fixes and bad for upgrade drift; you need a retest step per release.
• Young codebase. The repository was created on 29 June 2026, so it is about two months old at review date. Judge maturity on your provider set and upgrade process, not on popularity.
• Meaningful open issues. Issue #390 asks for upload symmetry for R2, Supabase, and Files.com, which currently have transit downloads but no matching upload actions; issue #413 is the OAuth scope audit. Neither blocks basic use, but both describe work you may need tracked or done.

Limitations and evaluation questions

Limitations worth knowing before you commit:

• Catalog breadth is a maintainer claim (1,000+ providers, 10,000+ Actions). Check that the exact providers and Actions you need are present, current, and complete, including write operations.
• Distribution is container or Node based: the README points to a GHCR Docker image and Node.js 22+, with no release binaries attached.
• Apache-2.0 covers repository-authored code and documentation, not third-party provider names, APIs, trademarks, or logos; the license scope is spelled out in the README.
• If your integration set is small, a direct vendor SDK or managed integration platform may be simpler than running a gateway. The README positions OpenConnector against Pipedream and Composio.

Ask these before production:

• Which providers and Actions does your product actually need, and are upload, download, and OAuth flows complete for them?
• Who registers, reviews, and rotates OAuth client credentials for each provider?
• Which runtime fits: Docker or Node on your server, Fly.io, Cloudflare, Kubernetes, or the hosted service?
• Which state and transit storage will you run, and do you have a migration runbook with rollback?
• Can your team absorb weekly releases and re-test provider behavior after upgrades?
• Do your agents need MCP, HTTP/OpenAPI, the SDK, or the CLI, and does that choice constrain the runtime?

Verdict

OpenConnector v1.4.0 is a serious, well-documented candidate for teams building agent products that need many SaaS connectors behind one policy and credential boundary. The v1.4.0 additions address the main server-side gaps: PostgreSQL for multi-instance state, S3 transit files, connection-scoped OAuth, and stricter egress. The deciding factors are operational, not architectural: OAuth registration, manual PostgreSQL migrations, version pinning, and per-provider contract verification.

Teams that should consider it include agent product teams with broad provider needs, teams wanting a hosted-to-self-hosted path, and teams with someone responsible for operating the gateway. Teams that should be cautious include those whose workflows need uploads to R2, Supabase, or Files.com today (an asymmetry at this snapshot), teams that cannot manage OAuth app lifecycle or re-auth flows, and teams that only need a handful of integrations.

What I can do next

If you are evaluating OpenConnector or already running a version behind, I can help turn this review into a deployment and maintenance plan: map your required providers to catalog Actions, choose the runtime and state storage, build the PostgreSQL migration and version-pinning runbook, review OAuth scope and egress configuration, and then own upgrades and incident response after launch. That is the self-hosted deployment, upgrade, and ongoing maintenance work I take on at XP812, including taking over a gateway that has drifted several releases behind.

Sources

• oomol-lab/open-connector repository
• OpenConnector v1.4.0 release notes
• Issue #413: OAuth scopes requested beyond current action requirements
• Issue #390: put/upload symmetry for R2, Supabase, Files.com
• OpenConnector self-hosting documentation