Skip to content

[FEATURE]:  multi-user auth and per-user provider credentials for opencode web #20067

New issue
New issue
Closed as not planned
Closed as not planned
[FEATURE]:  multi-user auth and per-user provider credentials for opencode web#20067
Assignees
Brendonovich

Description

@berkslv
berkslv
opened on Mar 30, 2026

Feature hasn't been suggested before.

  • I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

When deploying OpenCode on a shared enterprise server via opencode web, multiple team members accessing the same instance from a browser share a single identity and provider credentials. There's no login flow to separate users.

Two gaps:

  1. No user session layer in the web UI. opencode web opens packages/app with no concept of who is accessing it. Everyone sees the same sessions and uses the same provider keys.
  2. No per-user provider credentials. Each team member should be able to bring their own API key or OAuth subscription (e.g. their own Anthropic or OpenAI key). This matters for cost attribution and for teams where individuals have personal subscriptions.

The cloud console (packages/console) already has an OpenAuth.js-based flow with GitHub/Google. A similar opt-in mechanism for opencode web would make enterprise self-hosting viable for teams.

Proposed scope:

  • Optional auth mode for opencode web (off by default, opt-in via config)
  • Login flow in packages/app — user identity before accessing the UI
  • Per-user credential store so provider keys are isolated per session identity

Happy to help implement if the team is open to the direction.

Activity

  1. berkslv
    added
    discussionUsed for feature requests, proposals, ideas, etc. Open discussion
    on Mar 30, 2026
  2. github-actions
    assigned
    Brendonovich
    on Mar 30, 2026
  3. github-actions
    added
    coreAnything pertaining to core functionality of the application (opencode server stuff)
    webRelates to opencode on web / desktop
    on Mar 30, 2026

  4. berkslv commented on Apr 3, 2026

    @berkslv
    berkslv
    on Apr 3, 2026
    Author

    any suggestions @Brendonovich ?

  5. mrsimpson
    added a commit that references this issue on Apr 12, 2026

    feat(opencode-router): deploy per-session isolated OpenCode instances…

    e7bb721

  6. mrsimpson commented on Apr 12, 2026

    @mrsimpson
    mrsimpson
    on Apr 12, 2026

    Hey, wanted to share a WIP approach I've been building that addresses this issue from a different angle — might be useful as a reference or spark some ideas.

    Background / motivation

    I've been looking for an alternative to Claude Code web, which I find increasingly opinionated and leans heavily into opaque agentic behaviour. I prefer opencode precisely because of its configurability, transparency, and the fact that I can see and reason about what's happening. I run a homelab on an AMD Strix Halo (128 GB unified memory) with Qwen Coder Next as a local LLM — it works well enough with proper guidance — alongside Kubernetes (k3s) and Pulumi as IaC, exposed securely via Cloudflare tunnels.

    What I built

    Rather than adding auth/session management inside opencode serve, I took a proxy-based approach: a lightweight router sits in front of one opencode serve pod per session, where a session is a (user, repo, branch) triple — matching the Claude Code web model where each coding session is independent and has its own URL.

    • opencode-router — an HTTP/WebSocket reverse proxy that creates a Kubernetes Pod + PVC on demand when a user starts a session, then proxies all traffic (including WebSockets) to that pod. Auth is delegated to an upstream oauth2-proxy (GitHub OAuth in my case), so opencode serve itself needs no changes.
    • opencode-router-app — a small React SPA that lets users pick a repo + branch to open a session, shows a loading screen while the pod initialises, then redirects to the session URL.
    • opencode-cloudflare-operator (homelab-specific) — a sidecar that watches session pods and dynamically provisions Cloudflare DNS records and Traefik IngressRoutes so each session gets its own public HTTPS URL.

    The two PRs:

    Current state

    This is firmly MVP / proof of concept. It works on my cluster but has rough edges — no UI for listing or resuming sessions, PVC lifecycle is manual, and the Kubernetes dependency makes it non-trivial to adopt outside a cluster environment. I'm sharing it in case the approach is useful to the team or community, and to flag that there's real demand for this use case.
    Happy to discuss the design or answer questions.

    Opencode.@.homelab.mp4
  7. mrsimpson
    added a commit that references this issue on Apr 12, 2026

    feat(opencode-router): MVP multi-user multi-session opencode web via …

    af5c3dd

  8. luvk1412 commented on Apr 23, 2026

    @luvk1412
    luvk1412
    on Apr 23, 2026

    We also have a similar use case where we wanted to host a single opencode server and web instances internally and wanted support for user based login so that chats/session are user namespaced rather than being global.

    One approach i had in mind to do this was put a proxy in between opencode web and opencode server how @mrsimpson did but instead of spawning a pod for each i was thinking to keep a single server and then what if i created a per user project on top of the project we already have, so if we have project called system-debugging, then we could create a project by name user1/system-debugging and user2/system-debugging and proxy would handle filtering of sessions and auth per user so that user only sees his sessions. Yet to try out this approach though.

    Anyways native support for this would be great to have though.

  9. tjvjk commented on Apr 24, 2026

    @tjvjk
    tjvjk
    on Apr 24, 2026

    Agree, great feature.

    I experimented with this a bit. Just not at the level of 1 user - 1 pod/docker image. I think this setup is redundant and requires a lot of resources to maintain. I used one opencode server and multiple users, each with one session. Authentication is handled by the proxy layer. A session manager manages sessions. A separate folder is created for each user, where sessions and other files are stored. This can then be split into isolated S3 storage, for example. I also created my own UI client, since I wanted the simplest possible client without selecting a model or anything else, but that's not necessary. Overall, this setup works.

    [Browser]
    |
    v
[Next.js web]
    |
    v
[FastAPI wrapper]
    |
    v
[Session manager]
    |
    v
[opencode serve per user]
    |
    v
[data/users/<user>/...]
  10. thdxr
    removed
    discussionUsed for feature requests, proposals, ideas, etc. Open discussion
    webRelates to opencode on web / desktop
    coreAnything pertaining to core functionality of the application (opencode server stuff)
    on May 3, 2026

  11. razzeee commented on Jun 6, 2026

    @razzeee
    razzeee
    on Jun 6, 2026

    The biggest reason I want this, is not loosing sessions between my mobile and desktop devices. And being able to pick it up again from anywhere, even from mobile.

  12. alipievg commented on Jun 25, 2026

    @alipievg
    alipievg
    on Jun 25, 2026

    @tjvjk do you have a repo for that? Seems like exactly of what I was thinking of building....

  13. ashish16052 commented on Jul 9, 2026

    @ashish16052
    ashish16052
    on Jul 9, 2026

    This use case is very close to something I’ve been working through.

    One approach I’ve been experimenting with is to keep auth/authorization in the app or proxy layer, but isolate OpenCode at the runtime layer: each (workspace, user_id) gets its own managed OpenCode server/session/workspace, started on demand, reused when healthy, and cleaned up when stale. That does not solve UI login or per-provider credential UX by itself, but it avoids multiple users sharing the same OpenCode state.

    I maintain a small Python library for this runtime side: opencode-runtime. It is not meant as a replacement for OpenCode or the official SDK; it is more of a process/session/workspace manager for embedding OpenCode in a backend.

    Happy to share the architecture or adapt it if this direction is useful here.

  14. tjvjk commented on Jul 9, 2026

    @tjvjk
    tjvjk
    on Jul 9, 2026

    @tjvjk do you have a repo for that? Seems like exactly of what I was thinking of building....

    Hello, sorry, no. This was an experiment and I had only working concept.

  15. github-actions commented on Sep 8, 2026

    @github-actions
    github-actionsBot
    on Sep 8, 2026 – with GitHub Actions
    Contributor

    To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.

  16. github-actions
    closed this as not plannedon Sep 8, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions