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
> > > >>>>>>>>>
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>
> > > >>>
> > > >>
> > >
> >
>
