Friday, June 10, 2022

We Have Moved! Bitnami Support for Installers, VMs, and Cloud Images is Now Available on GitHub

When you have a problem with a Bitnami solution – whether it’s related to downloading an installer or running a virtual machine or cloud image - you navigate to the Bitnami Community site to find the answers and resolutions you’re looking for, both from Bitnami’s support team and from the community of Bitnami users. Through these interactions, we have built a large community of developers that help each other in solving common issues and thereby help you effectively use our catalog.  

A few years ago, we expanded our offerings to containers and Helm charts and began providing support for them in their natural environment: GitHub. Thus, Bitnami users may have had to navigate to two different sites to solve their issues, depending on the format they were running.  

To provide a unified experience, we will be moving the support for our installers, virtual machines, and cloud images to a GitHub repository as well: This change will be effective from June 30th, 2022. This will allow the Bitnami support team to meet the needs of our users from just one location: GitHub. 

The Bitnami Community site will remain open in read-only mode until July 15th, 2022.  We will migrate the most relevant content of this site to the new GitHub repository. If you will miss something, please do not hesitate to open a suggestion issue. Your feedback will help us to make this transition smoother!  

How Can I Submit a Request to the New Bitnami Support Page? 

If you are not familiar with GitHub, no worries! Our team has compiled everything you need to know on the README file, and incorporated a pinned issue to guide you on how to work with this repository. 

The following instructions walk you through the process of opening a new issue to receive support from the Bitnami team:  

  • Navigate to and, in the search box, enter the matter of your issue. Thus, you can check if there is an open issue that matches the topic you are searching for.  

  • GitHub shows only open issues by default. Hence, if you can’t find your topic in the resulting search, try to filter by closed issues as shown below: 

  • If any of the previous searches do not provide any results, then open a new issue. You can choose amongst three different types of issues depending on the problem you are experiencing: How to (if you want to ask us about how to use a Bitnami solution in a specific scenario), Suggestion (if you have feedback that you think will help us to improve our solutions), or Technical issue (if you are facing a problem or detected a bug when using our applications). 

Our support team will be happy to help you on GitHub! 


Thursday, April 28, 2022

Use Enterprise-Grade Bitnami Apps in Production with VMware Application Catalog

Originally published on the VMware Tanzu blog

Shagun Tewari and Raquel Campuzano Godoy co-wrote this post.

For the past fifteen years, the Bitnami team has delivered pre-packaged open source applications to millions of developers. Over that time, we have evolved our application catalog from delivering our stacks in the form of installers and virtual machines, to cloud native applications, containers, and Helm charts that help you build applications on any platform. Developers use the Bitnami solutions through the Bitnami Application Catalog, which is our name for the catalog available through marketplaces and on 

With over three million developers using our solutions today, there’s no doubt that Bitnami Application Catalog solutions are extremely popular and are ideal for testing purposes in development environments. 

There are, however, constraints with trying to deploy any open-source software in production/enterprise environments, including those from Bitnami Application Catalog. According to a VMware Tanzu survey taken in 2021 on the state of the software supply chain, 95 percent of respondents mentioned that there is no guarantee that vulnerabilities will be remediated, given that ownership of open-source software, in general, remains unclear. Moreover, respondents stated that it’s difficult to keep up-to-date on vulnerabilities so that they can be addressed in time. In reality, keeping up-to-date on every software and dependency vulnerability, and patching in upstream source code, is an enormous effort that few organizations can afford. It is not viable for developer teams to manually track every dependency and to make sure that application components are always updated, healthy, and patched with the latest vulnerability fixes—while guaranteeing internal compliance—instead of focusing on building new business solutions. 

This is where VMware Application Catalog comes in. With VMware Application Catalog, development teams can utilize a rich library of custom, pre-packaged, and trusted building blocks for private enterprise consumption delivered as containers, Helm charts, and virtual machines. These application building blocks are tested on multiple deployment platforms and are continuously and automatically updated for every new vulnerability fix, including those for all dependencies, thanks to an internal automatic build pipeline. 

What is VMware Application Catalog? 

Developers love open source software because it helps energize their application development cycles and offers a wide variety of community-backed technology to choose from. How do we bring these benefits into enterprise environments while avoiding any potential security pitfalls? 

VMware Application Catalog is a customizable selection of trusted, pre-packaged open-source application components that are continuously maintained and verifiably tested for use in production environments.  

It is a library of production-ready Open Virtual Appliances (OVAs), containers, and Helm charts ranging from solutions to integrated code, development applications, automation tools, databases, and other backing services. These catalog images can be plugged into any stage of your company's software lifecycle.

VMware Application Catalog brings users a rich library of pre-packaged open source components in the form of Helm charts, containers, and OVAs. 

So what exactly is special about these images? This catalog can be custom-packaged on any base operating system (OS) provided by a customer. Customers may provide custom golden base OS images or choose from a set of OS images provided by VMware. 

Then, multiple functional and verification tests are run on the packaged image, including build-time Common Vulnerabilities and Exposures (CVE), antivirus scanning, and deployment testing on various platforms. 

Finally, the hardened image, along with the image metadata that contains all vulnerability, antivirus scan, and deployment test results, is pushed to a registry of the customer’s choice for secure, private consumption. 

And last but not the least, VMware Application Catalog offers continuous monitoring of upstream source code changes to automatically trigger image rebuild, testing, and pushes to register new and fixed images. This means that the catalog is always up-to-date. 

How is VMware Application Catalog different from Bitnami Application Catalog?  

A legitimate question for current Bitnami Application Catalog users is: how does VMware Application Catalog differ from Bitnami’s free content? We can sum up the differences by saying that Bitnami Application Catalog is a standard catalog built for the community, while VMware Application Catalog is a custom catalog designed for the enterprise. This statement condenses a list of significant differences such as: 

  • Individual vs enterprise: Bitnami Application Catalog provides software that is intended for a wide range of developers, while VMware Application Catalog supplies a library of assets specifically built to address the security needs of a specific enterprise. 
  • Customization flexibility: Bitnami Application Catalog stacks are built on only one standardized base OS image: Debian. VMware Application Catalog customers can choose to have their images packaged on top of their own golden image (e.g., their own Center for Internet Security-certified Photon OS image), or choose from several hardened Linux flavors provided by VMware Application Catalog.

VMware Application Catalog provides many different base OS images to choose from.


  • Automatic image library refresh: Bitnami Application Catalog releases a new version of its images every time there is a security fix, patch, or new major version available in the upstream code. However, if they’d like to use the refreshed images, developers are required to navigate to the catalog and redeploy the image to update it. With VMware Application Catalog, images are automatically rebuilt and pushed to the private registry every time there is a new version available in the upstream community to ensure the catalog is always fresh. 
  • Detailed bill of materials and metadata for proof of provenance: To get information about the stacks they are running, Bitnami users go to DockerHub or GitHub repositories. VMware Application Catalog users have direct access to extensive metadata in their repositories, which eliminates the need to monitor any external sources. Extensive metadata is served in a JSON file that has information on how to consume the asset, its digest, its build, and release dates, and a complete list of included subcomponents or libraries with license information. We also provide detailed results for CVE, antivirus, and deployment to platform tests, as well as other functional and verification tests conducted on the image for full transparency and visibility. Further, this metadata is digitally signed using a cosignatory to protect it from tampering, which adds another layer of security to the catalog. 

Each asset available in the catalog provides users with all the information they need to consume it.

An example of a test results report which shows all the tests the application went through before being added to the customer’s catalog.

How Bitnami Application Catalog users can benefit from VMware Application Catalog 

Bitnami Application Catalog images are ideal for personal use or development environments, where the stakes are not so high. When it comes to enterprise-grade applications, software supply chain security is of the utmost importance, and developers must abide by strict IT compliance and security rules. VMware Application Catalog provides the goodness of open-source software that developers need to move faster while adhering to security and compliance regulations demanded by the operations and security teams. 

If an enterprise manages a dozen sites, this level of transparency and compliance may be achievable with the work of a single developer or by a small team. However, for large enterprises, moving to production usually means managing hundreds of thousands of applications and sites. In this scenario, companies are forced to dedicate part of their development and site-reliability engineering resources to more tedious tasks, such as tracking all application dependencies and making sure that they are kept up-to-date and patched with the latest CVE fixes to ensure internal compliance. 

VMware Application Catalog allows customers to request images that are custom-packaged on an OS of choice, hardened, security tested, and delivered to a private repository. This frees up developers from the necessity of building their own compliant application components, as well as monitoring external sources and the upstream code to keep their open-source images current. It also provides the security and operations team with detailed metadata for increased visibility and assurance that their software is secure and up-to-date. VMware Application Catalog promotes developer productivity while boosting operator and security team confidence.

Learn more about VMware Application Catalog 

To learn more about VMware Application Catalog, join our webinar session on June 23 at 10 AM PT. Register now for the session! 

For additional information, read about VMware Application Catalog on our product page, browse through all applications available on VMware Application Catalog, or read our newly updated technical documentation. 

For more questions, reach out to the product team directly at

Thursday, March 31, 2022

Kubeapps 2.4.3 - Now Supports for Carvel and Flux Packages

Michael Nelson and Raquel Campuzano co-wrote this blog post 

A new release of Kubeapps is out, and it introduces major changes that mark a milestone in the history of this tool. We are thrilled to announce that the support of different Kubernetes packages has now become a reality with the implementation of the Kubeapps API service. Helm charts are no longer the only option to choose from: now Kubeapps users can deploy Carvel and Flux packages as well! 

In addition to this new capability, the Kubeapps team has solved a long-standing security issue by removing the reverse proxy to Kubernetes API server.  

Keep reading to learn more about how the team has implemented a pluggable architecture that allows users to discover new implementation that make Kubeapps a robust and secure way to deploy applications on Kubernetes infrastructure.  

We will also cover how to deploy and manage Carvel and Flux packages from the Kubeapps user interface (UI).  

Kubeapps APIs – A Pluggable System Supporting Different Kubernetes Packages 

The design of the Kubeapps APIs server solves two main goals for Kubeapps. 

1. Enable pluggable support for presenting catalogs of different Kubernetes packaging formats for installation 

Kubeapps coupled to HelmPrior to this release, Kubeapps was tied closely to the Helm packaging API for listing, installing, and updating Helm charts. The team has abstracted the functionality for listing, installing, and updating packages so that it can be applied to other packaging formats apart from Helm charts. 

Each format is supported by a plugin that implements a core gRPC protocol for package interactions. Since each plugin implements the same packages protocol, Kubeapps can present the results from multiple plugins in the UI, so that, for example, both Helm and Carvel packages can be seen in the catalog together.  

2. Remove the long-standing requirement for the Kubeapps UI to talk directly with the Kubernetes API server 

Kubeapps UI gathering data via the resources pluginSimilarly, prior to this release, the Kubeapps UI needed to communicate directly with the Kubernetes API server and as a result, Kubeapps forwarded requests from the Kubeapps UI through to the Kubernetes API server. The team has now encapsulated the functionality required by the Kubeapps UI into a separate Kubernetes Resources plugin, which allows the Kubeapps UI to, for example, fetch or watch resources created by a specific installed package (if the authenticated user has access to those resources). 

With this change, only a very limited subset of the functionality of the Kubernetes API server is available to the Kubeapps UI. 

A side-effect of these changes is that the client code in the Kubeapps UI can be simplified significantly, which is not only easier to maintain but also opens the possibility for other Kubeapps clients. 

For more details about the implementation of the Kubeapps APIs service, see Kubeapps APIs: A pluggable system supporting different Kubernetes packages. 

New Package Types Discoverable through the Kubeapps UI  

This new release comes with new features and capabilities that provide cluster administrators and operators more flexibility when deploying applications on their Kubernetes environments. Let’s deep dive into them! 

Update your Helm repositories to ensure that you have the latest Kubeapps version. Refer to the Get Started guide to learn how to deploy Kubeapps for your cluster.  

Once you have made some configurations in your cluster and set up Kubeapps to enable Carvel and Flux packages, you will be able to find packages labelled as Helm, Carvel, and Flux when navigating to the “Catalog” section.  


The process of deploying Carvel and/or Flux packages from the Kubeapps UI and managing applications is similar to the processes followed for a Helm chart, but there are some requirements that your cluster must carry out to make sure that the deployment of these new packaging formats will work. 

Deploy and Manage Carvel Packages with Kubeapps 

Check out this step-by-step guide to learn how to manage Carvel packages with Kubeapps. 

Carvel is usually defined as a set of tools that helps you to build and configure applications for their deployment on Kubernetes. To enable the consumption of Carvel packages from the Kubeapps UI, you must make some configurations first. 

These are the pre-requisite steps to follow to make sure that both your cluster and Kubeapps deployment are ready to work with Carvel packages: 

  1. Install kapp-controller in your cluster 
  2. Configure Kubeapps to support Carvel packages 
  3. Install a package repository 
  4. Create a service account in your namespace 

Once everything is arranged, you’ll be ready to pick packages to deploy on the Kubeapps UI by navigating to the “Catalog” section. 

  • Log in to Kubeapps and navigate to the “Catalog” section. Search for Carvel packages:  

  • Pick an application to deploy. This blog post uses Contour as an example, but you can choose any other application from your catalog. 

You will find detailed information about the package you’re about to deploy such as the requirements, release notes, where to find support, licenses, or the maintainers of the image. 

  • Select the version you want to deploy. And click “Deploy” to continue:  

  • In the resulting screen, add a name for your deployment, select the service account, and make changes to the YAML file if applicable. Click “Deploy” to finish the process.  

  • Navigate to the “Applications” section. If the deployment went smoothly, your application will show a green label saying that the package was installed successfully in your cluster.  
  • Click on “Show apps in all namespaces” to get an overview of the applications running in your cluster regardless of the namespace.  

  • Look at the deployment details by clicking on the application you just deployed.  

In the resulting screen, you will have access to meaningful information such as the number of pods deployed, access URLs, secrets, installation notes, and application resources. Note that from this page, you can also upgrade your application to the next version available or delete it from your cluster.  

 Deploy and Manage Flux Packages with Kubeapps 

Check out this step-by-step guide to learn how to manage Flux V2 packages with Kubeapps. 

Flux is a set of continuous and progressive delivery solutions for Kubernetes that are open and extensible. The latest version of Kubeapps allows you to manage Helm releases declaratively with Kubernetes manifests via Fluxv2. Similar to Carvel packages, there are some previous configurations that you must perform in your cluster and Kubeapps installation to fully activate Flux packaging support.  

These are the pre-requisite steps to follow to make sure that both your cluster and Kubeapps deployment are ready to work with Carvel packages: 

  1. Install Flux controllers in your cluster 
  2. Configure Kubeapps to support Flux Helm release 
  3. Install a Flux Helm repository 
  4. Create a service account in your namespace 

Now everything is ready for the deployment of Helm packages via Flux.  

  • Log in to Kubeapps and navigate to the “Catalog” section. Search for Flux packages:  

  • Pick the package you want to install. We use Apache as an example.  

Enter the configuration parameters for your deployment. Note that for Flux, you must enter a ServiceAccount to be used for installing the package. Apart from that, the process for deploying and managing Flux packages is similar to those for any other packages available in Kubeapps.   

Laying Down the Foundation for Future Improvements 

Thanks to the implementation of the Kubeapps API service, we will be able to move forward and support different packaging formats in the future as the Kubernetes landscape and the needs of users will evolve. The current release lays down the foundation for making Kubeapps a more inclusive and secure path for Kubernetes deployments.  

Support and resources   

Since Kubeapps is an OSS project, support for this version of Kubeapps will be provided on a best-effort basis. To get a resolution on issues such as deployment support, operational support, and bug fixes, please open an issue in the Kubeapps GitHub repository. A markdown template is provided by default to open new issues, with certain information requested to help us prioritize and respond as soon as possible. Also, if you want to contribute to the project, feel free to send us a pull request, and the team will check it and guide you in the process for a successful merge.  

In addition, you can reach out to Kubeapps developers at #kubeapps on Kubernetes Slack (click here to sign up).  

For more information about the topics discussed in this blog post, refer to the following links: