Skip to content

Kubeapps

Kubeapps is deprecated. The upstream Kubeapps project (vmware-tanzu/kubeapps) was deprecated and its repository archived on August 25, 2025, and no longer receives updates. The maintainers point to the community fork SAP/kubeapps. For new deployments, prefer the Helm CLI with each application’s official chart repository. The steps below remain accurate where Kubeapps is still available.

Kubeapps is a web-based UI for deploying and managing applications in your Kubernetes clusters, available at https://apps.h8l.io.

Kubeapps dashboard

Click on “LOGIN WITH H8LIO” on the https://apps.h8l.io login page to authenticate on the dashboard.

If you are the owner, administrator or operator of your h8lio domain, you can add your own repositories or OCI registries to the current context by clicking on the top right header menu icon and the menu entry “Add Repositories”. The developers of your domain have a read access.

Refer to the documentation to add a private Repository or a Helm Repository.

If you get the warning message on your Chart “There is a problem with this package: this package has missing information, some actions might not be available.”, it is very likely that your Chart is missing its repository in the current context.

Check the Helm configuration to specify the application values before to install or upgrade a Chart.

On your h8lio domain’s dashboard you can see the “Applications” tab (beside the “Services” tab) which lists the charts present in your current cluster.

In August 2025, Bitnami restructured its public container catalog. If your services rely on Bitnami images, the changes below affect you.

reference #83267

Bitnami restructured its container image catalog with the following key changes:

  • Community Tier (Free): only a limited subset of hardened images remains available for free, intended for development use only. These are only available with the “latest” tag.
  • Legacy Repository: all existing container images, including versioned tags (e.g., 2.50.0, 10.6), were moved from docker.io/bitnami to docker.io/bitnamilegacy. These legacy images receive no further updates or security patches.
  • Open Source Code: all Helm charts and container images’ open-source code continue to be maintained and accessible on GitHub under the Apache 2 license, allowing you to build your own images if needed.

Bitnami made this transition to:

  • Provide more secure, hardened container images with better security practices
  • Focus their free offerings on development use cases while maintaining open-source code availability
  • Streamline their catalog while ensuring users can still build from source when needed

If your services still use Bitnami images:

  • Identify all applications using Bitnami images from docker.io/bitnami
  • Check which specific image tags you are currently using
  • Determine if your usage is for development or production environments

Quick check command:

Terminal window
# Check for Bitnami images in your Kubernetes cluster
kubectl get pods -n [your-namespace] -o jsonpath='{range .items[*]}{"\n"}{.metadata.name}{"\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' | sort | grep bitnami

For development environments:

  • Check if your required images are available in the new community tier at docker.io/bitnamisecure
  • If available, update your configurations to use only the “latest” tag
  • If not available, consider the temporary legacy repository option below

For production environments:

  • Recommended: build your own images from the open-source code available at bitnami/containers
  • Temporary workaround: update image references to use docker.io/bitnamilegacy (not recommended for long-term use as these will not receive security updates)

If staying with free community images:

Terminal window
# Update your image references to:
docker.io/bitnami/[image-name]:latest docker.io/bitnamisecure/[image-name]:latest

If using legacy repository temporarily:

Terminal window
# Update your image references to:
docker.io/bitnami/[image-name]:[version] docker.io/bitnamilegacy/[image-name]:[version]

For Helm charts: If your Helm charts are failing to pull images, you can temporarily update them:

Terminal window
helm upgrade [RELEASE_NAME] [CHART_NAME] \
--version [SAME_VERSION] \
--set image.repository=bitnamilegacy/[image-name] \
--set global.security.allowInsecureImages=true

Warning: images in the legacy repository (docker.io/bitnamilegacy) do not receive security updates. Using these images in production environments poses security risks and should only be done as a temporary migration measure.

For production workloads, we strongly recommend building your own images from the open-source code available at bitnami/containers, which continues to be maintained and updated.

While migrating away from Bitnami images, consider these alternative approaches for managing your application deployments.

Official Helm chart repositories with Kubeapps

Section titled “Official Helm chart repositories with Kubeapps”

Use official Helm chart repositories through apps.h8l.io (Kubeapps) to discover and install applications directly from their maintainers:

  • Access the Kubeapps interface to browse official chart repositories
  • Install applications using their official Helm charts, which often use official Docker images
  • Benefit from direct support from application maintainers

see Repositories chapter for more details

Manage applications using Helm directly with official chart repositories:

Terminal window
# Add official chart repository
helm repo add [app-name] [repository-url]
helm repo update
# Search for available charts
helm search repo [app-name]
# Install application
helm install --namespace [your-namespace] [release-name] [repo/chart-name] -f values.yaml

Beginning in Helm 3, you can use container registries with OCI support to store and share chart packages (see documentation).

GitOps approach with version-controlled configurations
Section titled “GitOps approach with version-controlled configurations”

You could create a Git repository (for example, a new service on h8l.io called “apps” or “platform”) to manage your application configurations:

  • Structure: use Git branches per environment (dev, qualif, prod, etc.)
  • Benefits: store, version, and compare Helm configurations across environments and new releases
  • Workflow: track configuration changes through Git history

Once you checked out your new git repository, and with the local commands kubectl and helm, you can create a directory per application with a README.md file which contains the installation and upgrade instructions.

Example for MinIO deployment:

  • Installation
Terminal window
# Add official repository
helm repo add minio https://charts.min.io/
helm repo update
helm search repo minio/minio
# Check current deployments
helm --namespace [your-namespace] list
# Generate and customize values
helm show values minio/minio > values.yaml
cp values.yaml minio.yaml
# edit minio.yaml with your specific configuration
# (optional) check latest image tag release:
# https://github.com/minio/minio/releases/latest
# https://github.com/minio/mc/releases/latest
# Install with custom configuration
helm install --namespace [your-namespace] minio minio/minio -f minio.yaml
  • Upgrade
Terminal window
# Update repository
helm repo update
helm search repo minio/minio
# Check current status
helm --namespace [your-namespace] list
# Compare configurations
helm show values minio/minio > values.yaml
# diff values.yaml and minio.yaml to see changes
# (optional) check latest image tag release:
# https://github.com/minio/minio/releases/latest
# https://github.com/minio/mc/releases/latest
# Upgrade your chart with the updated configuration
helm upgrade --namespace [your-namespace] --history-max=2 minio minio/minio -f minio.yaml

This approach gives you better control over your deployments, clear configuration versioning, and the ability to use official images directly from application maintainers.

The installed applications using the command lines will also be visible on h8l.io and apps.h8l.io dashboards.