OpenConnector ships a compose file with seventeen settings and one value

Fifteen environment settings, fourteen of them with no value

The compose file that starts a self-hosted gateway sets seventeen environment variables on the `connector` service. Exactly one carries a value, `OOMOL_CONNECT_DATA_DIR: /app/data`, paired with a named volume mounted at the same path. The other sixteen are keys with nothing after the colon.

Two of those blanks decide whether the deployment is safe. `OOMOL_CONNECT_ENCRYPTION_KEY` is the key the runtime uses to protect stored credentials, and `OOMOL_CONNECT_ADMIN_TOKEN` is what the Web Console authenticates against. Both are present in the file as names to fill in, which is a reasonable way to signal them and an easy way to start with neither set.

The rest configure storage and identity rather than secrets: `OOMOL_CONNECT_DATABASE_URL`, `OOMOL_CONNECT_DATABASE_POOL_MAX`, `OOMOL_CONNECT_DATABASE_CONNECT_TIMEOUT_MS`, `OOMOL_CONNECT_ORIGIN`, `OOMOL_CONNECT_RUNTIME_TOKEN`, `OOMOL_CONNECT_ALLOWED_CUSTOM_OAUTH`, and three JWT settings, `OOMOL_CONNECT_JWKS_URI`, `OOMOL_CONNECT_JWT_ISSUER` and `OOMOL_CONNECT_JWT_AUDIENCE`.

Two more details in the same file. The image is `ghcr.io/oomol-lab/open-connector:latest`, a floating tag rather than a digest or a release number. The comment at the top points at the source build path:

# the build overlay: docker compose -f docker-compose.yml -f docker-compose.build.yml up --build

Ports are published as `"3000:3000"`, which binds the gateway and the admin console to every interface on the host by default.

Allow lists, block lists and trusted egress hosts all start empty

Five of the seventeen settings decide what the gateway is allowed to reach and which Actions it will run: `OOMOL_CONNECT_ALLOWED_ACTIONS`, `OOMOL_CONNECT_BLOCKED_ACTIONS`, `OOMOL_CONNECT_ALLOWED_PROXIES`, `OOMOL_CONNECT_BLOCKED_PROXIES` and `OOMOL_CONNECT_EGRESS_TRUSTED_HOSTS`. All five are empty in the shipped file.

Read together with the feature list, they describe two different kinds of control. The action settings bound what an agent may invoke; the proxy settings and the egress host setting bound where a request may go once an Action runs.

That matters more here than it would in most services, because the thing being bounded is an agent acting on a user's behalf. The README's own description of the runtime controls names connection identity, scopes, runtime tokens, action allow and block policies, temporary file transit and redacted run logs, and the stated benefit is that provider secrets stay behind the runtime boundary while the agent receives metadata, safe account labels and execution results.

Scopes are the narrower of the two controls and they are set per connection rather than per deployment. Nothing in the compose file touches them, which means the scope grant is where the real permission boundary lives, and it is decided when a user authorises an account.

The manifest says 0.0.0-development and private true while the tags say v1.8.0

`package.json` declares the package as `@oomol-lab/open-connector` with `"version": "0.0.0-development"` and `"private": true`. Three tagged releases sit above it: v1.9.3 on 2026-10-24, v1.9.4 on 2026-10-27 and v1.9.5 on 2026-11-03, with the most recent commit dated 2026-11-02.

So no version number in the manifest corresponds to any of those tags, and `private: true` means this manifest cannot be published as it stands. Whatever produces the npm package named in the README badge has to rewrite the version and clear that flag, and nothing in the checked-in file records how. Anyone pinning a release has to take the version from the tag and not from the source.

The rest of the manifest describes a two-package layout: a single workspace, `web`, alongside the root package, with `"type": "module"` throughout. Four scripts run code at install or start time rather than only at build time:

"postinstall": "node scripts/ensure-generated.ts",
"dev": "node scripts/dev-local.ts",
"build": "npm run typecheck",
"start": "node scripts/ensure-generated.ts && node src/server/index.ts",

`start` executes TypeScript source directly through node, and `postinstall` runs a generator before anything else happens, so a plain install produces generated files that the tree does not carry.

The build script typechecks, and the Cloudflare scripts point at an uncommitted config

`"build": "npm run typecheck"` is the whole build. Nothing is compiled by that script; the actual work sits in `typecheck`, which first runs `generate:registry` and then `node scripts/typecheck.ts`, and `generate:registry` is `node scripts/generate-provider-registry.ts`. A second generator, `generate:catalog`, runs `node scripts/generate-catalog.ts` and is a prerequisite of the Cloudflare and runtime-package scripts rather than of `build`.

The two Cloudflare scripts both reference `wrangler.local.jsonc`:

"dev:cloudflare": "npm run generate:catalog && npm run build:web && node scripts/copy-catalog-assets.ts && wrangler dev --config wrangler.local.jsonc",
"deploy:cloudflare": "npm run generate:catalog && npm run build:web && node scripts/copy-catalog-assets.ts && wrangler deploy --config wrangler.local.jsonc --minify",

The only wrangler file at the repository root is `wrangler.example.jsonc`, so the config those two scripts name has to be created locally before either runs. Alongside them the root holds `fly.toml` for Fly.io and a `deploy/` directory, and the diagram in the README names Cloudflare Workers with D1 and R2 as one deployment shape among several.

Two toolchains coexist. Almost every script shells out to `node`, including the server entry point, while `build:binary` is the single script that reaches for `bun`, as `bun scripts/build-binary.ts`, and a `.bun-version` file is committed to pin it. Linting and formatting are handled by `oxlint .` and `oxfmt --check .`, configured through `.oxlintrc.json` and `.oxfmtrc.json`, and tests run under `vitest run`.

Five ways in, and the MCP endpoint is plain http on port 3000

An agent reaches the gateway through whichever surface fits the host it runs in. The Connector SDK is a thin TypeScript HTTP client, and it splits into three classes by deployment: `OpenConnector` for a self-hosted runtime, `Connector` and `ProjectConnector` for OOMOL-hosted personal and SaaS end-user connections. The `oo` CLI is the local agent relay, where `oo connector` searches, inspects and runs Actions against either a hosted or a self-hosted runtime. MCP is served over plain http at `http://localhost:3000/mcp`. Plain HTTP callers use `/v1/actions/*`, and the generated OpenAPI document lives at `/openapi.json`.

Five surfaces means five places where authentication has to hold. The runtime token settings exist for that, and the Web Console creates runtime tokens as one of its listed jobs, alongside browsing connectors, configuring credentials and inspecting usage. The Overview page is described as showing runtime readiness, available providers, executable Actions, recent failures, tool call trends and recent calls.

Endpoint details, response envelopes, auth headers and MCP tool listings are kept in a separate runtime API document, and the openapi.json route is the machine-readable version of the same surface.

Credentials stay behind the runtime boundary, and files transit through storage

The central design claim is that provider secrets do not reach the agent process. The stated shape is that apps and agents discover Actions, inspect schemas and scopes, select a connection alias and execute through the gateway, while the gateway keeps the secrets and hands back metadata, safe account labels and execution results.

Four credential kinds are handled: API keys, OAuth2, custom credentials and no-auth providers. The last one is worth pausing on, because a provider with no auth is a provider whose Actions are available to anyone who can reach the gateway and select that connection. Connection identity and scopes are the controls that stand between an agent and a user's account, and both live with the connection rather than in the deployment.

Files take a separate route. Temporary file transit is one of the named runtime controls, and the deployment options list local or S3-compatible transit storage, which is why `@aws-sdk/client-s3` is a runtime dependency. Run logs are described as redacted, which is a claim about the stored log rather than about what an Action returned to the caller.

The Action contracts themselves are described as inspectable, with request and response schemas, required scopes and lazy-loaded executor source, so what an Action will do is meant to be readable before it runs rather than inferred afterwards.

Eight README languages, a NOTICE file, and four example clients

The language row at the top of the README offers English plus seven translations under `docs/`, covering Simplified Chinese, Traditional Chinese, Japanese, Korean, Russian, French and Spanish. GitHub reports the licence as NOASSERTION and package.json says "SEE LICENSE IN LICENSE.txt"; the root holds `LICENSE.txt`, `LICENSE-APACHE-2.0.txt` and `NOTICE.md`, alongside `SECURITY.md` and `CODE_OF_CONDUCT.md`.

The `examples/` directory holds four shapes of client and two loose files. `local-http/` is a plain HTTP caller, `mcp-client/` speaks MCP, `openai-tools/` exposes Actions as tools for another kind of host, and `weixin-bot-login.ts` is a single script. Two names invite a second look before you run anything: `homebox-live-check.ts` has live in its filename, and the WeChat script is named for a bot login rather than for a connector Action.

Agent configuration is committed alongside them. The root carries `.claude/`, `.codex/`, `AGENTS.md` and `CLAUDE.md`. The provider list is the other place worth reading before you commit to anything: the README names GitHub, Gmail, Notion, BigQuery, Google Analytics, Supabase, Airtable and Slack among the products covered, and notes that provider names and trademarks belong to their owners and are used for identification and interoperability.

Editorial conclusion

OpenConnector is built for a team that wants provider credentials held in one inspectable runtime instead of inside an agent process, and that decision is the whole argument for it. It also means the deployment is a security deployment. Two things have to be settled before anything is exposed. First, `OOMOL_CONNECT_ENCRYPTION_KEY` and `OOMOL_CONNECT_ADMIN_TOKEN` are both present and empty in the shipped compose file, and port 3000 is published to the host, so fill both in before anything is reachable. Second, the allow list, block list and egress trusted host settings are all empty too, so decide which Actions and hosts to allow or block. Read the deployment docs for the platform you intend to run, and note that the Cloudflare scripts reference a local wrangler config while only an example file is committed.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes