For several years, Bitnami offered many standard cloud component Container images and Kubernetes Helm charts, e.g. for PostgreSQL, MariaDB, Redis, or MongoDB. I think they were well maintained, used in many production setups, and used with Bitnami subscriptions by paying customers. Also governments used them (e.g. the German government with openDesk and BundesMessenger or the European Commission with SIMPL-Open). In 2019, Bitnami was bought by VM Ware.

In 2025, Bitnami revaluated their business case and decided to discontinue their current offering:

• https://community.broadcom.com/tanzu/blogs/beltran-rueda-borrego/2025/08/18/how-to-prepare-for-the-bitnami-changes-coming-soon,
• https://github.com/bitnami/containers/issues/83267

In a time, where many customers find their dependency with VM Ware already problematic, customers are sceptical towards a mere upgrade to the new Bitnami offering. So it comes to no surprise, that the Internet is full of discussions on alternatives. Before I present three of them, let me recall the challenges:

• supply chain security
• complexity due to diverging supply chain sources
• transparency
• compliance with NIS2 (Network and Information Security (NIS) Directive 2, adopted in November 2022 and in principle effective from 2025), example measures from nis2compliant.org:
  • robust vulnerability handling and disclosure practices
  • Secure supply chain interactions and mitigate risks related to suppliers or service providers, ensuring comprehensive security from end to end
  • incident detection, triage, and response to meet reporting obligations
• Cybersecurity Regulation for EU institutions, e.g.
  • supply chain security, including security-related aspects concerning the relationships between each Union entity and its direct suppliers or service providers
  • establishment of software supply chain security through criteria for secure software development and evaluation
• any other applicable national legislation

So what are the options to manage supply chain security with a view of reaching compliance? I believe it is impossible for an individual organisation to take care of the supply chain security directly for all their software in use. On top, any attempt would not be good use of (public) money. Hence, the goal must be to outsource and to seek synergies with organisations having similar or higher requirements.

CloudPirates.io

• https://github.com/CloudPirates-io/helm-charts

Some German products may switch from Bitnami to CloudPirates.io. CloudPirates is a company like Bitnami, but it is in Germany and hasn’t been bought by VM Ware (yet). Read their German blog post addressing the Bitnami policy change. I have checked their MariaDB helm chart. It relies on the community MariaDB container.

To ensure compliance when using their work, it may be necessary to introduce obligations for CloudPirates, which they may allow only against a fee.

In alternative would be RedHat Linux, that also offers all kinds of containers with maintenance against a fee.

Self-Made Distroless Containers

• https://www.move-online.de/k21-meldungen/containerhaertung-auf-opencode/ (in German)

Governments could build containers for their own ministries. This is what parts of the German government currently explore. But then, there are many ways how this can be organised.

• Upstream: The Government could just review the community images that everyone is using. However, the community may not be reactive enough or have diverging standards, etc.
• Downstream: The Government could maintain their own downstream fork and still collaborate with the community.

In both situations, you have to decide with which community. Consider for instance MariaDB. Relevant communities are:

• the MariaDB community
• the Debian community that packages (and patches) MariaDB
• the Opensuse community that packages (and patches) MariaDB
• the NixOS community that packages (and patches) MariaDB
• the Fedora/CentOS Stream/AlmaLinux community that packages (and patches MariaDB)

The US Government got a project on this at https://repo1.dso.mil/dsop, but it consists of many repos, so that I cannot grasp easily their general apporach. Their NodeJS (slim) image relies on Alpine sourced from their own mirror.

The German Government decided to test NixOS Flakes to build containers from Debian packages that contain the bare minimum of software. If the container does not even contain a package management system, then it is called distroless. Read more about it from Google, Docker, RedHat, or Bitnami (minideb).

Find their work at: https://gitlab.opencode.de/open-code/oci or https://container.gov.de/

The following list of their requirements is copied over from the (nodejs image README.md):

Base Image Security

• Minimal base images are used - There is no base image at all, since this build is done using nix and debian packages directly.
• Base image provenance is verified - There is no base image at all, since this build is done using nix and debian packages directly.

• Immutable artifact references are used - There is no base image at all, since this build is done using nix and debian packages directly.

• Base Image can be automatically updates (or after a fixed period of time to avoid being a victim of a supply chain attack) - There is no base image at all, since this build is done using nix and debian packages directly.

Build Process Security

• Reproducible builds are implemented - Nix is being used to ensure that builds are reproducible, meaning the same source code and build instructions always produce identical container images.

• Build environment is isolated - Build runs in a Kubernetes GitLab-Runner. Nix is instructed to not do any sandboxing. However, the build environment is isolated from the host system and other builds to prevent contamination.

• Build provenance is attested - Build process generates cryptographically signed provenance (metadata about who, what, when, and how the artifact was built), ideally at SLSA Level 2 or higher. This creates an auditable trail proving the container came from your legitimate build system and hasn’t been substituted.

• Containers are signed - Images are signed using Cosign to ensure authenticity and integrity. They can be verified using the cosign.pub public key.

• Dev / Compile time dependencies are removed - Uses Nix

Component Management & Transparency

• All components are identified - Have a look at the config json files in the root directory. All components, including their versions, urls and checksums are listed there as input to the build process.

• Component PURLs can be matched to CVE reports We are using debian packages to match against known CVEs. Besides that, we are downloading Nodejs 24 from nodejs.org. To match that against CVEs, we are using the PURL constructed from their GitHub repository: pkg:github/nodejs/node@<version>. We can match this using DevGuard against CVEs (https://osv.dev/list?q=github.com%2Fnodejs%2Fnode).

• Component checksums are verified - All checksums are either in config.json or in flake.nix.

• Regular updates are provided for all components or latest Builds like new nodejs versions - Components receive timely updates and patches from upstream maintainers, and your build process incorporates these updates regularly. This ensures your container stays protected against newly discovered vulnerabilities in its components.

• Components can be automatically updated in a timely manner (or after a fixed period of time to avoid being a victim of a supply chain attack) - An automated pipeline exists to detect, test, and deploy component updates without manual intervention. Can provenance or signatures be verified for upstream components? This ensures security patches are applied quickly, reducing the window of exposure to known vulnerabilities.

Secrets & Sensitive Data

• No secrets in images - Credentials, API keys, certificates, and other sensitive data are never embedded in container images; they are injected at runtime via secrets management systems. This prevents secrets from being exposed in image layers, which can be extracted by anyone with access to the image.

Runtime Configuration

• Resource limits are documented - Since this is an runtime image only, resource limits heavily depend on the application being run.

• Container runs as non-root user - User 53111 (nonroot) is used as non-root user.

Compliance & Vulnerability Management

• SBOM is attested - A Software Bill of Materials (SBOM) is generated, accurate, and cryptographically attested to prove the container’s contents. This provides a tamper-proof inventory of components for compliance, license management, security scanning, and incident response.

• Vulnerability management is done in a timely manner - We are using DevGuard to monitor vulnerabilities in our components. New vulnerabilities are assessed and remediated promptly based on their severity and exploitability.

• VEX is attested - Vulnerability Exploitability eXchange (VEX) documents are provided and attested, indicating which vulnerabilities are exploitable in the specific container context and which are mitigated. This reduces alert fatigue by documenting which CVEs don’t actually affect your container due to configuration or usage patterns.

Fedora-based distroless Container images

As part of my pet pilot project EU OS, I rely on compiled code (i.e. RPM packages) from Fedora. Fedora (and their downstream stable versions Redhat RHEL, CentOS Stream, AlmaLinux) have technologies in place to cover most if not all Government use cases for open source:

• operating system for the corporate laptop of the end user (check out EU OS for some inspiration)
• operating system for cloud servers, including Kubernetes clusters
• container images for cloud workloads

So if we reuse the compiled code for all purposes, then the supply chain security becomes more managable (but due to such centralisation, vulnerabilities could have a higher impact).

Let us check, how distroless container images can be built from Fedora RPM packages. Fedora described this in a blog post from 2021. Meanwhile, things have changed a little bit and such Fedora distroless images can also be composed with podman and its multi stage builds. That’s my example for a small NodeJS container:

# kate: hl Containerfile;

ARG ROOTFS="/mnt/rootfs"
ARG HOME=/home/nonroot

ARG DNF="dnf"
ARG RELEASEVER="42"
FROM quay.io/fedora/fedora-minimal:42 as base
# alternatively:
# ARG RELEASEVER="9"
# FROM registry.access.redhat.com/ubi9/ubi-minimal as base
# or
# ARG RELEASEVER="10"
# FROM quay.io/almalinuxorg/10-minimal:10.0 as base

ARG ROOTFS
ARG DNF
ARG RELEASEVER
ARG DNF_OPTS="--installroot=${ROOTFS} --releasever=${RELEASEVER} --noplugins --config=/etc/dnf/dnf.conf --setopt=install_weak_deps=0 --setopt=cachedir=/var/cache/$DNF --setopt=keepcache=1 --setopt=reposdir=/etc/yum.repos.d --setopt=varsdir=/etc/dnf"

USER root

# pinning of software versions possible with https://dnf5.readthedocs.io/en/latest/dnf5_plugins/manifest.8.html
# (see also: https://github.com/rpm-software-management/dnf5/pull/2425)
RUN --mount=type=cache,target=/var/cache/$DNF \
  mkdir -p ${ROOTFS} && \
  $DNF ${DNF_OPTS} -y --nodocs install nodejs22

FROM scratch

ARG ROOTFS
ARG HOME

COPY --from=base ${ROOTFS} /

RUN \
  mkdir -p $HOME && \
  printf "nonroot:x:1001:\n" >> /etc/group && \
  printf "nonroot:x:1001:1001:Nonroot User:/home/nonroot:/sbin/nologin\n" >> /etc/passwd && \
  printf "nonroot:!:20386::::::\n" >> /etc/shadow && \
  chown -R 1001:1001 $HOME && \
  chmod -R g=u $HOME

USER 1001
WORKDIR $HOME
ENTRYPOINT ["/bin/bash"]

How does it compare? What is missing?

• The container image is not yet reproducible in the sense that it always uses the latest packages at the time of the build. However, with RPM manifests, the Fedora package manager can be instructed to install specific software versions, similar to npm and its package.json files. I could not enable it yet, because the feature is currently disabled, as the library is not yet widely available in the Fedora package repositories.
• SBOMs can be generated directly from the RPM database. Trivy can list vulnerabilities for a given SBOM, but only for distributions with support (fedora is not; CentOS Stream, RHEL, and AlmaLinux is). Trivy can also generate SBOMs for the container images directly. Renovate can be configured to update RPM manifest files.
• Podman supports signing containers.
• The container image also supports a non-root account.
• The container currently contains still bash, find, sed, grep as those tools are pulled in as a dependency of ca-certificates. The latter is required by nodejs. To remove them, an alternative custom ca-certificates package needs to be prepared that has no such dependencies. Interestingly the image is nevertheless smaller. See also: https://discussion.fedoraproject.org/t/169906/2

I think the main advantage would be to avoid Nix flakes. Maybe Nix flakes are cool, but the system is apparently still experimental/beta software (see here or here). Also, many developers have not worked yet with Nix flakes. So this is something new to learn. Using Nix flakes doesn’t make podman or Containerfiles redundant. So learning Nix flakes does not replace learning Podman or Containerfiles.

Obviously, this advantage would apply equally to building Podman distroless containers with OpenSUSE RPMs or Debian DEBs. All it takes is a build tool that can install dependencies in a separate folder. For dnf, this is done with the option --installroot. If an organisation has already solved supply chain security for a repository of compiled code, then I believe it is good practice to reuse this repository.

What is your view? Please comment, react on Mastodon or use any other channel.

References

• https://github.com/GoogleContainerTools/distroless
• https://fedoramagazine.org/building-smaller-container-images/
• https://discussion.fedoraproject.org/t/build-distroless-image-for-nodejs-with-minimal-dependencies/169906 (my own forum topic for research purposes)
• https://www.redhat.com/en/blog/why-distroless-containers-arent-security-solution-you-think-they-are
• https://docs.docker.com/dhi/core-concepts/distroless/
• https://github.com/bitnami/minideb
• https://wiki.almalinux.org/containers/docker-images.html

Every minute matters for companies managing vehicle fleets and Linux distributions like openSUSE’s serve as dependable backbones for these types of operations.

From security patrols in Indonesia to maintenance cars in the Philippines, fleets can be monitored in real time through cloud-based platforms powered by openSUSE Leap like Ntrack’s GPS Vehicle Tracking System.

Releases like Leap 16 can be used for GPS Vehicle Tracking list this and is one of several use cases for the distribution.

The vehicle tracking system processes raw data from third-party GPS IoT devices made by companies like Teltonika, Concox, Atrack and others. Each unit sends signals every minute over 3G, 4G and 5G networks, which creates a constant stream of location data. That data is queued using RabbitMQ and stored in PostgreSQL databases clustered on Leap servers.

It provides excellent support for database clustering and system monitoring, ensuring reliable failover and scalability of the data layer, said one developer who shared their use case with the project’s mailing list. The system is handling 50–100 data packets per second, and openSUSE keeps it reliable.

The Ntrack platform transforms these packets into actionable insights for fleet operators. Built on Leap, it offers features like live tracking, route scheduling, driver behavior analysis, geofencing and reporting.

The developer, Edwin, said that the use cases already cover fleets across the islands of Java and Bali related to private security, telecommunications maintenance vehicles in the Philippines, and company cars throughout Indonesia.

GPS tracking systems like Ntrack are another example of how the distribution powers mission-critical applications around the world; Leap 16’s extended lifecycle provides the reliability and upgradability businesses need to trust their technology infrastructure.

Members of the openSUSE Project are trying to showcase how people use openSUSE . If you have a use cases for Leap 16 that you want to share, comment on the project’s mailing list.

Recently, I’ve worked on making certain “less obvious” system settings more accessible for Plasma Mobile users. The modules I’ve worked on fall just outside the typical mobile phone use-case, but can be important to users of other types of devices. Specifically, users that plug in or connect a keyboard once in a while and need to change its layout or language, or devices that are connected using an ethernet cable, as often is the case with embedded industrial devices.

These two settings module offer a subset of their “desktop companions'” settings and cater to simpler use-cases while sporting a leaner and more focused user interface. Most of the business logic and the more complex UI components are also shared with the desktop versions.

Reviewers needed!

The merge requests for both are currently under review and I’d appreciate if people could help ironing out issues so we can go ahead and merge the code:

• Merge request for mobile wired network settings
• Merge request for mobile keyboard settings

Update: Both modules have been merged and will ship as part of Plasma 6.6.

As a follow up of the Hackweek 24 project, I've continued working on the gnome-tour fork for openSUSE with custom pages to replace the welcome application for openSUSE distributions.

GNOME Tour modifications

All the modifications are on top of upstream gnome-tour and stored in the openSUSE/gnome-tour repo

• Custom initial page

• A new donations page. In openSUSE we remove the popup from GNOME shell for donations, so it's fair to add it in this place.

• Last page with custom openSUSE links, this one is the used for opensuse-welcome app.

opensuse-welcome package

The original opensuse-welcome is a qt application, and this one is used for all desktop environments, but it's more or less unmaintained and looking for a replacement, we can use the gnome-tour fork as the default welcome app for all desktop without a custom app.

To do a minimal desktop agnostic opensuse-welcome application, I've modified the gnome-tour to also generate a second binary but just with the last page.

The new opensuse-welcome rpm package is built as a subpackage of gnome-tour. This new application is minimal and it doesn't have lots of requirements, but as it's a gtk4 application, it requires gtk and libadwaita, and also depends on gnome-tour-data to get the resoures of the app.

To improve this welcome app we need to review the translations, because I added three new pages to the gnome-tour and that specific pages are not translated, so I should regenerate the .po files for all languages and upload to openSUSE Weblate for translations.

Dear Tumbleweed users and hackers,

If 42 is the answer to the Ultimate Question of Life, the Universe, and Everything, then week 42 of the year 2025 must bring you all the software updates you have waited for your entire life, and your computer has entered the ‘working perfectly mode’ now. The number of snapshots is lower than in other weeks, as openQA ensured we reached perfection and has prevented us from releasing some broken snapshots (broken in the sense that the grub2/snapper integration was denied by SELinux).

We have thus released three snapshots (1013, 1014, and 1015), bringing you these updates:

• KDE Gear 25.08.2
• KDE Frameworks 6.19.0
• Qt 6.10.0
• Linux kernel 6.17.1 & 6.17.2
• GNOME 49.1 (gnome-shell and mutter are pending; they were released a bit later by upstream)
• gimp 3.0.6
• Ruby 3.4.7
• Switch to ffmpeg-8 by default
• LibreOffice 25.8.2.2
• GCC 15.2.1
• Qemu 10.1.1
• libxml 2.14.5
• opensuse-welcome was replaced by opensuse-welcome (sic!): the new implementation is forked off gnome-tour

The outlook for the next week promises to keep going strong. Using OBS’ staging areas, we are currently testing integration of:

• Linux kernel 6.17.3
• Mozilla Firefox 144.0
• KDE Plasma 6.5 (beta 2 being tested; waiting for the final release)
• util-linux 2.41.2
• transactional-update 5.5.0: enables soft-reboot if possible
• Switch from grub2 to grub2-bls
• openSSL 3.6.0: fix for nodejs22 pending

This is a roundup of articles from the openSUSE community listed on planet.opensuse.org.

The below featured highlights listed on the community’s blog feed aggregator are from October 11 to 17.

The week’s Planet highlights an install party at the University of Valencia, KDE Apps of the week, KDE turns 29 and more.

Here is a summary and links for each post:

Morning Day of the XI Annual Conferences of Wikimedia Spain

This blog recounts the author’s experience at the XI Annual Wikimedia Spain Conference in Valencia. Details include exploring the Etno Museum’s setting to attending engaging talks on GLAMWiki and media literacy.

Install party at the University of Valencia October 21

The KDE Blog announces an upcoming install party at the University of Valencia on Oct. 21 as the official support of Windows 10 ends. The association GNU/Linux València invites participants to try out Linux and free software at this hands-on community event.

Matrix Widgets in NeoChat – This Week in KDE Apps

The KDE Blog covers recent KDE app updates, which includes Matrix app NeoChat and social media app Tokodon. The blog also covers enhancements in Dolphin, Kate, Konsole and more.

KDE turns 29

Victorhck and Baltolkien both highlight the KDE’s 29th anniversary and congratulate to the entire community on its journey from the “Kool Desktop Environment” to a thriving global community of developers and users.

Home-made Berliner Currywurst

Perhaps in good taste, Sebastian Kügler shares his recipe for Berlin-style Currywurst, which adds some chili powder to the Linux flavors people can consume on the blog aggregator.

Leap Powers Consultants on the Move

openSUSE News highlights how independent consultants, like Agustín Benito Bethencourt, rely on openSUSE Leap. From meetings to security, Bethencourt highlights a use case that keeps him going while on the move.

DiraQ: Pocket Linux for Quantum Computing

Alessandro de Oliveira Faria introduces DiraQ, which is a a lightweight plug-and-play alternative, that is tailored for quantum computing. It fits a niche use case for research and enthusiasts.

KDE Frameworks 6.19.0

The KDE Blog reports on the latest KDE Frameworks 6.19 version and highlights its bug fixes, and enhanced performance.

Memory Bank: Labels in HTML

This blog post dives into proper use of the <label> element in HTML forms. It points out best practices and pitfalls developers should avoid with labels.

Talk: What is Free Software? in Castellón

The association GNU/Linux València highlights an upcoming public talk in Castellón on Oct. 24 titled “What is Free Software?|” to spread awareness of free software values.

KDE Gear 25.08 Second Update

The KDE Blog covers the second bugfix release of KDE Gear 25.08. The blog focuses on KDE Connect and neochat as well as other KDE applications.

A lot of stability work for Plasma 6.5 – This Week in Plasma

The KDE Blog highlights improvements in Plasma 6.5. It shows where Plasma 6.6.0 is moving with the Breeze icon theme “Send” icon. It also points out fixes with KWin and the fixing of issues that bled apps using XWayland on some screens.

Tumbleweed – Review of the week 2025/42

And last but not least, a new weekly review by Dominique Leuenberger and Victorhck in Spanish, detailing the news that has arrived at the openSUSE Tumbleweed repositories in the last week.

View more blogs or learn to publish your own on planet.opensuse.org.