Unsere Open Source Helm Charts als Bitnami Alternative

Bitnami war für viele Jahre der Goldstandard für Kubernetes Deployments: zuverlässig, mit stabilen Helm Charts für beliebte Open-Source-Lösungen. Mit der Umstellung ab August 2025 (siehe unseren vorherigen Blogbeitrag) sind viele der bislang frei verfügbaren Images aber nur noch mit Enterprise-Abo nutzbar.

Wir glauben: Open Source-Infrastruktur darf nicht hinter Paywalls verschwinden.

Deshalb haben wir – als Cloud-Native-Enthusiasten und Open Source Befürworter – eine eigene, wirklich offene Alternative geschaffen. Dabei wollten wir nicht einfach “das Gleiche in Grün” bauen, sondern gezielt einige Schwächen der bisherigen Charts verbessern: Bei uns stehen Security-Best-Practices, nachvollziehbare Werte (values.yaml), ausführliche Dokumentation und ein Developer freundlicher Aufbau im Vordergrund.

Wir haben gemeinsam mit unserer Crew in den letzten Tagen intensiv an den ersten Helm Charts gearbeitet. Diese Charts findet ihr ab sofort auf Artifact Hub und in unserem GitHub Repository.

Aktuell stehen folgende Charts zur Verfügung

• MariaDB – High-Performance, Open-Source-Datenbankserver und Drop-in-MySQL-Ersatz

• PostgreSQL – Das weltweit fortschrittlichste Open-Source-Relational Database Management System

• MinIO – High Performance Object Storage mit Amazon S3-Kompatibilität

• MongoDB – Flexible, dokumentenorientierte NoSQL-Datenbank für skalierbare Datenverarbeitung

• Redis – In-Memory Key-Value Store für Datenbankspeicherung, Caching und Message Brokering

• Valkey – Hochperformanter Fork von Redis, ebenfalls In-Memory Datenstruktur-Server

• RabbitMQ – Message Broker, der das Advanced Message Queuing Protocol (AMQP) implementiert

• TimescaleDB – Erweiterung für PostgreSQL zur effizienten Analyse von Zeitreihen- und Eventdaten

• ClusterPirate – Client-Agent, um Kubernetes-Cluster mit der CloudPirates Managed Observability Platform zu verbinden

Natürlich können unsere aktuell neun verfügbaren Charts die über 100 Charts von Bitnami noch nicht ersetzen und sollen das auch gar nicht – vielmehr geht es uns darum, eine solide, sichere und gut dokumentierte Basis für die wichtigsten Open-Source-Anwendungen zu legen, auf der wir gemeinsam mit der Community weiter aufbauen können. Habt ihr Wünsche für weitere Software? Dann erstellt gerne einen Pull Request oder teilt uns eure Wünsche über ein GitHub Issue mit.

Angenommen, du möchtest eine MariaDB Production Ready in Kubernetes bereitstellen – mit persistentem Storage, sicheren Credentials und sinnvollen Standardwerten.

Die Installation mit unserem Chart ist bewusst schlank gehalten:

helm install my-mariadb oci://registry-1.docker.io/cloudpirates/mariadb

Für individuelle Anforderungen wird klassisch eine values.yaml verwendet. Ein typischer Setup für den Alltag sieht zum Beispiel so aus:

# Inline Credentials (leave blank to get auto generated credentials)
auth:
  rootPassword: "superSicheresPasswort"
  database: "exampledb"
  username: "customuser"
  password: "examplepassword"
# Or use existing Credentials
auth:
  existingSecret: my-existing-secret
persistence:
  size: 20Gi

Damit erhältst du direkt nach dem helm install ein vollständiges MariaDB Setup mit persistentem Speicher, festgelegten Zugangsdaten (im Kubernetes Secret abgelegt, kein Klartext im Manifest) sowie sinnvollen Security-Defaults:

• Das MariaDB-Container läuft standardmäßig als non-root und mit geringsten Berechtigungen.

• Resource-Limits und Healthchecks (liveness/readiness) sind vorkonfiguriert.

• Das Image basiert immer auf den offiziellen Upstream-Images von Docker Hub – keine Blackbox-Images oder undurchsichtigen Re-Builds.

Ein weiterer Vorteil: Die Charts (und alle genutzten Container Images) verwenden den SHA256-Digest als Tag, was für reproducible Deployments sorgt.

Cloud-native Security ist für uns kein Nebenprodukt, sondern ein Kernfeature: Sämtliche Charts werden mit Cosign kryptografisch signiert. Der Public Key ist im Chart-Repository einsehbar – so kann man verifizieren, dass man wirklich unveränderte Charts nutzt.

Welches Image auf welchem Commit, mit welchem Wert – alles nachvollziehbar, kein Rätselraten. Das Ziel: Audits vereinfachen, Fehlerquellen früh sichtbar machen und Abhängigkeiten klar halten.

Non-Root, sensibel konfigurierte Filesystem-Berechtigungen, kein unnötiger Privilege-Escalation und sinnvolle SecurityContext-Policies sind überall Standard.

Einer der zentralen Vorteile unserer Helm-Charts ist die durchgängige Standardisierung der Werte und Konfigurationsblöcke. Entwickler, SREs und Ops-Teams profitieren davon, weil sie sich nicht für jede Applikation aufs Neue durchwühlen müssen, welche Parameter wie gesetzt werden – stattdessen kann man Code, Automation und Best Practices konsistent wiederverwenden. Das beschleunigt Deployment und Betrieb, schafft Übersichtlichkeit in CI/CD-Pipelines und erleichtert Migrationen enorm.

Ein konkretes Beispiel: Die grundlegenden Bereiche wie auth, persistence, resources und Healthchecks lassen sich dank einheitlichem Layout für alle Charts praktisch identisch definieren.

Beispiel: Gleiche Konfigurationsstruktur bei MariaDB und MongoDB

MariaDB (values.yaml):

auth:
  rootPassword: "meinPasswort"
  database: "applikation"
  username: "user"
  password: "userPasswort"

persistence:
  enabled: true
  size: 20Gi
  storageClass: "fast-ssd"

resources:
  requests:
    cpu: 500m
    memory: 1Gi
  limits:
    cpu: 1000m
    memory: 2Gi

livenessProbe:
  enabled: true
readinessProbe:
  enabled: true

MongoDB (values.yaml):

auth:
  enabled: true
  rootUsername: "admin"
  rootPassword: "mongoPass"
  existingSecret: ""   # Optionales Kubernetes-Secret

persistence:
  enabled: true
  size: 20Gi
  storageClass: "fast-ssd"

resources:
  requests:
    cpu: 500m
    memory: 1Gi
  limits:
    cpu: 1000m
    memory: 2Gi

livenessProbe:
  enabled: true
readinessProbe:
  enabled: true

Wie man sieht, unterscheiden sich die Werte nur minimal; Details wie persistence.size oder resources.limits sind immer an gleicher Stelle konfigurierbar, ebenso Authentifizierung und die Probes.

Einheitliche Nutzung von Secrets und individuellen Volumes

Statt für jedes Chart einen anderen Mechanismus zu lernen, kannst du bestehende Kubernetes Secrets oder zusätzliche Configs überall gleich einbinden:

auth:
  existingSecret: my-db-credentials
  secretKeys:
    rootPasswordKey: "root"
    userPasswordKey: "user"

Das obige Pattern findest du z. B. auch bei PostgreSQL und Redis wieder. Und wer zusätzliche Volumes oder Umgebungsvariablen mounten will:

extraSecrets:
  - name: tls-certs
    mountPath: /etc/certs
extraConfigs:
  - name: custom-init
    mountPath: /docker-entrypoint-initdb.d
extraVolumes:
  - name: backup-store
    mountPath: /var/backup

Ingress, Service und Network Policies – immer gleich

Jedes Chart verwendet einheitliche Strukturen für die Anbindung ans Netzwerk:

service:
  type: ClusterIP
  port: 27017   # MongoDB
  # ... oder 3306 bei MariaDB

ingress:
  enabled: false
  className: ""
  hosts:
    - host: db.example.com
      paths:
        - path: /
          pathType: Prefix

networkPolicy:
  enabled: true
  allowExternal: false

Unabhängig vom jeweiligen Workload werden Service, Ingress und Netzwerkfreigaben immer nach gleichem Prinzip gesteuert.

Das vielleicht schönste Zeichen: Schon in den ersten Tagen, selbst vor offizieller Ankündigung, landeten die Charts bei Reddit im /r/kubernetes Subreddit und in einigen anderen Communities. Dort kamen nicht nur Installationsberichte, sondern auch Verbesserungswünsche. Alle Rückmeldungen fließen bei uns direkt in die Weiterentwicklung mit ein – wir sehen diese Charts ausdrücklich als Startpunkt für eine Community-Alternative zu Bitnami. Maintainer, Nutzer und Contributor sind ausdrücklich willkommen!

Wir wissen natürlich, dass viele Nutzer bestehende Bitnami-Charts im Einsatz haben, und dass ein Umstieg manchmal im Detail knifflig sein kann. Im nächsten Blogartikel werden wir Schritt für Schritt zeigen, wie man am besten von bestehenden Bitnami-Setups auf unsere (und ähnliche) Community-Charts wechselt: Welche Werte finden sich wo wieder? Was ist mit Persistent Volumes, Ingress, Secrets, usw.? Dazu gibt es praktische Tipps, Troubleshooting und Beispiele aus realen Migrationsprojekten.

Bis dahin: Testet gerne unsere Chart, gebt uns Feedback – und wenn ihr Lust habt, baut mit uns gemeinsam eine nachhaltige und wirklich offene Open Source Alternative zu Bitnami auf.