This guide is for operators upgrading an existing LiteMaaS deployment (v0.3.x) to v0.4.0. If you are deploying LiteMaaS for the first time, follow the standard Helm or Kustomize deployment guides instead.
Upgrading from v0.1.x? First follow the v0.2.0 Upgrade Guide, then return here.
See the CHANGELOG for the full list of changes. Highlights include:
- Model Capability Management: Multi-type model support (Chat, Embeddings, Document Conversion) with Tokenize capability and type-specific UI behavior
- Custom LiteLLM fork with Docling document conversion endpoint and
/tokenizesupport - Optional Redis integration for faster model CRUD propagation across LiteLLM proxy pods
- Model sync reliability fixes preventing deleted models from reappearing
LITELLM_DATABASE_URLexpanded role — now used for model sync cross-referencing in addition to backup/restore
| Change | Required? | What | Why |
|---|---|---|---|
| LiteLLM image | Yes | Switch from upstream ghcr.io/berriai/litellm-non_root to custom fork quay.io/rh-aiservices-bu/litellm-non-root:main-v1.81.0-stable-custom |
Adds Docling document conversion and /tokenize endpoints |
LITELLM_DATABASE_URL |
Recommended | Ensure this env var is set (may already be if backup/restore is configured) | Now also used by model sync to cross-reference LiteLLM_ProxyModelTable, preventing deleted models from reappearing |
| Redis | Optional | Deploy a Redis instance shared by LiteLLM and the backend | When available, the backend flushes LiteLLM's cache after model CRUD for immediate propagation. Without it, changes still work but may take longer to appear across proxy pods |
- Back up both databases (
litemaas_dbandlitellm_db) — use the built-in Backup feature orpg_dump - Review the CHANGELOG for any configuration changes that affect your deployment
- Build and push new LiteMaaS v0.4.0 container images (or pull them from your registry)
- Check whether
LITELLM_DATABASE_URLis set in your deployment (check your Helm values or Kustomize secrets) — if not, consider adding it
helm upgrade litemaas deployment/helm/litemaas/ -n litemaas \
--set backend.image.tag=0.4.0 \
--set frontend.image.tag=0.4.0With the default Helm values, this automatically:
- Switches the LiteLLM image to the custom fork (new default in
values.yaml) - Deploys Redis (
redis.enabled: trueby default) - Auto-constructs
REDIS_HOSTfrom the release name - Auto-constructs
LITELLM_DATABASE_URLfrom PostgreSQL credentials (ifpostgresql.enabledis true)
If you override litellm.image in your values file, update it explicitly:
litellm:
image:
repository: quay.io/rh-aiservices-bu/litellm-non-root
tag: "main-v1.81.0-stable-custom"If you don't want Redis, disable it:
redis:
enabled: falseEverything still works — cache flush is silently skipped.
If you already have an external Redis, disable the built-in one and point to yours:
redis:
enabled: false
backend:
redis:
host: "my-external-redis.example.com"
port: "6379"-
Update LiteMaaS images in your deployment manifests to v0.4.0.
-
Update the LiteLLM image in
litellm-deployment.yaml:image: quay.io/rh-aiservices-bu/litellm-non-root:main-v1.81.0-stable-custom
-
(Optional) Add Redis —
redis-deployment.yamlandredis-service.yamlare included in the Kustomize base. To enable, ensure they are listed in yourkustomization.yamland thatREDIS_HOSTis set in the backend deployment env vars:resources: - redis-deployment.yaml - redis-service.yaml
-
Verify
LITELLM_DATABASE_URLis set in yourbackend-secret. If you already use backup/restore, it should be there. If not, adding it is recommended to prevent deleted models from reappearing after sync. -
Apply:
oc apply -k deployment/kustomize/
Wait for all pods to become ready, then verify:
# Backend health
curl <backend-url>/api/v1/health
# Expected: 200 with litellm: "healthy"
# LiteLLM health
curl <litellm-url>:4000/health/liveness
# Expected: 200Then test through the UI:
- Model list loads correctly with capability labels (Chat, Embeddings, etc.)
- Create a model via Admin > Models — verify it appears immediately without needing a sync
- Delete a model — verify it does not reappear after a few seconds
- Create an API key — View Key modal shows correct curl example for the model type
- Chat Playground only shows chat-capable models
- If using Document Conversion models: create one with type "Document Conversion" and verify the
/healthendpoint test works
| Scenario | Action | Risk |
|---|---|---|
| LiteMaaS update fails | helm rollback litemaas |
Low |
| LiteLLM fork issues | Revert litellm.image to previous upstream image — LiteMaaS still works but Docling/tokenize features are unavailable |
Low |
| Redis issues | Set redis.enabled: false and remove REDIS_HOST — cache flush is silently skipped, model CRUD still works |
Low |
| Variable | Description | Default | Required |
|---|---|---|---|
REDIS_HOST |
Redis hostname for LiteLLM cache flush after model CRUD | - | No |
REDIS_PORT |
Redis port | 6379 |
No |
LITELLM_DATABASE_URL is not new but its role has expanded — it is now also used by model sync to verify models against LiteLLM's database. See the Configuration Guide for details.
Redis can be used by both LiteLLM (model/key caching) and the LiteMaaS backend (cache flush after model CRUD). A single shared instance is sufficient.
- Helm: Deployed automatically when
redis.enabled: true(default). Usesredis:7-alpinewith 64Mi-128Mi memory limits. Disable withredis.enabled: false. - Kustomize: Available via
redis-deployment.yamlandredis-service.yaml. Add them to yourkustomization.yamlif desired. - Without Redis: Everything works. Cache flush after model CRUD is silently skipped. Model changes may take longer to propagate to all LiteLLM proxy pods (depends on LiteLLM's internal cache TTL).