Why Bitnami Was Hard to Replace

What HelmForge Does Differently

1. Official upstream images only

2. S3 backup is built into every stateful chart

3. MIT licensed, forever

16 Charts With Backup Built In

Real Examples

Vaultwarden with SQLite backup to MinIO

n8n with queue mode and backup

Honest Comparison

The CI Pipeline

Try It

Contribute 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. 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. 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. This is the other thing Bitnami never solved. You deploy the database, it works, and then backup is your problem. With HelmForge: That's it. The chart creates a CronJob with: Works with AWS S3, MinIO, Cloudflare R2, Backblaze B2, DigitalOcean Spaces — anything that speaks S3. 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. Same backup.enabled + backup.s3.* interface across all of them. 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. 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: 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. Every chart goes through: 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. 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: The goal is simple: a community-owned chart repository where no single entity can pull the rug. 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. Templates let you quickly answer FAQs or store snippets for re-use. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse