mirror of
https://github.com/glenndehaan/unifi-voucher-site.git
synced 2026-05-09 08:25:29 +02:00
[GH-ISSUE #103] Multiple Sites #57
Labels
No labels
bug
enhancement
pull-request
question
question
question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/unifi-voucher-site#57
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @jdieStrama on GitHub (Dec 1, 2025).
Original GitHub issue: https://github.com/glenndehaan/unifi-voucher-site/issues/103
Originally assigned to: @glenndehaan on GitHub.
The question
Hi,
i like your tool. It is exactly what i was looking for.
Is there a way to add multiple sites?
At the moment I'm running three containers for our three sites.
@glenndehaan commented on GitHub (Dec 1, 2025):
Hi @jdieStrama,
This is a duplicate of #63.
And is something that won't be implemented. It is indeed recommended to run an instance per UniFi Site.
The explanation for this is simple, the purpose of the app is to expose a simple UI to end-users. And the introduction of a
siteto users would complicate the UI a lot. It would also make the Kiosk for example more complicated to setup, since you would now need control over every kiosk for every site available.It would also main a complete rewrite of the backend logic of the app. At some point I introduced a mechanism for slower Cloud Key Gen 1/2 to cache the vouchers (Since a lot of users complained about loading times). This is completely based on the fact that there is 1 site active, changing this would mean a rewrite of all logic.
Maybe I will consider it in the future if the app grows more, but for now I don't see it as an option.
Kind regards,
Glenn de Haan
@idominiki commented on GitHub (Apr 20, 2026):
Maybe this can be done using the new Fabrics feature?
@glenndehaan commented on GitHub (Apr 20, 2026):
Hi @idominiki,
Unfortunately this won't change anything. The same problems would still count and would require a complete rewrite of logic.
Also it would introduce a new issue: Requiring users to utilize the UniFi Site Manager.
And this is a whole new rabbit-hole I don't even want to start the discussion on. I know a lot of people who actively block any and all connection to UniFi's cloud services and only want local control. If I would even consider making that switch I would either have to maintain 2 versions, 1 local and 1 cloud. Or have to drop the local control entirely, something that I don't feel is reasonable for users to ask in a world where people want to be less dependent on external cloud hosted services.
I get what UniFi is trying to do, but if the API is not locally on the controller I don't see it as a complete solution. Even basic things that used to work with the
internalAPI's are still not back in the currentpublicAPI. (Ehm: https://community.ui.com/questions/Feature-Request-Network-API-Guest-Access-Voucher-ID/d3c470e2-433d-4386-8a13-211712311202)So for now my original standpoint still stands, if you have multiple sites you have to host multiple instances. For most people this would work since every site should have it's own UniFi controller.
I know some people have 1 dedicated controller for multiple sites, and then this is not the best solution. But from an UI/UX and backend perspective this currently still is the best solution in my mind.
Kind regards,
Glenn de Haan