# MinIO 💾

**URL:** <https://discourse.eom.dev/t/minio/344>\
**Category:** Meta\
**Created:** [September 18, 2025, 7:40pm UTC](https://discourse.eom.dev/t/minio/344 "2025-09-18T19:40:23Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![eric](https://discourse.eom.dev/user_avatar/discourse.eom.dev/eric/32/610_2.png) [@eric](https://discourse.eom.dev/u/eric)\
**Post date:** [September 18, 2025, 7:40pm UTC](https://discourse.eom.dev/t/minio/344/1 "2025-09-18T19:40:24Z")

</div>

> 🔖 **ITT** [MinIO on eom.dev](https://minio.eom.dev) is discussed. The service itself is briefly introduced, its role on the platform is described, and instructions for accessing its contents are provided. Readers are invited to ask questions and offer suggestions towards improving its usage in the subsequent thread.

# About

**MinIO** offers efficient uploads and downloads for media on eom.dev and it is used in the background for many of the other services on the platform.

> **[Data and Memory Foundation for Enterprise AI | MinIO](https://www.min.io/)**
>
> MinIO unifies persistent AI memory, open tables, and S3-compatible object storage on a secure, governed foundation for AI training, inference, and agents.

The following repository contains the Ansible role used to deploy MinIO to eom.dev and can be used to report issues with the service on this platform:

> **[ansible-role-minio](https://gitea.eom.dev/DevOps/ansible-role-minio)**
>
> Ansible role to deploy MinIO to Kubernetes

## Usage

Generally speaking, content uploaded to MinIO will be embedded directly into another site such as Gitea, [Discourse](https://discourse.eom.dev), or [Mastodon](https://mastodon.eom.dev/). The requisite link can be used to access content directly from MinIO, often with better performance:

> [@Video Playback over Discourse](https://discourse.eom.dev/t/video-playback-over-discourse/268):
>
> Upon investigating your MinIO set-up I had an obvious idea: “Can I just open the address of the video in my browser address bar?” Yes, I could! “[https://minio.eom.dev/public/Videos/2025-08-26\_20-32-29.mp4](https://minio.eom.dev/public/Videos/2025-08-26_20-32-29.mp4)” Worked beautifully with zero buffering. I’ll just do this from now on. joy

While buckets can be viewed using a standard web browser, the service returns plain XML unless the URL contains the full object key. Dedicated clients can be used for a more user-friendly experience: [mc](https://docs.min.io/community/minio-object-store/reference/minio-mc.html) to access objects from the command line and [s3fs](https://s3fs.readthedocs.io/en/latest/) to mount a bucket to your local filesystem.

## Buckets

### Default

Unused.

### Discourse

This bucket exists to store media uploaded to [Discourse](https://discourse.eom.dev/t/discourse/71). It is not currently in use.

### Eric

@eric’s private bucket.

### Mastodon

The mastodon bucket is managed by the Mastodon service. Content in this bucket is publicly accessible, but must be accessed directly.

### Nextcloud

Nextcloud provides an interface for managing any bucket to which it is given access. By default, it will store data locally. A dedicated bucket for Nextcloud exists to be shared among users.

### Owncast

A bucket exists for Owncast live streams, but is not currently in use.

### Public

A manually-maintained bucket for content that has been published for public consumption.

#### Metadata

Files in this bucket have extensive metadata used to describe the media itself. Metadata exists independently from MinIO as part of the original media file.

#### Tags

- `published_url`: the URL at which this media was originally published (Gitea, Discourse, etc.). (Not currently implemented)

#### Keys

Prefixes are used to organize content in the public bucket:

- 🎤 **Audio**
- 📄 **Documents**
- 📁 **Downloads**
- 🎵 **Music**
- 📷 **Photos**
- 📹 **Videos**

---

<div class="post-metadata">

**Author:** ![eric](https://discourse.eom.dev/user_avatar/discourse.eom.dev/eric/32/610_2.png) [@eric](https://discourse.eom.dev/u/eric)\
**Post date:** [September 18, 2025, 7:54pm UTC](https://discourse.eom.dev/t/minio/344/2 "2025-09-18T19:54:15Z")

</div>

> [@eric](#):
>
> ### Discourse
> 
> This bucket exists to store media uploaded to Discourse. It is not currently in use.

Though MinIO could offer performance improvements here on Discourse, the forum is currently configured to store all files uploaded by users locally. Doing so keeps these files in their original format, and prevents this platform from being dependent on that one. Migrating these files to MinIO in the future is straightforward and scripted, but migrating back to local storage has been reported to be more challenging.

> **[Set up file and image uploads to S3](https://meta.discourse.org/t/set-up-file-and-image-uploads-to-s3/7229)**
>
> So, you want to use S3 to handle image uploads? Here’s the definitive guide, but also see Configure an S3 compatible object storage provider for uploads to see how to configure your app.yml. S3 registration Head over to...

> **[Migrate\_from\_s3 problems](https://meta.discourse.org/t/migrate-from-s3-problems/119064)**
>
> When migrating from S3 to local storage, we see a number of issues. The main issue is that the migrate\_from\_s3 rake task is not taking the Uploads table as a starting point, but the posts. This causes it to skip a lot of uploads which are being...

> **[Set up file and image uploads to S3](https://meta.discourse.org/t/set-up-file-and-image-uploads-to-s3/7229/275?u=ericomeehan)**
>
> The linked thread mentions a PR to remove a migrate\_from\_s3 task, and I have seen no reason to believe it has been added back later, but I wanted to check if this was still the case. I am considering migrating to MinIO and am a bit concerned with...

I have the same apprehensions about migrating [Matrix](https://discourse.eom.dev/t/matrix/72) to MinIO as well; however, lack of support on the non-pro version of Element makes this a moot point for that service:

> <https://github.com/element-hq/ess-helm/issues/558>
>
> I haven't seen anything in the documentation about adding s3/s3 like storage. ca…n that be made a feature in the community edition? i think i saw it as an option on the pro edition.

---

<div class="post-metadata">

**Author:** ![eric](https://discourse.eom.dev/user_avatar/discourse.eom.dev/eric/32/610_2.png) [@eric](https://discourse.eom.dev/u/eric)\
**Post date:** [November 1, 2025, 3:45pm UTC](https://discourse.eom.dev/t/minio/344/3 "2025-11-01T15:45:26Z")

</div>

# Is MinIO Still Open Source?

Recent developments in the MinIO project show that the organization is prioritizing proprietary features and paid users. The first change I heard about was that the free version of the web console was losing features. Since I do not have the web console deployed, this change did not impact me; however, in a recent [Reddit thread](https://www.reddit.com/r/selfhosted/comments/1olnaj5/selfhosted_and_open_source_content_creator_and/nmj0f8w/), I was informed that they have also pulled support for their Docker containers.

> **[Is It Still Open Source? MinIO Steering Users Toward Paid Subscriptions](https://linuxiac.com/minio-steering-users-toward-paid-subscriptions/)**
>
> MinIO removes key web console features, nudging users toward its paid offering. Is this still open-source, or is it just an AGPLv3 on paper?

[https://ckh.enc.edu/news/minio-retires-free-docker-images-impact-on-the-open-source-community/](https://ckh.enc.edu/news/minio-retires-free-docker-images-impact-on-the-open-source-community/)

Further compounding the problem, MinIO on eom.dev was deployed using a Helm chart that is being deprecated by Bitnami.

> <https://github.com/bitnami/containers/issues/83267>
>
> \> \[!IMPORTANT\] 
> \> After evaluating the impact and community feedback, the Bitnam…i team has postponed the deletion of the Bitnami public catalog (\`docker.io/bitnami\`) until \*\*September 29th\*\* to give users more time to adapt to the upcoming changes.
> \>
> \> To raise awareness before the registry deletion, we will run a series of \*\*brownouts\*\* over the coming weeks. During each brownout, a set of 10 container images from docker.io/bitnami will be temporarily unavailable for 24 hours. The scheduled brownouts are:
> \>\* August 28, 08:00 UTC → August 29, 08:00 UTC
> \>\* September 2, 08:00 UTC → September 3, 08:00 UTC
> \>\* September 17, 08:00 UTC → September 19, 08:00 UTC
> \>
> \>The list of affected applications will be published on the day of each brownout via our usual channels.
> \>
> \>As previously announced, since August 28th, we have not published new Bitnami container images or Helm charts to Docker Hub in OCI format. The source code for containers and Helm charts remains available on GitHub under the Apache 2.0 license.
> 
> \---------------
> 
> \### 📢 Overview
> 
> As of August 28th, 2025, the Bitnami public catalog will undergo the following changes:
> 
> \- \*\*Community catalog\*\*
> - Disable images generation for Debian-based images and gradually move existing ones to a \[\_Bitnami Legacy\_ repository\](https://hub.docker.com/u/bitnamilegacy).
> - A focused set of more hardened, more secure images. These free images are intended for development and are only available on the “latest” tag. You can find them at https://hub.docker.com/u/bitnamisecure.
> - Helm charts and container images' open-source code will continue to be maintained up-to-date and accessible on GitHub under the Apache 2 license.
> 
> \- \*\*Bitnami Secure Images\*\*
> - Production-ready, enterprise-grade containers and Helm charts will move under the Bitnami Secure Images offering.
> - Benefits include:
> - Hardened, low-attack-surface operating system
> - Continuous rebuilds with the latest security patches (SLSA Level 3)
> - Industry-standard CVE transparency (VEX, KEV)
> - SBOMs and compliance artifacts
> - Enterprise support and LTS branches
> - Access to the entire catalog of applications (over 280)
> - Minimal distroless runtime images 
> 
> \- \*\*Legacy repository migration\*\*
> - All existing container images, including older or versioned tags (e.g., \_2.50.0\_, \_10.6\_), will be moved from the public catalog (\`docker.io/bitnami\`) to the \[\_Bitnami Legacy\_ repository\](https://hub.docker.com/u/bitnamilegacy) (\`docker.io/bitnamilegacy\`). This legacy catalog will receive no further updates or support and should only be used for temporary migration purposes.
> - Exception: Images based on distros deprecated from the Bitnami catalog more than 3 years ago (tags: \`debian-8\`, \`debian-9\`, \`debian-10\`, \`centos-7\`, \`ol-7\`) will not be copied.   
> - Suppose your deployed Helm chart is failing to pull images from \`docker.io/bitnami\`. In that case, you can resolve this by subscribing to Bitnami Secure Images, ensuring that the Helm charts receive continued support and security updates. As a temporary workaround, you can upgrade to the same version and update the repository parameter for each container image to the \[\_Bitnami Legacy\_ repository\](https://hub.docker.com/u/bitnamilegacy).
> 
> \### 🗓️ Timeline
> 
> \- \*\*Now – August 28th, 2025\*\*
> - You will see deprecation notices in READMEs and documentation.
> - Plan your migration: Update CI/CD pipelines, Helm repos, and image references.
> - Start trying out the new hardened images available to the community today at https://hub.docker.com/u/bitnamisecure.
> 
> \- \*\*August 28th, 2025\*\*
> - The \[public catalog\](https://hub.docker.com/u/bitnami) switches to the limited community-tier subset of container images (the same images that are initially available at https://hub.docker.com/u/bitnamisecure).
> - Legacy assets are archived in the \[\_Bitnami Legacy\_ repository\](https://hub.docker.com/u/bitnamilegacy).
> 
> \- \*\*Post-August 28th, 2025\*\*
> - For development purposes, community-tier users are restricted to pulling only the most recent ‘latest’ tags of the limited community-tier subset of container images.
> - Production users should subscribe to Bitnami Secure Images for full version support at https://go-vmware.broadcom.com/contact-us.
> 
> \<div align="center"\>
> \<img width="639" height="830" alt="Image" src="https://github.com/user-attachments/assets/7955df63-96fc-4d77-8003-7ca04bd9ea4b" /\>
> \</div\>
> 
> \---------------
> 
> \### FAQ
> 
> \*\*Q: What is the \[\_Bitnami Legacy\_ repository\](https://hub.docker.com/u/bitnamilegacy)?\*\*
> \*\*A:\*\* The \[\_Bitnami Legacy\_ repository\](https://hub.docker.com/u/bitnamilegacy) is an archive that will host all older container images, including versioned tags (e.g., \_2.50.0\_, \_10.6\_) that are no longer maintained in the main Bitnami catalog. These images will not receive updates, fixes, or support and should only be used as a temporary fallback for migration purposes. Although there are no updates to the container images, the Bitnami project continues to make its source code available at \[bitnami/containers\](https://github.com/bitnami/containers) under the Apache 2 license.
> 
> \*\*Q: How is \[\_Bitnami Legacy\_ repository\](https://hub.docker.com/u/bitnamilegacy) different than \[\_Bitnami Mainline\_ repository\](https://hub.docker.com/u/bitnami)?\*\*
> \*\*A:\*\*
> \- The \[\_Bitnami Mainline\_ repository\](https://hub.docker.com/u/bitnami) (\`docker.io/bitnami\`) currently hosts regularly updated and supported container images, including free and enterprise-grade offerings.
> \- The \[\_Bitnami Legacy\_ repository\](https://hub.docker.com/u/bitnamilegacy) will contain archived versions that will no longer receive updates. It is provided solely to help with migration during the transition.
> 
> After August 28th, 2025, only a limited set of hardened images will remain in the \[\_Bitnami Mainline\_ repository\](https://hub.docker.com/u/bitnami). All others will be moved to the \[\_Bitnami Legacy\_ repository\](https://hub.docker.com/u/bitnamilegacy).
> 
> \*\*Q: What do users of \[\_Bitnami Mainline\_ repository\](https://hub.docker.com/u/bitnami) need to do before August 28th, 2025?\*\*
> \*\*A:\*\* Users should:
> 1. Review and update CI/CD pipelines to avoid relying on deprecated images.
> 2. Consider subscribing to Bitnami Secure Images if they need continued support, security updates, or access to full version history at https://go-vmware.broadcom.com/contact-us.
> 3. Upgrade their deployments
> 1. If the deployed application belongs to the limited set of hardened images available under the new free community tier, double-check that the used tags are still updated.
> 2. Otherwise, point to the \[\_Bitnami Legacy\_ repository\](https://hub.docker.com/u/bitnamilegacy) as a temporary workaround.
> 
> \*\*Q: Are Bitnami’s free images going away?\*\*
> \*\*A:\*\* Not entirely. Bitnami will continue to offer a limited subset of free, latest-version images intended for development use. These images will be more hardened and secure, but older versions and many applications will be removed from the free tier and moved to the \[\_Bitnami Legacy\_ repository\](https://hub.docker.com/u/bitnamilegacy). You can browse the images available for free at https://hub.docker.com/u/bitnamisecure until August 28th, after which the main Bitnami registry will have the same content.
> 
> \*\*Q: How can I obtain continued support for an application that is no longer available for free?\*\*
> \*\*A:\*\* To continue receiving updates, security patches, and enterprise support for older or specific versions of an application, you can subscribe to the Bitnami Secure Images offering. This includes access to:
> \- Long-term support (LTS) branches
> \- Distroless and hardened images
> \- SBOMs, CVE transparency (VEX/KEV), and compliance artifacts
> \- SLSA Level 3 build processes
> 
> The Bitnami project continues to make its source available at \[bitnami/containers\](https://github.com/bitnami/containers) under the Apache 2 license; images can be built from source.
> 
> \*\*Q: What will happen to the existing OCI Helm charts?\*\*
> \*\*A:\*\* The already packaged Helm charts will remain available at \`docker.io/bitnamicharts\` as OCI artifacts, but they will no longer receive updates\*. Deploying these charts will not work out-of-the-box\* unless you override the bundled images with valid ones.
> \_\*except for the BSI images included in the free community-tier subset.\_
> 
> \*\*Q: What will happen to the Helm charts source code?\*\*
> \*\*A:\*\* No changes are being made to the helm chart source code on \[https://github.com/bitnami/charts\](https://github.com/bitnami/charts). It continues to be available under the Apache 2 license.
> 
> \*\*Q: How can I get a complete list of what images and charts are available from Bitnami, both free and commercial?\*\* 
> \*\*A:\*\* We are working on an enhanced public directory that inventories everything available from Bitnami. In the meantime, you can determine the subset of images that will remain free/community by looking at what is in this registry: \[BSI Dockerhub\](https://hub.docker.com/u/bitnamisecure/). All remaining Bitnami images/charts, as well as new ones being developed, are available via custom private registries provided as part of a BSI commercial subscription. 
> 
> \*\*Q: How can I get continued support for Helm charts?\*\*
> \*\*A:\*\* If your deployed Helm chart is failing to pull images from docker.io/bitnami, to ensure continued support and access to security updates, we recommend subscribing to Bitnami Secure Images at https://go-vmware.broadcom.com/contact-us.
> As a temporary workaround, you can keep using the same Helm chart version by pointing it to the “\[\_Bitnami Legacy\_ repository\](https://hub.docker.com/u/bitnamilegacy), which hosts archived images with no further updates. For that, you can upgrade to the same chart version and update the repository parameter of each container image to the \[\_Bitnami Legacy\_ repository\](https://hub.docker.com/u/bitnamilegacy):
> \- List container images: \`\`grep 'repository.\*REPOSITORY\_NAME/' postgresql/README.md | awk -F'\\\`' '{print $2, $(NF-1)}'\`\`
> \- Upgrade modifying repositories: \`helm upgrade RELEASE\_NAME oci://registry-1.docker.io/bitnamicharts/CHART\_NAME --version SAME\_VERSION --set REPOSITORY\_REFERENCE=bitnamilegacy\`
> \- \`REPOSITORY\_REFERENCE\` is the path to the repository parameter as it is in the values.yaml for each container image.
> \- Example:
> \`\`\`console
> $ grep 'repository.\*REPOSITORY\_NAME/' postgresql/README.md | awk -F'\\\`' '{print $2, $(NF-1)}'
> image.repository REPOSITORY\_NAME/postgresql
> volumePermissions.image.repository REPOSITORY\_NAME/os-shell
> metrics.image.repository REPOSITORY\_NAME/postgres-exporter
> \`\`\`
> \`\`\`
> $ helm upgrade mypostgres oci://registry-1.docker.io/bitnamicharts/postgresql \\
> \--version 16.7.0 \\
> \--set image.repository=bitnamilegacy/postgresql \\
> \--set volumePermissions.image.repository=bitnamilegacy/os-shell \\
> \--set metrics.image.repository=bitnamilegacy/postgres-exporter \\
> \--set global.security.allowInsecureImages=true
> \`\`\`
> 
> \--------------------
> 
> \> \[!NOTE\]  
> \> \[Sealed Secrets\](https://github.com/bitnami-labs/sealed-secrets), \[charts-syncer\](https://github.com/bitnami/charts-syncer) and \[minideb\](https://github.com/bitnami/minideb) remain unaffected by these changes. Container images for those projects will continue to be released on \[docker.io/bitnami\](\`http://docker.io/bitnami\`) as usual without any modifications.

In short, there will probably be substantial work in the future to deal with these problems. If an alternate provider cannot be found I may have to take on supporting the Docker container and Helm chart myself. It may also be worth considering an alternative service, but I am not aware of a viable one. Given that all of my video content is on this service, this presents a substantial problem for my platform and workflow.

The future of MinIO on eom.dev is uncertain, and I am open to suggestions for how best to deal with these issues.
