Hi @Houbsi, good question. This is how it works: any XO instance that is connected to a pool will add some information about itself to the pool's metadata XO Lite reads that information to know the URL of XO's UI In xo-server's config, you can force XO to report a custom URL instead of raw network information: [http] publicUrl = 'http://example.com' However, at the moment, XO Lite doesn't support it, but it's coming soon: https://github.com/vatesfr/xen-orchestra/pull/7849 And @olivierlambert, yes, for now, any XO instance, whether it's an XOA or not, reports itself on the pool and we simply pick the latest one. But we can definitely implement something smarter in the future if necessary. pdonias opened this pull request in vatesfr/xen-orchestra closed feat(lite/XoaButton): support `xo-server`'s setting `http.publicUrl` #7849

@Tristis-Oris said in XOLite - Which URL?: @itpartner it already builtin at xen 8.3, so guide will not requried. This, XCP-ng 8.3 isn't released yet, so you're running 8.2 which doesn't include the package.

@hellst0rm I don't see why it wouldn't work as long as everything is set to trust your internal CA root. It's pretty trivial to create a CA. I did it years ago because I can't stand cert errors and as a learning exercise. The only annoying part is it's just one more thing to keep track of and update, but if you're running a homelab it just becomes another part of the exercise.

@borzel With my PWA manifest merged you can do further development work around it if you wish. However don't add to much extra Java script if you do so, as it can seriously affect performance and security. Also too many abstractions can affect the ability to understand how Xen Orchestra, as well as XCP-ng works and fix any issues, by thus limiting the number of people who can understand the code and its workings in order to fix them. As read any code from libraries and frameworks used in order to understand them and avoid any vulnerabilities in the code. Not to mention that people who wish to use it may not have Java script enabled browsers or have Java script disabled (maybe even blocked). If the software can't work at all without Java script in the browsers currently support available at the moment now, then they will boycott using the software or website.

I'm not waiting for your suggestion to do it, it's already in the backlog