Given this discussion [1], I don't think putting the UI in the server image makes sense at this point. We could revisit that decision in the future if the Console evolves into a multi tenant web application.
If we continue to treat the Console as a separately deployed REST client, I'm not convinced there is a strong reason to move it into the main repo. This seems consistent with the position taken in the earlier MCP discussion [2][3]: If MCP server goes in polaris main repo, than other tools could be > there too (console, catalog migrator, etc). But I don't think it's a > good idea due to the LICENSE/NOTICE overhead and also clear separation > of concerns. I think the MCP server is a "client" for the Polaris server, like the > CLI or the Console (UI). > So, maybe it's worth considering polaris-tools as a host (it's what > I'm doing to the Polaris Console). To me, the same reasoning still applies. If the Console remains an independent client that interacts with Polaris exclusively through REST APIs, keeping it separate preserves a clear separation of concerns and allows it to evolve independently. Moving it into the main repo would therefore require a stronger justification. 1. https://lists.apache.org/thread/v4jqvfdw0myxkgfzb01t2787nz7oyzbw 2. https://lists.apache.org/thread/539p26bwk7zh1p4d1jqyhh2pqkkh0n36 3. https://lists.apache.org/thread/yj98vol73dhpvygmyxm23sgjbnf7zfsd Yufei On Tue, Jun 2, 2026 at 7:59 AM Dmitri Bourlatchkov <[email protected]> wrote: > Hi JB, > > This plan sounds good to me. > > While packaging the UI in the same image as the server may help fresh > users, keeping a separate UI image will likely have less impact on existing > deployments. Docker compose profiles seem like a good middle ground from > the UX perspective. > > Cheers, > Dmitri. > > On Tue, Jun 2, 2026 at 7:22 AM Jean-Baptiste Onofré <[email protected]> > wrote: > > > Hi, > > > > To provide some perspective based on my experience with other Apache > > projects that include a UI by default (such as ActiveMQ, NiFi, Druid, and > > Hop), I don't believe the console necessarily needs to be enabled by > > default. While a seamless out-of-the-box user experience is key for > getting > > started quickly with Polaris, we must also recognize that console > > requirements vary depending on the deployment. > > > > I propose keeping the Polaris server distribution and Docker image > focused > > solely on the server as they are today. We can then offer the console > (and > > potentially other REST clients) as a sidecar or composable container. > Using > > Docker Compose profiles, we could structure it like this: > > > > services: > > console: > > image: polaris-console... > > profiles: [console] > > server: > > image: polaris-server... > > > > Users could then simply run docker compose --profile console up to > include > > the UI. > > > > In summary, I propose: > > > > 1. Moving the console code to a module within the main repository to > > improve visibility and contributions. > > 2. Providing a Docker Compose setup with profiles and updating the Helm > > chart to include the console as an optional component. > > > > Thoughts? > > > > Regards, > > JB > > > > > > > > On Tue, Jun 2, 2026 at 3:21 AM Yufei Gu <[email protected]> wrote: > > > > > I think the Console is essentially a REST client, so I’m not sure it > > should > > > belong to the server Docker image by default. > > > > > > Could we publish it as a separate client artifact instead, for example > to > > > PyPI or a similar distribution channel, depending on the > implementation? > > > That would keep the server image focused on serving the API, while > still > > > making the Console easy to install, release, and consume. > > > > > > We can still keep it in the main repo, but I didn't see much benefit of > > > doing so when we treat it as a separate deployable component. > > > > > > Yufei > > > > > > > > > On Mon, Jun 1, 2026 at 12:02 PM Romain Manni-Bucau < > > [email protected]> > > > wrote: > > > > > > > I like the on by default in docker, off by default in helm > compromise - > > > > that said it still makes sense to split it for prod if desired cause > it > > > > will not use the same service/httproute at all IMHO, one will be > public > > > > like versus the other can stay internal most of the time. > > > > > > > > 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. 1 juin 2026 à 20:14, Yong Zheng <[email protected]> a > > > écrit > > > > : > > > > > > > > > Hello, > > > > > > > > > > Why not put them in the same repo but keep them separate (similar > to > > > > spark > > > > > plugin which doesn’t get include automatically). Same apply to helm > > as > > > > > people can decide on what to deploy and avoid UI component if > > desired. > > > > > > > > > > As the UI is SPA, the actually calls are from client browser as > > opposed > > > > to > > > > > UI pod, the usability may be limited there in certain use cases. I > > > would > > > > > start a different ML for this topic. > > > > > > > > > > Thanks, > > > > > Yong Zheng > > > > > > > > > > > On Jun 1, 2026, at 11:52 AM, Dmitri Bourlatchkov < > [email protected] > > > > > > > > wrote: > > > > > > > > > > > > Hi All, > > > > > > > > > > > > The idea of moving the UI to the main repo SGTM. > > > > > > > > > > > > I tend to agree with Romain, that the UI should be easy to > > _disable_ > > > > > > because in production environments it may not be intended to run > at > > > > all, > > > > > or > > > > > > perhaps not on the same nodes as the main Polaris server. The > > > > simplicity > > > > > of > > > > > > the UI (static pages + REST API via JS) may not justify always > > > running > > > > it > > > > > > from the SRE perspective, I guess. > > > > > > > > > > > > I'm sure there are multiple ways to tackle this in helm. For a > > > start, a > > > > > > simple on/off helm value might be sufficient, though. > > > > > > > > > > > > Regarding defaults, how about ON by default in plain docker (for > > > local > > > > > > runs), but OFF by default in helm (mostly for "prod" > environments)? > > > > > > > > > > > > Cheers, > > > > > > Dmitri. > > > > > > > > > > > >> On Mon, Jun 1, 2026 at 11:44 AM Romain Manni-Bucau < > > > > > [email protected]> > > > > > >> wrote: > > > > > >> > > > > > >>> Le lun. 1 juin 2026 à 17:35, Robert Stupp <[email protected]> a > > > écrit : > > > > > >>> > > > > > >>> But isn't the concern solved with the configuration option > > "enable > > > > web > > > > > >> UI = > > > > > >>> true|false"? > > > > > >>> > > > > > >> > > > > > >> if default is false it does but breaks the easy by default no? > > > > > >> > > > > > >> > > > > > >>> > > > > > >>> With a standalone web UI, as it exists today, everybody can run > > it > > > > and > > > > > >>> perform "click-ops." > > > > > >>> Similar for custom built web UIs. > > > > > >>> Or if some user extracts the static files and serves their own > > > > instance > > > > > >>> using a local http daemon. > > > > > >>> > > > > > >>> The web UI doesn't allow anything that cannot be done via > another > > > > > >>> interface, such as a terminal and `curl`. > > > > > >>> > > > > > >> > > > > > >> yes but it is less tempting enough to be sufficient for me > > > > > >> > > > > > >> > > > > > >>> > > > > > >>> With that, I'm not sure maintaining multiple different > > > distributions > > > > > >> really > > > > > >>> helps lock people out of web UIs ("click-ops"). > > > > > >>> > > > > > >> > > > > > >> from my windows integrating the ui is not helping since you need > > the > > > > > >> database anyway so maybe the ui outside is sufficient too else > the > > > all > > > > > in > > > > > >> one with h2 or pg will help, i'm not clear on it > > > > > >> > > > > > >> > > > > > >>> > > > > > >>> Robert > > > > > >>> > > > > > >>> > > > > > >>> On Mon, Jun 1, 2026 at 5:15 PM Romain Manni-Bucau < > > > > > [email protected] > > > > > >>> > > > > > >>> wrote: > > > > > >>> > > > > > >>>> Le lun. 1 juin 2026 à 17:12, Robert Stupp <[email protected]> a > > > écrit > > > > : > > > > > >>>> > > > > > >>>>> Hi Romain, > > > > > >>>>> > > > > > >>>>> Disabling the console (web UI) is easy once it becomes part > of > > > the > > > > > >>>>> polaris-server. > > > > > >>>>> > > > > > >>>>> To clarify, the web UI is a static web resource, it doesn't > > > execute > > > > > >>>> web-UI > > > > > >>>>> code in Quarkus. > > > > > >>>>> The UI uses the same authentication and authorization > > mechanisms > > > > that > > > > > >>> any > > > > > >>>>> REST client uses; it is just a UI on top of that. > > > > > >>>>> > > > > > >>>> > > > > > >>>> > > > > > >>>> Yep, this is my issue, it is trivial to use and break the "all > > as > > > > > code" > > > > > >>>> pattern and get back to click-ops pattern. > > > > > >>>> Being API only is less tempting so I'm trying to stick to > that. > > > > > >>>> > > > > > >>>> *Still thinking out loud* but having 3 images sounds the best > of > > > all > > > > > >>>> worlds: > > > > > >>>> > > > > > >>>> * server > > > > > >>>> * frontend/ui > > > > > >>>> * all-in-one (== demo) > > > > > >>>> > > > > > >>>> It is the pattern used by most products (all in one can even > > embed > > > > > >>> postgres > > > > > >>>> to really be ready to use) and everybody will be happy at a > very > > > low > > > > > >> cost > > > > > >>>> in terms of dev/maintenance and infra IMHO. > > > > > >>>> > > > > > >>>> Hope it makes sense. > > > > > >>>> > > > > > >>>> > > > > > >>>>> > > > > > >>>>> Hope this helps, > > > > > >>>>> > > > > > >>>>> Robert > > > > > >>>>> > > > > > >>>>> > > > > > >>>>> On Mon, Jun 1, 2026 at 4:33 PM Romain Manni-Bucau < > > > > > >>> [email protected] > > > > > >>>>> > > > > > >>>>> wrote: > > > > > >>>>> > > > > > >>>>>> Hi, > > > > > >>>>>> > > > > > >>>>>> as an user I have a small request: can it be disabled by > > default > > > > > >> (or > > > > > >>>> made > > > > > >>>>>> unusable by disabling the authn) or at least be made easy to > > > > > >> disable > > > > > >>>>>> (corrollar being: can we get a headless docker image, solves > > my > > > > > >>> concern > > > > > >>>>>> too)? > > > > > >>>>>> rational is that when you have everything automated around > > > polaris > > > > > >>> you > > > > > >>>>>> don't want the UI to be able to mess up things nor render a > > > > > >> different > > > > > >>>>> view. > > > > > >>>>>> not my usage but an in between readonly enforced mode - even > > for > > > > > >>> admin > > > > > >>>>>> users - can be useful I think so maybe 3 modes in terms of > > > toggle: > > > > > >>>> Full, > > > > > >>>>>> ReadOnly, Off or alike. > > > > > >>>>>> > > > > > >>>>>> Shouldn't be crazy to do with quarkus but think it is an > > > important > > > > > >>>>> feature > > > > > >>>>>> to integrate it cleanly as a global solution. > > > > > >>>>>> > > > > > >>>>>> the tricky part is to make the prod and dev defaults > > converging > > > > but > > > > > >>>>> quarkus > > > > > >>>>>> has a profile option by default which can be the way to > solve > > > it. > > > > > >>>>>> > > > > > >>>>>> hope it makes sense. > > > > > >>>>>> > > > > > >>>>>> 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. 1 juin 2026 à 15:28, Jean-Baptiste Onofré < > > > > [email protected] > > > > > >>> > > > > > >>> a > > > > > >>>>>> écrit : > > > > > >>>>>> > > > > > >>>>>>> Hi, > > > > > >>>>>>> > > > > > >>>>>>> Yes, that is indeed part of the proposal. > > > > > >>>>>>> > > > > > >>>>>>> The goal is to provide the UI as soon as the Polaris server > > > > > >> starts > > > > > >>> to > > > > > >>>>>>> ensure a better experience for our users. > > > > > >>>>>>> > > > > > >>>>>>> Regards, > > > > > >>>>>>> JB > > > > > >>>>>>> > > > > > >>>>>>> On Mon, Jun 1, 2026 at 3:12 PM Robert Stupp < > [email protected]> > > > > > >>> wrote: > > > > > >>>>>>>> > > > > > >>>>>>>> +1 > > > > > >>>>>>>> > > > > > >>>>>>>> Could we then bundle the Console with the Polaris server? > > > > > >>>>>>>> > > > > > >>>>>>>> On Mon, Jun 1, 2026 at 8:01 AM Jean-Baptiste Onofré < > > > > > >>>> [email protected] > > > > > >>>>>> > > > > > >>>>>>> wrote: > > > > > >>>>>>>> > > > > > >>>>>>>>> Hi everyone, > > > > > >>>>>>>>> > > > > > >>>>>>>>> As mentioned on the dev mailing list a few days ago, I am > > > > > >>>> currently > > > > > >>>>>>>>> preparing the first release of the Polaris Console. There > > is > > > > > >>>>>>>>> significant interest in the Console, and it is a key > > > > > >> component > > > > > >>> of > > > > > >>>>> our > > > > > >>>>>>>>> efforts to improve the onboarding experience. > > > > > >>>>>>>>> > > > > > >>>>>>>>> After discussing this with Yong, who started to help with > > the > > > > > >>>>>> console, > > > > > >>>>>>>>> we believe that moving the Console into the main Polaris > > > > > >>>> repository > > > > > >>>>>>>>> would provide better visibility and encourage further > > > > > >>>>> contributions. > > > > > >>>>>>>>> This would also allow it to be released as part of the > main > > > > > >>>> Polaris > > > > > >>>>>>>>> release cycle. Additionally, the Console could be > included > > as > > > > > >>> an > > > > > >>>>>>>>> optional component in the main Helm chart, allowing users > > to > > > > > >>>> choose > > > > > >>>>>>>>> whether to enable it. > > > > > >>>>>>>>> > > > > > >>>>>>>>> Thoughts? > > > > > >>>>>>>>> > > > > > >>>>>>>>> Regards, > > > > > >>>>>>>>> JB > > > > > >>>>>>>>> > > > > > >>>>>>> > > > > > >>>>>> > > > > > >>>>> > > > > > >>>> > > > > > >>> > > > > > >> > > > > > > > > > > > > > > >
