If you run into issues or have questions, we recommend posting in our #feat-vtadmin Slack channel. Click the Slack icon in the top right to join. This is a very active community forum and a great place to interact with other users.
The following is from the local example showing a minimal set of environment variables. $web_dir, in this case, refers to the vtadmin-web source directory but could equally apply to the web/vtadmin/ directory copied into a Docker container, for example. VITE_VTADMIN_API_ADDRESS uses the same hostname as the --addr flag passed to vtadmin in the previous step.
After running build command, the production build of the front-end assets will be in the $web_dir/build directory. They can be served as any other static content; for example, Go's embed package or npm's serve package. Each filename inside of $web_dir/build/assets will contain a unique hash of the file contents.
Now that you can build and run VTAdmin, there are a few best practices you should follow before deploying into production.
Because VTAdmin by definition has access to potentially-sensitive information about your clusters, it's important to ensure that only the right people have access to those resources.
VTAdmin provides RBAC to provide administrators a mechanism for controlling who can perfom what actions across their clusters.
Out of the box, having no RBAC configuration at all will allow anyone to do anything in any cluster, while an empty RBAC configuration will prevent anyone from doing anything in any cluster.
It is strongly recommended to provide at least some minimal RBAC configuration when deploying VTAdmin.
When designing your particular configuration, it is best to apply the principle of least privilege.
For example, you should avoid applying a * actor to a write action, or a * action to resources that are subject to write actions.
For further reading on VTAdmin's RBAC design, please refer to the reference page.
There is no trust boundary between vtadmin-web and vtadmin-api, with deployment-specific authentication mechanisms being left to the operator to design for their specific environment.
As such, you should deploy VTAdmin within a trusted environment, for example, behind a single sign-on (SSO) integration, such as okta.