Skip to content
Copyright © 2022-2026 basebox GmbH, all rights reserved.
Licensed to be used in conjunction with basebox, only.

// installation

Validate installation

Applies to

Product: Server · Audience: Platform Operator

Acceptance checks before releasing to users: pods ready, GPU resources bound, chat, RAG, OCR and STT each verified once, reboot test passed, manifest recorded. Run the checks with synthetic test data – no customer, patient or production data – and record operational metadata, not prompts, documents or answers.

1. Platform

kubectl -n basebox get pods -o wide                 # all Running, restart count 0
kubectl -n basebox get job                          # idp-keycloak-bootstrap Complete
kubectl -n basebox get cluster                      # CNPG clusters healthy
kubectl -n basebox get pvc                          # all Bound
kubectl -n basebox get ingress                      # host = global.domain
kubectl -n basebox get certificate 2>/dev/null      # with cert-manager: Ready
kubectl -n basebox get events --sort-by='.lastTimestamp' | tail -20
  • All pods Running, no restarts
  • Bootstrap job complete
  • Database clusters healthy, PVCs bound
  • Ingress and TLS correct; browser shows a trusted certificate (with local the expected warning)

2. GPU allocation

kubectl describe node <node> | grep -A8 -E "Capacity|Allocatable|Allocated resources"
kubectl -n basebox describe pod -l app.kubernetes.io/name=inference | grep -A3 "nvidia.com/"
kubectl -n basebox exec -it <inference-pod> -- nvidia-smi
  • The node advertises the expected resources (e.g. nvidia.com/gpu: 1 and nvidia.com/mig-1g.35gb: 4 for 2 × H200)
  • Inference is bound to the whole GPU(s)
  • Every service workload holds its own GPU or MIG instance
  • No workload shares the inference GPU's memory

3. Functional check through the application

Sign in with the administrator account (basebox-admin-secret) and once each:

Check Procedure Expected
Login Browser → https://<domain> → sign in Interface loads; "About" shows version, model, context size, realm
Chat Ask a short question Answer streams; no error
Long context Paste a longer synthetic text and have it summarised Answer without context error up to the configured size
Reasoning (if the model supports it) Choose reasoning level High Train of thought appears and can be collapsed
RAG Create an app with knowledge base, upload a synthetic PDF, ask a question Processing status complete; answer with source chips; original download works
OCR Upload a scanned PDF or image with text Text is recognised and answered
STT Upload a short synthetic audio file, "Transcribe" Transcript appears; microphone dictation works
Generate documents "Create a Word document with …" File available for download
Connectors (if enabled) Administration → Connectors → Test connection Test successful
API curl $URL/v1/models with an API key Model list; chat completion successful
Audit log Administration → Audit log Login and actions appear; CSV export works
  • All rows passed

4. Failure behaviour

  • Stop inference in a maintenance window (kubectl -n basebox scale deploy/inference --replicas=0 or block the external endpoint): chat shows an error, no silent fallback
  • Start inference again: chat works after warm-up without intervention

A bounded run with simultaneous chat, document ingestion, OCR and STT shows whether service models and inference get in each other's way. Reference of the 2 × H200: 60 minutes of mixed load, 720 short and 12 long LLM requests, 12 service load spikes, 0 inference restarts.

  • No workload restarts during the mixed load
  • Chat response times stay stable while documents are processed

6. Reboot test

sudo reboot
# afterwards:
kubectl get nodes
kubectl describe node <node> | grep -A8 Allocatable
kubectl -n basebox get pods
  • GPU resources and MIG layout return
  • All workloads become Ready again; inference after warm-up (cold start about 6 minutes for 2 × H200)
  • Persistent data intact: the test app's knowledge base still answers

7. Monitoring and backup

  • Health endpoints reachable (/health of AISRV and inference; /health/ready of Keycloak)
  • Metrics flowing, if configured (AISRV_METRICS_PORT, enablePodMonitor, DCGM) – see Monitoring
  • A first backup of the databases created and a restore rehearsed – see Backup & restore

8. Record the manifest

Record – without credentials:

helm list -n basebox
kubectl -n basebox get deployments -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.template.spec.containers[0].image}{"\n"}{end}'
nvidia-smi --query-gpu=name,uuid,driver_version --format=csv
nvcc --version | tail -1
kubectl version --short 2>/dev/null || kubectl version
helm version --short
kubectl get pods -n gpu-operator -o jsonpath='{.items[0].spec.containers[0].image}'
  • Chart and app version, image digests, model and quantisation, driver, CUDA, Kubernetes, Helm, GPU Operator, firmware, GPU UUIDs with role, MIG layout, values files used (without secrets)

9. Handover

  • First administrator's credentials handed over securely; Keycloak admin stays with operations
  • Administrators know their entry point: Administration; they create a second administrator immediately
  • Operational responsibility settled: Operations
  • For custom hardware: completed Custom hardware document sent to basebox

All ticked? Then the installation is accepted. From here on, Operations applies.