Bitnami Hit the Brakes. The Community Needs a Free, Secure Alternative to migrate — Meet NiceOS

Broadcom has locked down free Bitnami container images, breaking CI/CD pipelines and open Helm charts across the community. We’re answering with NiceOS — a purpose-built, container-first Linux that ships every image with a full SBOM and vulnerability report, runs non-root by default, and guarantees deterministic, auditable builds.

What is Bitnami?

For more than a decade, Bitnami has been one of the silent engines behind modern open-source infrastructure. It offered prebuilt, security-hardened container images, virtual machines, and Helm charts for hundreds of popular open-source applications — from PostgreSQL, Redis, and NGINX to WordPress, GitLab, and Kafka. For developers, Bitnami became the fastest way to deploy reliable versions of complex stacks without worrying about dependency hell or manual patching. Enterprises used it for quick proofs of concept; hobbyists used it to spin up homelabs in minutes.

That convenience was powered by a consistent release pipeline: every image was built from source, tested, and published to public registries — free for anyone to pull. Bitnami’s reputation rested on two things: trust and predictability. When you ran docker pull bitnami/postgresql:14, you knew it was current, secure, and aligned with upstream best practices.

In 2019, after being acquired by VMware (later part of Broadcom), Bitnami began to evolve toward a more commercial, enterprise-focused direction. Its catalog is now split between open and “Bitnami Secure Images”, with many of the once-freely available images restricted to paying customers or private registries. What was once the community’s go-to source of ready-to-use open-source stacks is now transitioning into a subscription-based model.

What happened

In late August 2025, Broadcom quietly began a multi-stage deprecation of the public Bitnami container catalog. On August 28, users started noticing that familiar image tags — like bitnami/postgresql:15 or bitnami/redis:7 — had either vanished from Docker Hub or been relocated to a new namespace labeled Bitnami Legacy.” According to Broadcom’s own community posts, this cleanup marked the beginning of a transition toward a more curated, commercial offering under the Bitnami Secure Images brand.

The immediate effect was abrupt. Dozens of Helm charts, CI/CD pipelines, and Kubernetes deployments that depended on specific versioned tags suddenly failed with ImagePullBackOff errors. For many, it felt like a rug-pull moment: production systems were intact, but automated updates, replicas, and new environment rollouts started breaking across clusters worldwide.

A key nuance here is that Bitnami’s code remains open-source — the Dockerfiles, Helm charts, and application definitions are still publicly available on GitHub. But the prebuilt images, the most valuable output of that open pipeline, are no longer freely published at scale. Developers must now either build those images themselves (which removes the main appeal of Bitnami’s convenience) or subscribe to Broadcom’s paid registries that host continuously updated, vulnerability-scanned images.

Meanwhile, the open catalogs that remain accessible have grown inconsistent. Some repositories only provide a latest tag “for development purposes,” while others have frozen legacy versions that will never be updated again. Community discussions on GitHub and Hacker News describe the uncertainty bluntly: no one knows which images will persist, which will move behind paywalls, or how long the remaining “legacy” ones will be maintained.

What had once been a predictable and trusted ecosystem of community-accessible containers effectively fractured overnight — leaving developers scrambling to patch pipelines, rebuild CI workflows, and hunt for trustworthy replacements.

Why this is a problem

For anyone who has built pipelines around Bitnami’s catalog, the shift wasn’t just inconvenient — it was operationally destructive.

Pipelines broke overnight. Continuous deployment systems that depended on fixed version tags started throwing ImagePullBackOff and manifest not found errors as tags disappeared or were relocated. Helm upgrades failed mid-deployment; GitOps systems couldn’t reconcile expected versions. Infrastructure teams began describing the event as a kind of container brownout — workloads were still running, but no one could roll out new replicas or apply updates without rebuilding everything from source.

Compliance turned chaotic. Many remaining images are now labeled “for development use only” and published as latest. That single change obliterates the ability to pin versions, a fundamental requirement for both software audits and supply-chain traceability. Enterprises that relied on Bitnami’s consistent versioning suddenly found themselves without clear provenance or update guarantees. Even the so-called “legacy” images are frozen — they’ll never receive future security patches or CVE remediations.

Costs surged unexpectedly. The path to stability now involves either self-building every image (a major maintenance burden) or paying for Broadcom’s Bitnami Secure Images subscriptions. For small teams and community projects that used Bitnami as a free, trusted base, this introduced unplanned operational costs. Larger organizations face a different kind of expense — the time and labor needed to re-establish compliance workflows, internal scanning, and release pipelines.

In short, the open ecosystem that once offered dependable, transparent building blocks has splintered into a paywalled service and a patchwork of abandoned tags. The net effect is that developers now spend more time re-building what used to “just work” — a perfect storm of broken automation, compliance headaches, and resource drain.

Real user pain points with Bitnami

Even before the August 2025 cleanup, developers had been voicing frustrations with Bitnami’s image design. The issues weren’t theoretical — they showed up in scanners, audit logs, and production outages.

“Non-root”… but still root-group. Many Bitnami containers run processes as user 1001 but keep group 0 (root). On paper that looks like a non-root setup; in practice, most vulnerability scanners and compliance tools still flag it as a high-risk configuration. Access control policies see the container as belonging to the root group, which can grant unintended privileges in shared volume or Kubernetes contexts.

Endless permission battles on volumes. Anyone who has tried to mount persistent storage for Bitnami’s MariaDB or PostgreSQL images knows the pattern: Permission denied errors, ownership mismatches, and brittle fixes involving chmod 777 or init-containers to reset permissions. Because of the rigid /opt/bitnami path layout and GID 0 setup, migrating these workloads between clusters or storage classes often required custom entrypoints or post-start hooks.

Odd filesystem layout and privilege rules. Bitnami’s convention of placing everything under /opt/bitnami simplifies packaging, but it also concentrates write privileges in root-owned directories. Official documentation even acknowledges that the entire stack is writable by root, with only narrow exceptions for data directories. For operators following least-privilege guidelines, that structure feels inverted—applications should own their writable paths, not the other way around.

Operational friction and emergency migrations. When Broadcom’s registry changes hit, those architectural quirks amplified the pain. Reddit and GitHub threads filled with stories of teams spending weekends re-tagging images, re-building local mirrors, and debugging permission regressions under deadline pressure. For many, the shift confirmed a growing sentiment: Bitnami images were convenient, but opaque — hard to inspect, hard to customize, and increasingly unpredictable.

Sidebar: “Symptoms & Risks” quick scan • ImagePullBackOff or missing tags after upgrades • Audit failures due to :latest or missing digests • Security scanner flags for UID 1001/GID 0 • Stateful volumes resetting or mounting read-only • Manual chmod/chown scripts lurking in production

Each of these small pains hints at the same underlying issue: developers need container images that are not only up-to-date and secure but also transparent, predictable, and policy-friendly. That’s exactly the gap the NiceOS project sets out to close.

Our proposition: a free, community-first alternative built on NiceOS

The answer to Bitnami’s disappearance isn’t another closed catalog — it’s a transparent, reproducible ecosystem built for the community itself. That’s what we’re creating with NiceOS.

NiceOS is a container-first Linux distribution engineered from the ground up for modern DevOps and cloud environments. Every image is built deterministically from audited source packages, and each one ships with a Software Bill of Materials (SBOM) and a vulnerability scan report embedded directly inside the container. You don’t have to trust a marketing page or scrape external registries — the evidence of security and provenance is in the image itself.

Our catalog already includes foundational stacks like Redis, PostgreSQL, NGINX, and OpenJDK 21/25, with many more on the way. These are designed as drop-in replacements for their Bitnami counterparts: same purpose, same ease of deployment, but with cleaner architecture and modern security defaults. All images are non-root by default, running as user 10001:10001, making them Kubernetes-ready and compliance-friendly out of the box.

The project lives fully in the open — source, tooling, manifests, and build logs — under the **niceos-labs/containers repository. Pre-built artifacts are published on Docker Hub under the [niceos](https://hub.docker.com/r/niceos/base-os)** organization, including the minimal base-os foundation and application layers built atop it.

In essence, NiceOS offers what Bitnami once did — trustworthy, pre-hardened open-source images — but with the transparency and community ownership that modern infrastructure deserves.

What makes NiceOS different

Most “secure” container images stop at a marketing claim. NiceOS backs every claim with evidence, embedded right where it belongs — inside the container itself.

Supply-chain transparency built in. Every NiceOS image carries its own Software Bill of Materials (SBOM) and full vulnerability scan report within the filesystem, located at /nicesoft/niceos/reports/<release>-<build>-<arch>/. That means auditors, DevSecOps teams, or compliance pipelines can inspect the image directly without relying on third-party dashboards or API calls. Provenance isn’t a promise — it’s a file you can open.

Deterministic rootfs with a minimal attack surface. Each image is built from scratch through a reproducible pipeline that guarantees byte-for-byte identical results. There’s no package manager left inside at runtime, no mutable layers, and all SUID/SGID bits are stripped by default. This makes NiceOS containers smaller, safer, and easier to verify through digest comparison.

Secure defaults by design. Instead of pretending to be “non-root,” NiceOS runs every container under a dedicated UID/GID 10001:10001 — isolated from privileged groups and ready for Kubernetes deployment with clear securityContext examples. This approach avoids the notorious “GID 0 trap” that has plagued many Bitnami and legacy images.

Versioned tags and digest discipline. NiceOS uses semantic versioning (semver) for all image tags and publishes immutable SHA-digest references, making compliance, rollback, and reproducibility straightforward. You can pin a precise version today and know it will still work a year from now.

Open build tooling and visible provenance. Everything that builds an image — scripts, manifests, metadata — lives in the open on GitHub. Each container includes a clear provenance file at /.niceos/manifest.json, detailing the sources, build environment, and exact commit references used to produce it.

A roadmap that follows community needs. The first wave of NiceOS applications covers the essentials: Redis, PostgreSQL, and NGINX, with MariaDB, RabbitMQ, and Kafka next in line. Multi-architecture support (x86–64 and ARM64) and full integration with Artifact Hub are already on the roadmap — all driven by community feedback and transparent development cycles.

Together, these design choices make NiceOS something Bitnami never fully achieved: a container ecosystem where security, transparency, and reproducibility are guaranteed by construction, not added as an afterthought.

Architecture in brief

For those curious about what lies under the hood, NiceOS isn’t a random collection of container images — it’s a structured ecosystem designed around deterministic layering and transparent provenance.

The foundation: niceos/base-os. At the core sits niceos/base-os, a minimal, container-first Linux base purpose-built for reproducible images. It’s not a stripped-down Debian or Alpine — it’s a clean-room foundation assembled specifically for container workloads. Every application image in the NiceOS catalog, from Redis to OpenJDK, is layered on top of this reproducible base, ensuring consistency across all stacks and architectures.

Security-first by default. Each image inherits the same hardened posture: a non-root runtime, a minimal package footprint, and embedded SBOM and vulnerability reports that travel with the image itself. During builds, NiceOS optionally enforces strict CVE gating — policies that can fail the build if known vulnerabilities exceed configured severity thresholds. This makes “secure by design” an automated reality rather than a manual checklist.

Transparent provenance. Every container carries a /​.niceos/manifest.json file — a structured, machine-readable record of its origin. It lists the exact Git commits, build timestamps, compiler versions, and upstream package sources used to produce the image. For auditors and engineers alike, this file is a single, authoritative truth of how that binary came to exist.

Together, these layers form a container architecture where security, traceability, and reproducibility are not add-ons — they’re part of the operating system’s DNA.

Migration: drop-in patterns and compatibility notes

NiceOS isn’t just a new idea — it’s meant to be a drop-in replacement for the images that Bitnami left behind. We’ve designed the migration path so that teams can recover stability without rewriting their Helm charts or pipelines from scratch.

1. Helm swap — plug and rebuild. In most cases, replacing Bitnami images is as simple as switching the image reference. Change

image:
  repository: bitnami/postgresql
  tag: 15.5.0

to

image:
  repository: niceos/postgresql
  tag: 15.5.0
  digest: sha256:<immutable-digest>

and add a runtime context:

securityContext:
  runAsUser: 10001
  runAsGroup: 10001
  fsGroup: 10001

NiceOS containers already include pre-created writable directories and correct ownership, so persistent volumes usually need no extra chmod or init scripts. For examples, see the Postgres, Redis, and NGINX charts in the niceos-labs/containers repository.

2. ENV variables and playbooks. Bitnami popularized its own set of environment variables like POSTGRESQL_USERNAME, ALLOW_EMPTY_PASSWORD, or REDIS_PASSWORD. NiceOS keeps the most common ones for convenience but also documents direct upstream equivalents (e.g., POSTGRES_USER, POSTGRES_PASSWORD) for a smoother, standards-aligned configuration. Migration guides map these variables side-by-side and include recommended volume paths (/var/lib/postgresql/data, /data/redis) plus readiness probes tested with our non-root UID/GID 10001 setup.

3. Policy-as-code enforcement. To help teams formalize security hygiene, we provide ready-made Gatekeeper and Kyverno policies that verify every deployed container:

• Images must be pinned by digest, not floating latest tags.
• Containers must run as non-root and not belong to group 0.
• Optional policy rules can require the presence of the embedded SBOM file or a /.niceos/manifest.json entry for provenance checks.

With these policies in place, adopting NiceOS isn’t just a migration — it becomes a permanent improvement to how your infrastructure enforces trust.

The overall goal is zero-friction replacement: same deployment patterns, better security posture, and transparent provenance by default.

Case study sketches

Sometimes the best way to understand the impact of change is through stories. Here are two real-world situations that many teams have already lived through — and how they would have played out differently under NiceOS.

Case 1 — “Killed by :latest.” A DevOps team at a fintech startup relied on Bitnami’s PostgreSQL Helm chart for its staging and production clusters. Like many, they used the latest tag for convenience. When Broadcom’s registry changes rolled out, their CI/CD pipeline suddenly failed with manifest not found. The outage delayed several releases, but the bigger problem came later: a compliance audit failed because the company couldn’t produce evidence of which image had actually been deployed at any given time.

Had they been using NiceOS, that never would’ve happened. Every image ships with an immutable SHA digest, embedded SBOM, and manifest.json linking to its source commit. Digest pinning makes it impossible for latest to surprise you, and the internal SBOM gives auditors the traceability they need instantly — even offline. The result: stable builds, verifiable provenance, and no midnight rebuilds just to prove what’s running.

Case 2 — “GID 0 headaches.” A SaaS provider running Redis clusters with Bitnami images kept hitting security warnings in their vulnerability scans: containers running as UID 1001 but with group 0 (root). The scanner flagged them as effectively privileged because group 0 could still modify files in shared mounts. Their remediation team spent weeks writing custom security contexts and init containers to reset permissions across environments.

In the NiceOS model, this class of problem doesn’t exist. All containers run under UID/GID 10001:10001, fully detached from root privileges. Scanners see them as clean, compliant, and isolated by default. No special mounts, no chmod 777 rituals, and no long-term tech debt. It’s a small detail — but one that can eliminate dozens of false positives and recurring compliance noise.

These are modest examples, but they reveal a bigger truth: small, intentional design decisions — deterministic builds, non-root groups, embedded SBOMs — add up to enormous reliability gains across the entire software supply chain.

Why a purpose-built OS instead of general-purpose bases

It might be tempting to ask: why build a whole new operating system when perfectly good bases like Debian, Alpine, or CentOS already exist? The short answer is intent.

Those distributions were designed for general-purpose computing — servers, desktops, and embedded systems. Containers came later, and reproducibility, SBOMs, and provenance weren’t part of their design DNA. When you use them as container bases, you inherit layers of complexity: package managers that mutate the filesystem, non-deterministic timestamps, background services you’ll never run, and security metadata scattered across external tools instead of living inside the image.

NiceOS flips that model completely. It’s a purpose-built container OS, created solely to produce verifiable, minimal, reproducible containers with evidence of their own integrity embedded from the start. Every layer — from the build scripts to the package manifests — is optimized for deterministic builds, non-root operation, and embedded security artifacts like SBOMs and vulnerability reports.

This makes NiceOS not just lighter, but trustworthy by construction. It’s not trying to be a general-purpose Linux flavor. It’s a specialized foundation for the next era of container infrastructure — one where every image can prove what it contains, how it was built, and who built it.

Community model and governance

At its core, NiceOS is a community project, not a corporate product. Everything — from the build scripts and manifests to the test pipelines and vulnerability reports — lives in public view. There are no private registries, no hidden layers, and no gated features behind enterprise paywalls.

The source of truth for the project is the niceos-labs/containers repository, where every image’s Dockerfile, manifest, and build metadata are tracked openly. Contributors can file issues, submit pull requests, or propose new container definitions directly through GitHub. We treat transparency as both a security feature and a development philosophy: if you can’t inspect it, you shouldn’t have to trust it.

The same principle guides the roadmap. Community feedback directly shapes priorities — whether that’s new images (like MariaDB, RabbitMQ, or Kafka), multi-architecture support, or integrations with Kubernetes Helm charts and Artifact Hub. Governance is meritocratic and discussion-driven: decisions are documented in issues and milestones, not made behind closed doors.

Most importantly, NiceOS will remain free and open. The project exists because the open-source community deserves a sustainable alternative to the Bitnami model — one where shared infrastructure stays accessible, secure, and verifiable for everyone.

Roadmap & what’s shipping today

The NiceOS project is already alive and evolving fast. The foundation is in place, and the next milestones are laser-focused on scale, polish, and community adoption.

Available now. The core NiceOS Base OS image and OpenJDK 21/25 runtimes are live and published on Docker Hub. These images follow the project’s full reproducibility guarantees — deterministic builds, non-root operation, and embedded SBOMs and CVE scan reports. The first wave of application containers, including Redis, PostgreSQL, and NGINX, is entering active testing with semantic version tags and immutable SHA digests for each release.

What’s next. The immediate roadmap focuses on integration and usability. We’re working toward:

• Full Artifact Hub publication so that NiceOS images and Helm charts are discoverable alongside major community projects.
• Multi-architecture support for both amd64 and arm64, ensuring parity across cloud and edge environments.
• Comprehensive Kubernetes deployment examples for each app, showing real-world usage with persistent volumes, non-root contexts, and secure defaults.
• A practical “Bitnami-to-NiceOS” migration guide, including variable mapping, Helm snippets, and digest pinning templates for smooth transitions.

The broader vision is to make NiceOS not only a replacement for Bitnami but an improvement — a standard for verifiable, minimal, and transparent container stacks that anyone can build upon.

Honest limitations

No open-source project starts perfect, and NiceOS is no exception. Transparency means being clear about what’s working — and what still needs work.

We’re not a one-click drop-in for every Bitnami edge case, at least not yet. While most of our images preserve common environment variables and directory structures, some Bitnami-specific conventions differ. We’re documenting these differences in detailed compatibility notes and will gladly accept pull requests that improve migration coverage.

If your stack depends on deeply integrated Bitnami tooling — custom automation scripts, wrapper entrypoints, or the old /opt/bitnami layout — plan for a short migration sprint. We’ll provide guides, ready-made Helm patches, and example manifests to make that process as smooth as possible.

NiceOS is meant to grow with the community. Every issue report, PR, or suggestion helps close those gaps faster — ensuring that what started as a replacement soon becomes the stronger standard for container transparency and security.

Get involved

The container ecosystem runs on trust — and rebuilding that trust starts with participation.

If you’ve been affected by the Bitnami shutdown, or if you simply want a more transparent, reproducible foundation for your workloads, start with the NiceOS images. Pull them, test them, and tell us what breaks. Every bug report, feature request, or benchmark helps refine the next release.

We’re especially interested in feedback on the first-wave applications — Redis, PostgreSQL, NGINX, and soon Redis Cluster. If you have a particular stack you’d like prioritized, open an issue or comment directly in the NiceOS Containers repository.

And please — share your migration stories, even the painful ones. Those “we lost a weekend to missing tags” or “our scanner wouldn’t stop flagging group 0” tales are exactly what we need to build the guides, compatibility notes, and Helm templates that will save someone else next month.

NiceOS exists because open infrastructure should stay open — verifiable, auditable, and free to build upon. Let’s make that real, together.