[GH-ISSUE #103] Multiple Sites #57

Closed
opened 2026-05-07 00:18:27 +02:00 by BreizhHardware · 3 comments

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.

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.
BreizhHardware 2026-05-07 00:18:27 +02:00
  • closed this issue
  • added the
    question
    label
Author
Owner

@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 site to 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

<!-- gh-comment-id:3598055272 --> @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 `site` to 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
Author
Owner

@idominiki commented on GitHub (Apr 20, 2026):

Maybe this can be done using the new Fabrics feature?

<!-- gh-comment-id:4282549389 --> @idominiki commented on GitHub (Apr 20, 2026): Maybe this can be done using the new Fabrics feature?
Author
Owner

@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 internal API's are still not back in the current public API. (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

<!-- gh-comment-id:4282685446 --> @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 `internal` API's are still not back in the current `public` API. (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
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/unifi-voucher-site#57
No description provided.