Hi,
we recently ran a technical spike on a very similar scenario.
We tested exposing a single VCD instance through an additional public FQDN using NGINX reverse proxy (HTTPS termination + HTTPS backend), without any VCD-side reconfiguration.
Result of the test:
-
The VCD UI loads correctly via the alternative FQDN.
-
However, during login the UI fails with “Failed to Start / bootstrap-failure”.
-
Browser dev tools show CORS errors: the frontend (loaded from the new domain) still performs API calls to the original VCD FQDN (e.g. /api/session, /api/versions).
-
Because the origins differ, the browser blocks the requests. Rewriting headers and basic proxying is not sufficient.
We also verified that this is not a pure NGINX issue: the frontend uses absolute URLs and runtime-generated endpoints tied to the canonical VCD hostname, so cross-origin calls occur before the proxy can help.
At this point it looks like:
-
Reverse proxy alone is not a viable/supported way to expose VCD on multiple public domains.
-
Even with rebranding / three-tier tenancy, VCD still behaves as a single-FQDN application.
Question:
Have you (or anyone) successfully implemented:
-
a reverse proxy–based solution that works end-to-end (login + UI), or
-
a native VCD configuration (e.g. allowed origins / base URI changes) that truly supports multiple public UI domains?
In our tests, the page loads but login consistently breaks due to CORS, so we are leaning toward separate VCD installations per brand/provider as the only clean solution.
Thanks in advance for any real-world feedback.