[Feature]: Bring your own OIDC and environment directory to T3 Connect

[urostripunovic]

Problem

I am building a Kubernetes orchestrator that starts an ephemeral T3 pod per
repository. I already have identity through Zitadel and connectivity through HTTPS
ingress and a VPN.

I would like to sign into the T3 iOS app with my own identity provider and see my
running environments, with authentication and discovery handled by infrastructure
I control. I am happy to authorize each new pod; the missing piece is linking those
environments to my own account system.

What already exists

• Direct pairing works without a T3 account, but requires pairing each client with
  each environment.
• The relay already maintains account-to-environment links and brokers normal scoped
  environment sessions. It can be self-hosted with Cloudflare and Clerk.
• CliTokenManager implements OAuth device login and refresh. The shared
  ManagedRelaySession accepts an account ID and a token-reader callback.
• Account-discovered connections currently require cloudflare_tunnel endpoints.
  Disabling managed tunnels creates a publish-only link, not an advertised ingress
  endpoint.

Proposal

Add an optional self-hosted connection mode, with hosted T3 Connect remaining the
default:

• Identity: configurable OIDC issuer and client configuration, supporting native
  sign-in and headless authorization where available.
• Discovery: configurable connection-service URL that lists environments linked
  to the authenticated account and brokers access using T3's existing session model.
• Connectivity: support verified, existing HTTPS/WSS endpoints alongside managed
  tunnels.
• Clients: expose this configuration in web, desktop, and mobile so users can
  select their own deployment.

T3 app → own OIDC login → own environment directory → selected T3 pod

Potential integration points:

• apps/server/src/cloud/publicConfig.ts: CLI endpoints are derived from a Clerk key.
• CloudAuthProvider.tsx: mobile login uses Clerk; web and desktop have corresponding integrations.
• infra/relay/src/http/Api.ts: general authentication and the DPoP exchange both need configurable identity verification.
• EnvironmentConnector.ts: account-based connection currently requires a managed tunnel allocation.

Why account-based discovery

Disposable environments come and go. An account-linked directory lets the phone
find current workspaces without maintaining a growing list of manual pairings.
The orchestrator already provides isolation and routing; each T3 environment remains
single-tenant.

Alternatives considered

• Self-host the current relay: supports operating a separate deployment, but
  retains the Clerk and Cloudflare integrations.
• New self-hosted platform: feat(relay): self-hosted relay (T3 Relay Self) #6033 proposed a broader relay implementation and was
  declined. Could narrower client/protocol extension points support an externally
  maintained connection service instead?
• Environment-level multi-user OIDC: RFC: OIDC-backed multi-user self-hosted environments #12278 included per-user execution isolation.
  My setup already isolates workspaces in separate pods.

Current workaround

Direct pairing over the VPN, or registering each pod through hosted T3 Connect.
Direct pairing covers connectivity; hosted Connect supplies the account directory.

Environment

Planned deployment: Kubernetes, one T3 server per ephemeral repo pod, Zitadel OIDC,
HTTPS ingress, VPN, and the T3 iOS/web clients.

[bigpod98]

yea a selfhosted own OIDC would be great

[urostripunovic]

I've been experimenting with emhperal pods in k8s and from what I understood of t3code it is more directed towards a ssh machine. But having your own oidc would improve sandboxing and hardening agentic coding where security is a priority in k8s or just using k8s in general.

[bigpod98]

yea but existance of t3connect and if you want internally that kind of simple connection you either need to use third party SaaS auth provider or t3connect saas.

[burnmandont]

We have a working fork with the same underlying requirement: keep the connection infrastructure fully self-hosted, without Tailscale, Cloudflare, or Clerk. We replaced the hosted identity integration with our own Better Auth/OAuth service and use PostgreSQL and an FRP-based relay/connector. The fork has corresponding authentication paths for web, desktop, mobile, and headless CLI hosts.

Our goal is to reduce the fork and contribute generally useful changes upstream. We would maintain the replacement account/relay service ourselves.

I read #6033 and Julius's response that a VPS relay deployment was not something you wanted to take on at that time. Would you consider a narrower scope: allow stock T3 clients to use an independently operated OAuth identity and compatible relay service, while keeping T3 Connect as the default and keeping the alternative service implementation outside this repository?

The likely pieces would be:

• configurable identity/service discovery and client configuration;
• provider-neutral identity verification and connector boundaries;
• explicit protocol versions/capabilities so unsupported transports fail clearly;
• credentials scoped to the selected service, with explicit authorization when switching.

This is about choosing an operator's service, not automatic failover between unrelated relays. We would preserve the existing scoped environment-session and DPoP model.

Before preparing implementation PRs, could a maintainer clarify whether that direction is in scope, and which smallest slice you would be willing to review? If compatibility with external services is also out of scope, knowing that would help us avoid work you do not want to maintain.