feat: add self-managed Airbyte connection - #445
Conversation
|
Quick live-QA follow-up: after deploying the fork build against an existing self-managed Airbyte connection, I found one more recovery edge case. A stored Airbyte token can be rejected before its recorded expiry (for example after a restart or revocation), so the gateway now remints an Airbyte application token on a cold/cache-miss resolution and then caches it normally. The focused Airbyte tests and the full lint/type/format gate are green after that change. That kind of credential-boundary behavior is exactly why I like OneCLI—it's a great app, and it gives this integration one reliable place to recover instead of making every agent rediscover the token flow. |
|
hey @thethomasjfellows , i just commented in the issue :) |
|
Thanks! I’m running a local Codex agent through OneCLI. It uses Airbyte’s Public API to inspect connections and sync status, and when authorized, trigger or retry syncs. The main need is for OneCLI to handle the client-credentials exchange and token refresh so the agent never sees the client secret or bearer token. The current narrow self-managed connection design covers the use case well. |
…f-managed # Conflicts: # apps/gateway/src/connect.rs # apps/gateway/src/gateway.rs # packages/api/src/routes/apps.ts # packages/api/src/services/connection-service.ts
|
great! @thethomasjfellows sounds awesome |
…f-managed # Conflicts: # apps/gateway/src/connect.rs # apps/gateway/src/gateway.rs # apps/gateway/src/gateway/mitm.rs
I have read the CONTRIBUTING.md file.
YES
What kind of change does this PR introduce?
Feature and documentation.
What is the current behavior?
OneCLI does not have a first-class way to connect a self-managed Airbyte instance. A generic bearer secret can work only until Airbyte’s short-lived access token expires, while generic header injection cannot perform Airbyte’s JSON-body client-credentials exchange.
Closes #444.
What is the new behavior?
This adds a first-class self-managed Airbyte connection. It is intentionally not an Airbyte Cloud connection.
A project admin enters one instance origin, application client ID, and client secret. OneCLI exchanges and refreshes the short-lived token, then injects it only on the exact configured HTTPS authority (including a non-default port) under
/api/public/v1.The implementation also:
Additional context
OneCLI is a great app, and I built this after using it as the credential boundary for an Airbyte workflow. The integration was reviewed specifically for host/port isolation, private-network SSRF boundaries, token refresh behavior, and policy enforcement.
Local QA is green:
pnpm checkpnpm test— 585 API tests, 518 gateway unit tests, and 8 gateway integration testspnpm build— optimized web build and release gateway buildI kept the first version deliberately narrow: self-managed Airbyte, project scope, HTTPS origins, and no reverse-proxy subpath support. I’m happy to adjust the dynamic-host shape if there is a preferred internal convention.