Hi Artur, >From the discussion, it seems that: - 1:1 remains the preferred deployment model. - There is currently no request to embed the UI into the Polaris Server, and the UI remains a separate component.
+1 to that from my side. If this understanding is correct, I propose to keep the current PR focused on the client-side use case and proceed with review/merge. I'll review shortly (hopefully :) ) Cheers, Dmitri. On Mon, Feb 9, 2026 at 5:08 AM artur rakhmatulin < [email protected]> wrote: > Hi all, thanks for the discussion. I'm sorry for the late response, I was > on a vacation. > > Let me try to summarize and check alignment: > - The current PR introduces client-side workspaces only (LocalStorage, no > backend changes). > - It is meant as a UX improvement for working with multiple > realms/environments. > - It does NOT aim to implement a full 1 enterprise-grade console or a > centralized backend layer. > > One additional context - I originally started working on this while > experimenting with OIDC integration in the UI. > Having workspaces significantly simplifies testing, prototyping, and > integrating the UI with different Polaris servers and auth setups. > Without it, these workflows become a bit complex. > > From the discussion, it seems that: > - 1:1 remains the preferred deployment model. > - There is currently no request to embed the UI into the Polaris Server, > and the UI remains a separate component. > > If this understanding is correct, I propose to keep the current PR focused > on the client-side use case and proceed with review/merge. > Please let me know if anyone sees blockers for this approach. > > Regards, > Artur. > > чт, 5 февр. 2026 г. в 16:17, Dmitri Bourlatchkov <[email protected]>: > > > Hi Alex, > > > > Good point about the front-end service endpoint! > > > > I suppose in real life deployments, the proxy / API gateway can indeed be > > in front of both the UI server and the API server and the Browser will > > observe the same host/port but different URI paths. > > > > I suppose we could simulate that in the UI module by using helm instead > of > > plain docker for the getting-started example (i.e. the UI helm will > include > > a Polaris Server with some fixed version for its image). > > > > Cheers, > > Dmitri. > > > > On Thu, Feb 5, 2026 at 8:52 AM Alexandre Dutra <[email protected]> > wrote: > > > > > Hi all, > > > > > > I think I would prefer to stay on the 1:1 model and I would even > > > advocate for co-locating the UI with the Polaris server. > > > > > > My reasons are: > > > > > > 1) Users would simply direct their browser to the service in front of > > > the Polaris deployment, completely eliminating CORS issues. > > > > > > 2) Quarkus already supports Human-to-Machine flows, such as the > > > authorization code grant. It would transparently redirect users to the > > > IDP login page if necessary. > > > > > > 3) For the internal /token endpoint, indeed a simple login page as > > > suggested by Dmitri could help, if it mimics the authorization code > > > grant flow. > > > > > > The 1:N model is undoubtedly attractive, as it could serve as a > > > central management interface for multiple Polaris deployments. > > > However, it introduces significant complexity, and I'm uncertain if we > > > have the resources to develop and sustain it. Not to mention that I > > > don't think any users have explicitly requested that feature. > > > > > > Thanks, > > > Alex > > > > > > On Mon, Feb 2, 2026 at 6:03 PM Dmitri Bourlatchkov <[email protected]> > > > wrote: > > > > > > > > Good point by Romain about 1:1 vs. N:1 between UI and Polaris > Servers. > > > > > > > > I do agree that the N:1 model with CORS headers requires Polaris > > Servers > > > to > > > > be aware of all UI instances, which may be very inconvenient in > larger > > > > environments. > > > > > > > > From my POV the key negative point about using an API proxy in UI is > > > > passing credentials through it. Otherwise, the proxy is quite valid, > > > IMHO. > > > > > > > > So, in case of OAuth2, the UI should be able to redirect the browser > to > > > an > > > > auth page in an IdP (e.g. Keycloak). That is a pure browser-level > > > redirect > > > > and should not cause any CORS issues (although I'm not an expert in > > UI). > > > > > > > > In case of the "internal" Polaris Authentication flow, currently > > someone > > > > has to POST to the /tokens endpoint in Polaris. Doing that via proxy > is > > > not > > > > ideal from the security perspective, IMHO. Doing a direct POST from > JS > > > code > > > > causes CORS issues. So, how about we host a custom login page in > > Polaris > > > > (no full UI, just the login page), and allow UI to redirect the > browser > > > to > > > > it in a manner similar to OAuth2 flows? > > > > > > > > Given that the /token endpoint is already deprecated in the Iceberg > > REST > > > > Catalog API, handling the internal login flow via OAuth2 flows might > be > > > > preferable from that POV too. Polaris effectively acts as an IdP for > > > > internal principals anyway. > > > > > > > > WDYT? > > > > > > > > Sorry, if this steers the conversation a bit sideways from the > original > > > > topic, but I believe these issues are interconnected. > > > > > > > > Thanks, > > > > Dmitri. > > > > > > > > On Mon, Feb 2, 2026 at 4:12 AM Jean-Baptiste Onofré <[email protected] > > > > > wrote: > > > > > > > > > Hi Romain > > > > > > > > > > That was my point and the reason why I started the console with > 1-1. > > > > > Again for dev it’s totally fine but enterprise grade probably need > > > extra > > > > > work. > > > > > > > > > > Regards > > > > > JB > > > > > > > > > > Le lun. 2 févr. 2026 à 09:55, Romain Manni-Bucau < > > > [email protected]> a > > > > > écrit : > > > > > > > > > > > Hi, > > > > > > > > > > > > my 2 cts would be that if you switch to 1-N instead of 1-1 you > > can't > > > just > > > > > > rely on the frontend to do the switch since you will desire some > > > sort of > > > > > > centralized security management so specific backend to avoid to > > rely > > > on > > > > > > every backend to be configured the same way to enable smooth > > > workflows > > > > > > (login -> actions) plus sounds like the backend should handle the > > > list of > > > > > > instances it aggregates with security for every level? > > > > > > > > > > > > Indeed it only applies to enterprise grade solution, for dev the > > > current > > > > > > option is perfect. > > > > > > > > > > > > Romain Manni-Bucau > > > > > > @rmannibucau <https://x.com/rmannibucau> | .NET Blog > > > > > > <https://dotnetbirdie.github.io/> | Blog < > > > https://rmannibucau.github.io/ > > > > > > > > > > > > | Old > > > > > > Blog <http://rmannibucau.wordpress.com> | Github > > > > > > <https://github.com/rmannibucau> | LinkedIn > > > > > > <https://www.linkedin.com/in/rmannibucau> | Book > > > > > > < > > > > > > > > > > > > > > > > > https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064 > > > > > > > > > > > > > Javaccino founder (Java/.NET service - contact via linkedin) > > > > > > > > > > > > > > > > > > Le lun. 2 févr. 2026 à 09:24, Jean-Baptiste Onofré < > > [email protected]> > > > a > > > > > > écrit : > > > > > > > > > > > > > Yes I know the change. My point was > > > > > > > More for context to everyone, in order to understand the > > > deployment and > > > > > > > behavior. > > > > > > > > > > > > > > Thanks for your work on workspaces. As said, I will take a > look. > > > > > > > > > > > > > > Regards > > > > > > > JB > > > > > > > > > > > > > > Le lun. 2 févr. 2026 à 08:49, artur rakhmatulin < > > > > > > > [email protected]> > > > > > > > a écrit : > > > > > > > > > > > > > > > Hi JB, > > > > > > > > Thanks for the clarification and for sharing your experience > — > > > the > > > > > > > > distinction between the two approaches is very helpful. > > > > > > > > > > > > > > > > Just to clarify the scope of the current PR: it does not > > > introduce > > > > > any > > > > > > > > server-side changes. The workspace concept is purely > > client-side > > > and > > > > > > > > user-scoped, with all configuration stored in browser > > > LocalStorage. > > > > > > > > > > > > > > > > Also, a previous change already removed the strict 1 Console > = > > 1 > > > > > server > > > > > > > > limitation in main. > > > > > > > > As a result, using a Console with Polaris server now requires > > > > > explicit > > > > > > > CORS > > > > > > > > configuration on the server side. > > > > > > > > This adds some setup overhead, but keeps the security model > > > explicit > > > > > > and > > > > > > > > controlled by the server. > > > > > > > > > > > > > > > > The workspace approach builds on top of this by improving > > > usability > > > > > > when > > > > > > > > working with multiple realms or environments, without > changing > > > server > > > > > > > > assumptions. > > > > > > > > > > > > > > > > Thanks again for the context. > > > > > > > > > > > > > > > > Best regards, Artur. > > > > > > > > > > > > > > > > пн, 2 февр. 2026 г. в 10:44, Jean-Baptiste Onofré < > > > [email protected]>: > > > > > > > > > > > > > > > > > Hi > > > > > > > > > > > > > > > > > > Fundamentally, it means about two different approaches: > > > > > > > > > 1. Without workspace, it means one Polaris server == one > > > Console > > > > > > > > > 2. With workspaces, it means one Console == several Polaris > > > servers > > > > > > > > > > > > > > > > > > Initially, the intent was (1), but we discussed (2) as > well. > > > > > > > > > Personally, when I started the Console, I was more (1) as > > it's > > > > > easier > > > > > > > in > > > > > > > > > terms of infrastructure (local to the server) and security > > (no > > > > > proxy, > > > > > > > > etc), > > > > > > > > > and the Console doesn't need any state/storage for the > access > > > to > > > > > the > > > > > > > > > different servers. > > > > > > > > > > > > > > > > > > I'm fine with the workspaces, even if it's a change in the > > > > > paradigm. > > > > > > > > > > > > > > > > > > I will take a look at the workspaces PR. > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > JB > > > > > > > > > > > > > > > > > > On Sun, Feb 1, 2026 at 8:24 PM artur rakhmatulin < > > > > > > > > > [email protected]> wrote: > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > I’d like to start a discussion on introducing > "workspaces" > > > in the > > > > > > > > Polaris > > > > > > > > > > Console UI. > > > > > > > > > > > > > > > > > > > > The idea is to move away from environment-variable–based > > > > > > > configuration > > > > > > > > > > toward a UI-managed model, where a workspace represents > an > > > > > isolated > > > > > > > > > Polaris > > > > > > > > > > context (server, realm, and authentication). This allows > a > > > single > > > > > > > > console > > > > > > > > > > instance to work with multiple realms and Polaris > > > environments > > > > > in a > > > > > > > > clean > > > > > > > > > > and scalable way. > > > > > > > > > > > > > > > > > > > > A preliminary PR is available for review [1] > > > > > > > > > > > > > > > > > > > > Thanks, Artur. > > > > > > > > > > > > > > > > > > > > [1]: https://github.com/apache/polaris-tools/pull/138 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Best regards, Artur Rakhmatulin > > > > > > > > e-mail: [email protected], > > > > > > > > telegram: https://t.me/binarycat0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > Best regards, Artur Rakhmatulin > e-mail: [email protected], > telegram: https://t.me/binarycat0 >
