Licensed to be used in conjunction with basebox, only.
basebox.ai on-premise FAQs
Installation
How do I install basebox.ai on-premise?
Use one of these paths:
- Server Preparation Guide for infrastructure prerequisites
- Local Quick Start for
basebox.localinstalls - Using Helm Charts for real domains, cert-manager, or existing TLS secrets
Can I change the behaviour of the support button in the user menu?
Yes, you can set the VITE_BB_SUPPORT_BUTTON_LINK in the frontend configuration. Set it to a URL you want the user to be redirected to when clicking the button. If you set it to an empty string, the button will be hidden.
Troubleshooting
Instead of a login page, I see an "Organisation not found" page.
Make sure you have set VITE_BB_OIDC_FORCE_REALM in the frontend configuration to primary.
I only see a spinner when trying to access the application.
Press F11 to see the browser console and check the log.
Idp/Keycloak not reachable
Look for entries that indicate problems to connect to your Keycloak instance.
I see /auth/... Failed to load resource: the server responded with a status of 404 (Not Found)
If you see a 404 related to auth, most likely the path to your IdP (e.g. keycloak) is incorrect. Check the VITE_BB_OIDC_DOMAIN frontend environment variable; it must end in a slash and usually with the realms/ directory, e.g. https://keycloak.your-domain.de/auth/realms/.
If you get a JSON response from curl -k https://localhost/auth/realms/primary/.well-known/openid-configuration (the URL might need slight adoption to your configuration), the correct value for VITE_BB_OIDC_DOMAIN is "https://basebox.your-domain.de/auth/realms/" (note the trailing slash).
After login, the application enters a redirect loop.
This usually means that authentication fails at an unexpected point. We are working on improving the error handling here.
- Clear the browser data (cookies and local storage) and try again.
- If that does not help, check the browser console; if you see INVALID_TOKEN errors, check also the
aisrvlogs. See below questions for more hints.
aisrv log contains "iss does not match" messages.
This indicates that the AISRV_OIDC_IDP_URL setting for AISRV is not a base URL or the same as the VITE_BB_OIDC_DOMAIN setting for the frontend. If these two values really need to be different, you can also set the AISRV_OIDC_ISSUER_URL variable for aisrv to the expected ISS value directly, as stated in the log.
However, you have to be careful here: basebox aisrv uses this value to determine if an access token a browser is using to connect has actually been issued by the right Keycloak/IdP instance. If you set this to a foreign issuer, that issuers tokens can be used to access your basebox instance.
I see an error message "data transmission failed (SSE)" or similar ("Fehler bei der Datenübertragung" in German)
Check the browser console and especially aisrv logs. The problem could lie between the browser and the server, or between aisrv and the inference endpoint - or ragsrv.
inference and ragsrv-support fail to start: Temporary error in name resolution
This is a common issue if you run the cluster with k3s on Linux systems that use systemd (virtually all, e.g. Ubuntu and Debian). See here for more details. The simplest solution is to tell the coredns pod to use a DNS server directly; note that the host's systemd-resolved at 127.0.0.53 will not work. If no DNS server is available, you can use Cloudflare's at 1.1.1.1 or Google's at 8.8.8.8
To set the DNS server, do:
This will open your system editor (vi by default); look for a line forward . /etc/resolv.conf and replace it with:
Then restart the coredns pod:
This example is using Cloudflare's DNS service with a fallback; substitute with your DNS server if applicable.