Maicon Berlofa

Posted on Mar 31

After the Broadcom Rug Pull: Why I Built Open-Source Helm Charts That Use Upstream Images and Ship With S3 Backup

#kubernetes #helm #devops #opensource

If you're running Bitnami Helm charts, you already know the situation. Broadcom acquired VMware, pulled Bitnami images behind a paid subscription, and the community that built itself around those charts got left holding stale images and broken CI pipelines.

Some teams pinned to bitnamilegacy. Some forked charts and are now maintaining them forever. Some migrated to operators like CloudNativePG or Strimzi. Many are still stuck, wondering when something will break.

I'd been building Helm charts before the Broadcom situation, but what happened crystallized the problem: the ecosystem was too dependent on one vendor's charts, one vendor's images, and one vendor's goodwill.

So I built HelmForge — 23 MIT-licensed Helm charts that use official upstream container images and ship with built-in S3-compatible backup. No proprietary images. No custom entrypoints. No licensing surprises.

Why Bitnami Was Hard to Replace

The thread I keep seeing on Reddit is some version of: "Where do I find Helm charts for MongoDB/Redis/PostgreSQL now?"

And the honest answer is: it's hard. Here's why:

Bitnami charts were tightly coupled to Bitnami images. They added custom environment variables, init scripts, and directory layouts. You can't just swap in the official postgres:16 image and have the chart work.
Forking 300+ charts is insane to maintain. The open-bitnami fork exists, but maintaining hundreds of charts with security patches and K8s compatibility is a full-time job for a team, not a community side project.
Operators solve the database problem but not the application problem. CloudNativePG is excellent for PostgreSQL. Strimzi is great for Kafka. But what about Vaultwarden? n8n? WordPress? Keycloak? Strapi? There's no operator for every stateful app.

What HelmForge Does Differently

1. Official upstream images only

Every HelmForge chart runs the official container image published by the upstream project. PostgreSQL uses postgres:16. Redis uses redis:7. MongoDB uses mongo:8. Vaultwarden uses vaultwarden/server.

No vendor-built images. No custom entrypoints that break when the vendor changes their license. If the upstream project publishes an image, that's what the chart uses.

2. S3 backup is built into every stateful chart

This is the other thing Bitnami never solved. You deploy the database, it works, and then backup is your problem. With HelmForge:

backup:
  enabled: true
  schedule: "0 2 * * *"
  s3:
    endpoint: https://minio.example.com
    bucket: my-backups
    accessKey: minioadmin
    secretKey: minioadmin

That's it. The chart creates a CronJob with:

An initContainer that dumps the data (pg_dump, mysqldump, mongodump, sqlite3 .backup, or tar — the chart picks the right tool)
A main container that uploads the compressed archive to any S3-compatible endpoint
A ConfigMap with the backup scripts (fully visible, no black boxes)

Works with AWS S3, MinIO, Cloudflare R2, Backblaze B2, DigitalOcean Spaces — anything that speaks S3.

3. MIT licensed, forever

No CLA. No proprietary dependencies. No "community edition" that might get pulled. The charts live on GitHub, are published to ghcr.io and a Helm repo on GitHub Pages. The only dependency is GitHub being up.

16 Charts With Backup Built In

Chart	What gets backed up
PostgreSQL	pg_dump of all databases
MySQL	mysqldump of all databases
MongoDB	mongodump archive
Vaultwarden	SQLite .backup, pg_dump, or mysqldump
Keycloak	External DB dump (PostgreSQL or MySQL)
n8n	SQLite or external DB dump
WordPress	MySQL dump + wp-content tar
Strapi	SQLite or external DB dump + uploads tar
Answer	SQLite or external DB dump
Guacamole	PostgreSQL or MySQL dump
Komga	SQLite backup + library metadata
Minecraft	World data tar
Pi-hole	Configuration and lists tar
Uptime Kuma	SQLite backup
AdGuard Home	Configuration and data tar
Authelia	Configuration backup

Same backup.enabled + backup.s3.* interface across all of them.

Real Examples

Vaultwarden with SQLite backup to MinIO

data:
  persistence:
    enabled: true

backup:
  enabled: true
  schedule: "0 30 2 * * *"
  s3:
    endpoint: https://minio.example.com
    bucket: vaultwarden-backups
    prefix: sqlite
    existingSecret: vaultwarden-backup-s3

The CronJob runs sqlite3 .backup, compresses it, and uploads to S3. Switch to PostgreSQL or MySQL and the chart automatically uses pg_dump or mysqldump — same values key, different initContainer.

n8n with queue mode and backup

architecture: queue

database:
  type: postgresql
  external:
    host: my-pg.example.com

redis:
  enabled: true

backup:
  enabled: true
  schedule: "0 4 * * *"
  s3:
    endpoint: https://minio.example.com
    bucket: n8n-backups

Honest Comparison

HelmForge is not a Bitnami replacement. The catalog is 23 charts, not 300. It's maintained by one person, not a corporate team. Here's the tradeoff:

	Bitnami (pre-Broadcom)	Bitnami (post-Broadcom)	HelmForge
License	Open source	$5-6k/month	MIT (forever)
Catalog	100+ charts	100+ charts	23 charts
Container images	Bitnami-built (custom)	Bitnami-built (paid)	Official upstream
Backup	Not included	Not included	Built-in S3 CronJob
Image lock-in	High (custom env vars, paths)	High + paid	None (standard upstream)
CI validation	Yes	Yes	lint, template, unittest, kubeconform

If you need a chart for a niche application, HelmForge might not cover it yet. But for the 23 apps it does cover — databases, identity, CMS, automation, monitoring, game servers, DNS — the charts are tested, the images are upstream, and backup works out of the box.

The CI Pipeline

Every chart goes through:

helm lint --strict
helm template with default and all CI scenario values
helm unittest for template logic
kubeconform for Kubernetes schema validation
Local k3d cluster validation before merge

Each chart has a maturity label (stable, beta, alpha) so you know exactly what you're getting. Releases are automated with semantic versioning and categorized GitHub Release notes.

Try It

# Add the repo
helm repo add helmforge https://repo.helmforge.dev
helm repo update

# Or use OCI directly
helm install vaultwarden oci://ghcr.io/helmforgedev/helm/vaultwarden

# Show available values
helm show values helmforge/vaultwarden

Repository: github.com/helmforgedev/charts
Documentation: helmforge.dev
Artifact Hub: artifacthub.io/packages/search?repo=helmforge

Contribute

HelmForge is 23 charts maintained by one person. That's the honest starting point. But the Bitnami situation proved that one company owning the chart ecosystem is a single point of failure — and the fix isn't another single maintainer, it's shared ownership.

The repo is MIT licensed with no CLA. Adding a new chart follows a clear pattern: values.yaml, templates, unit tests, CI scenarios, and backup if the app is stateful. If you've been maintaining internal charts or patching Bitnami forks for your own apps, consider contributing them upstream instead of maintaining them alone.

Ways to get involved:

Add a chart for an app you already run on Kubernetes
Port a Bitnami chart to use official upstream images
Improve existing charts — new topologies, better defaults, additional backup strategies
Open an issue to request a chart or report a bug
Star the repo if you want to follow the progress

The goal is simple: a community-owned chart repository where no single entity can pull the rug.

Repository: github.com/helmforgedev/charts
Documentation: helmforge.dev
Artifact Hub: artifacthub.io/packages/search?repo=helmforge

If your infrastructure depends on a single vendor's goodwill, you're one acquisition away from a rug pull. HelmForge won't replace Bitnami's 300-chart catalog, but it covers the workloads most teams actually run — with upstream images, built-in backup, and a license that won't change on you. The more people contribute, the less any of us depends on one vendor.

DEV Community