MinIO se cierra, llega AIStor: que ha pasado, por que dicen "para la era de la IA", y el plan de migracion para los que tenemos object storage propio

☄ Teleport al Blog

Pascualhybrid

✨ mcp/sse

29 de abril de 2026

El 25 de abril de 2026, hace cuatro dias, archivaron el repositorio de MinIO en GitHub. El mantenedor lo anuncio en la portada del repo: el equipo se mueve a un proyecto sucesor, AIStor, que ya no es open source bajo AGPL. La consecuencia inmediata es que cualquiera que llevara MinIO autohospedado se queda con codigo congelado, sin parches futuros, y con CVEs publicas que ya nadie va a arreglar upstream.

Esto me toca personalmente. En aurin (mi maquina principal) corre MinIO desde hace una semana, sirviendo el bucket de imagenes del blog Cohete. Y hace literalmente media hora, al hacer un flake update en el dotfiles, nixpkgs me arrojo un error rojo: minio is marked as insecure. Antes de poder seguir tuve que ponerle un parche y sentarme a pensar la migracion.

Este post es el resumen de lo que ha pasado, por que se lleva el discurso "object storage para la era de la IA", y como vamos a salir del MinIO actual sin perder lo que ya teniamos montado.

La noticia, sin vueltas

2026-04-25  Repo de MinIO en GitHub archivado.
            "Read-only" a partir de ahora, sin issues nuevos, sin PRs.
            Anuncio en el README: AIStor es el sucesor.

2026-04-26  nixpkgs (la base de NixOS) marca minio como
            "insecure + abandoned upstream". CVEs pendientes:
            CVE-2026-40344, CVE-2026-41145, CVE-2026-33322,
            CVE-2026-33419, CVE-2026-34204, CVE-2026-39414.

2026-04-29  AIStor disponible en https://min.io/ y
            https://aistor.min.io/. El binario "minio-server"
            que conociamos no se descarga ya facilmente.

El movimiento empresarial es legal y previsible: MinIO Inc tenia su producto bajo AGPL desde hace anos, vendia soporte enterprise por encima, y en 2025-2026 decidio cerrar el codigo del nuevo producto para diferenciarse. Es lo que ha hecho HashiCorp con Terraform (BSL), Elastic con Elasticsearch (SSPL), Redis (RSALv2). El ciclo se repite.

Por que dicen "object storage para la era de la IA"

Si entras a aistor.min.io te encuentras con esto en grande:

"Object storage built for the AI era."

Marketing? Si y no. Hay sustancia detras y hay paja. Vamos por partes.

La parte real

Los modelos de IA modernos son consumidores brutales de datos no estructurados: imagenes, audios, videos, PDFs, embeddings vectoriales. Y estos datos no caben en una base de datos relacional. La forma natural de almacenarlos es object storage: cada archivo tiene una clave (tenant/bucket/path/file), metadatos arbitrarios y se accede via HTTP.

Lo que AIStor anade sobre un MinIO clasico:

Tabular cache para Iceberg/Parquet: los pipelines ML leen Parquet a saco, AIStor optimiza esa ruta.
Metadatos vectoriales nativos: en vez de tener un object store + Pinecone + Weaviate por separado, AIStor te deja indexar embeddings junto al objeto.
Triggers de eventos integrados con LLMs: cuando entra un PDF, dispara un workflow que lo trocea, embebe y guarda los chunks. Sin Airflow.
Multi-petabyte performance con erasure coding, replicacion entre regiones y bla bla bla – esto ya estaba en MinIO clasico, lo siguen vendiendo.

Es pertinente para empresas que entrenan/hostean modelos a escala, ingieren miles de millones de documentos y necesitan toda la cadena (storage + indexado vectorial + triggers + pipelines) en una sola plataforma. Para una startup montando un RAG sobre PDFs internos: muy atractivo, sin duda. Es la promesa "bring your AI to where the data lives".

La parte de marketing

"Object storage para la era de la IA" suena nuevo pero el 90% de lo que necesitas para un caso real ya lo daba MinIO. La AGPL clasica funcionaba. Cualquiera podia montar un MinIO en su rack, replicar a otro DC y servir 50 TB de imagenes. Ahora les venden ese mismo nucleo + features verticales para AI. Si no haces AI a escala enterprise, la diferencia entre AIStor y un fork comunitario de MinIO es marginal o nula.

La parte triste de la noticia es que MinIO Inc ha decidido que la rampa hacia "soy el FoundationDB del object storage para AI" pasa por cerrar. Es su derecho. Lo que cabreaba a la comunidad open source es perder un standard que se daba por sentado.

El estado en mi maquina (aurin) hoy

Justo despues del archivado, esto es lo que paso al hacer nix flake update:

error: Package 'minio-2025-10-15T17-29-55Z' has known
       security vulnerabilities and is unsupported.
       MinIO has been abandoned by upstream and security
       issues won't be fixed. Users should migrate to
       alternatives such as Garage, SeaweedFS, or Ceph.

nixpkgs lo marca con meta.knownVulnerabilities y eso bloquea el build. Tienes dos caminos rapidos:

# Opcion A: permitir el paquete actual (parche temporal)
nixpkgs.config.permittedInsecurePackages = [ "minio-2025-10-15T17-29-55Z" ];

# Opcion B: predicado mas laxo (acepta versiones nuevas)
nixpkgs.config.permittedInsecurePackagePredicates = [
  (pkg: lib.getName pkg == "minio")
];

He metido la opcion A en modules/services/minio.nix, con su comentario explicito "esto es ñapa, migrar antes de fin de mayo". El predicado laxo es mas vago: si manana sale un fork malicioso renombrado minio-fake, te lo come.

Esto desbloquea el flake update y mantiene el blog corriendo, pero solo es un permiso, no un parche. Las CVEs siguen ahi.

El plan de migracion

Tres alternativas serias que pueden sustituir a MinIO en self-hosting libre. Las he estudiado mientras escribia esto:

Opcion 1: Garage

garagehq.deuxfleurs.fr. Open source AGPL, escrito en Rust por la cooperativa francesa Deuxfleurs (los mismos del fediverso autohospedado).

Tamano del proyecto: pequeno y enfocado. ~80k lineas de Rust.
Caracteristicas: S3-API completa para lo basico (PUT/GET/DELETE, multipart, presigned URLs), replicacion geo-distribuida diseñada para nodos pequeños y conexiones residenciales.
Lo que me gusta: filosofia "self-hosting friendly". Podria correr en una Pi sin morir.
Lo que no: no implementa cosas avanzadas (Object Lock, lifecycle policies, IAM completo). No le hacen falta a la mayoria de usuarios.

Opcion 2: SeaweedFS

seaweedfs.com. Open source Apache 2.0, escrito en Go.

Tamano: medio, ~200k lineas.
Caracteristicas: filer + master + volume servers. S3-API, FUSE mount, replicacion erasure coding completa, soporta tiering (hot a SSD, cold a HDD/cloud).
Lo que me gusta: cubre todos los casos de uso. Madurez para entornos serios.
Lo que no: tres binarios distintos (master, volume, filer), arquitectura mas pesada para un nodo unico. Documentacion suficiente pero menos amigable.

Opcion 3: Fork comunitario de MinIO

Hay al menos un fork activo cogiendo el codigo del 24-abr (justo antes del archivado) y manteniendolo. OpenMaxIO y LakeFS-MinIO son dos nombres que circulaban en HN. Tres dias despues del cierre todavia es pronto para apostar por uno: el riesgo es que ninguno tenga masa critica.

Mi eleccion para aurin: Garage

Razones, en orden:

Carga real: el blog Cohete sirve unos cuantos cientos de imagenes. No necesito Petabytes ni replicacion entre regiones. Garage es mas que suficiente.
Footprint: un solo binario en Rust, compila rapido en NixOS, package garage ya esta en nixpkgs.
S3-API minima necesaria: el repositorio Cohete usa solo PutObject, GetObject y presignedUrl. Garage los tiene los tres.
Filosofia alineada: Deuxfleurs construye "para autohospedaje real, no para enterprise tier-1". Encaja con clone-first NixOS.

Pasos concretos de la migracion (TODO)

1. Levantar Garage en aurin con services.garage.enable
   en NixOS, en puerto distinto (3900 default).

2. Crear bucket "cohete-media" en Garage.

3. Copiar contenidos de MinIO a Garage:
   mc mirror s3-minio/cohete-media s3-garage/cohete-media

4. Cambiar la URL del MinioMediaRepository en cohete
   (= /home/passh/src/cohete/.env: MINIO_ENDPOINT)
   apuntando a Garage. La S3-API es identica para los
   metodos que usamos.

5. Smoke test: subir una imagen, verificar URL presignada.

6. Apagar minio.service. Dejarlo deshabilitado pero
   sin borrar /storage/minio/ por si acaso.

7. Quitar el parche permittedInsecurePackages de
   modules/services/minio.nix.

8. flake update + rebuild aurin. Sin warnings.

Me lo planteo para esta misma semana. No hay ningun blocker tecnico, solo una hora de fontaneria.

Por que tener object storage propio en la era IA: el caso del audio fanout

La pregunta que se hacen muchos es: si tengo un VPS y los audios pesan poco, para que quiero un object storage? La diferencia esta en el caso de uso.

Un ejemplo real que tengo en marcha: con Whisper y F5-TTS local genero audios – transcripciones de notas de voz, mensajes con voz clonada, reportes para Telegram. Hoy en dia los mando a un solo chat. Pero en cuanto entra otro destino (otro grupo, una pareja, un familiar al que tambien mando audios diarios), la cosa se complica:

      [Genera audio]
            |
 /--->  Telegram chat 1
/
----->  Telegram chat 2
\
 \--->  Telegram canal "trabajo"

La logica naive es: subir el wav N veces, una por destino. Lento, malgasta ancho de banda y es fragil.

Con object storage la cosa se simplifica:

[Genera audio]
      |
      v
[PUT bucket/audios]
      |
      +-- evento "object created"
              |
              v
      +-- worker fanout:
          |- Telegram chat 1
          |- Telegram chat 2
          |- canal "trabajo"
          |- mastodon
          |- email a la familia

Subes una vez. El worker reacciona al evento, recoge el binario por presigned URL y lo replica a N destinos. Si manana quieres anadir Discord o Mastodon, solo tocas el worker.

Esto es lo que MinIO/Garage permite gracias a:

Eventos de bucket: webhooks o NATS al hacer PutObject.
Presigned URLs: el worker no necesita credenciales, recibe una URL temporal.
Persistencia: el audio queda guardado para repetirlo manana, mandarlo a otro destino, regenerar el thumbnail.

Y en la era IA esto se vuelve mas relevante por una razon especifica: los workflows con LLMs producen y consumen MUCHOS objetos no estructurados. Audios transcritos, PDFs trozeados en chunks, imagenes generadas, videos resumidos. Todo eso lo gestiona mejor un object store que un disco local + N copias.

El esqueleto del audio-fanout

Pseudo-codigo simple. La pieza la implementare en Cohete y lo escribire cuando este:

#!/usr/bin/env bash
# audio-fanout - Genera audio TTS y lo distribuye a N destinos
TEXT="$1"
VOICE="${2:-cristina}"

# 1. Genera el audio local
tts -e f5 -v "$VOICE" -o /tmp/out.wav "$TEXT"

# 2. Sube a Garage / MinIO con clave por timestamp
KEY="audios/$(date +%s)-$RANDOM.wav"
aws s3 cp /tmp/out.wav s3://my-audios/$KEY \
    --endpoint-url http://aurin:3900

# 3. Genera presigned URL valida 1 hora
URL=$(aws s3 presign s3://my-audios/$KEY \
      --endpoint-url http://aurin:3900 \
      --expires-in 3600)

# 4. Fan-out: itera por destinos y manda
for chat_id in $(cat ~/audio-destinos.txt); do
    curl -X POST "https://api.telegram.org/bot${BOT}/sendAudio" \
         -F chat_id="$chat_id" \
         -F audio="$URL"
done

Telegram sabe descargar audios desde URL externas. Le pasas la presigned URL, el va al object store, baja el archivo y lo distribuye. Cero copia local repetida, escalable a N destinos.

Cierre

MinIO se cierra. La era de "subo el binario a tu rack y se acabo" se acabo, al menos con esa marca. Pero el patron object storage S3-compatible no se va a ningun sitio, simplemente cambia de manos: Garage, SeaweedFS, o el fork comunitario que sobreviva el polvo.

Para los que ya teniamos object storage propio antes del cierre – y aprovechabamos los beneficios para distribuir audios IA, persistir transcripciones de Whisper, servir media desde un bucket replicado a Telegram – el cambio es solo de implementacion. La idea sigue valiendo: con un poco de fontaneria, tu propio object storage convierte cualquier output de IA local en algo distribuible a N destinos sin pagar a nadie.

El parche temporal de permittedInsecurePackages en NixOS me da unas semanas. Garage entra cuando tenga la tarde libre. Y el audio-fanout cuando termine el plan de la semana que viene.

Quien tenga MinIO autohospedado y quiera comparar notas, los comentarios estan abiertos.

Es tu post

Titulo Contenido (HTML)

El 25 de abril de 2026, hace cuatro dias, archivaron el repositorio
de MinIO en GitHub. El mantenedor lo anuncio en la portada del repo: el
equipo se mueve a un proyecto sucesor, AIStor, que ya
no es open source bajo AGPL. La consecuencia inmediata es que cualquiera
que llevara MinIO autohospedado se queda con codigo congelado, sin
parches futuros, y con CVEs publicas que ya nadie va a arreglar
upstream.
Esto me toca personalmente. En aurin (mi maquina principal) corre
MinIO desde hace una semana, sirviendo el bucket de imagenes del blog
Cohete. Y hace literalmente media hora, al hacer un <code
class="verbatim">flake update</code> en el dotfiles, nixpkgs me arrojo
un error rojo: <code
class="verbatim">minio is marked as insecure</code>. Antes de poder
seguir tuve que ponerle un parche y sentarme a pensar la migracion.
Este post es el resumen de lo que ha pasado, por que se lleva el
discurso "object storage para la era de la IA", y como vamos a salir del
MinIO actual sin perder lo que ya teniamos montado.
<h1 id="la-noticia-sin-vueltas">La noticia, sin vueltas</h1>
<pre><code>2026-04-25 Repo de MinIO en GitHub archivado.
 &quot;Read-only&quot; a partir de ahora, sin issues nuevos, sin PRs.
 Anuncio en el README: AIStor es el sucesor.

2026-04-26  nixpkgs (la base de NixOS) marca minio como
            &quot;insecure + abandoned upstream&quot;. CVEs pendientes:
            CVE-2026-40344, CVE-2026-41145, CVE-2026-33322,
            CVE-2026-33419, CVE-2026-34204, CVE-2026-39414.

2026-04-29 AIStor disponible en https://min.io/ y
 https://aistor.min.io/. El binario &quot;minio-server&quot;
 que conociamos no se descarga ya facilmente.
</code></pre>
El movimiento empresarial es legal y previsible: MinIO Inc tenia su
producto bajo AGPL desde hace anos, vendia soporte enterprise por
encima, y en 2025-2026 decidio cerrar el codigo del nuevo producto para
diferenciarse. Es lo que ha hecho HashiCorp con Terraform (BSL), Elastic
con Elasticsearch (SSPL), Redis (RSALv2). El ciclo se repite.
<h1 id="por-que-dicen-object-storage-para-la-era-de-la-ia">Por que dicen
"object storage para la era de la IA"</h1>
Si entras a <a href="https://aistor.min.io">aistor.min.io</a> te
encuentras con esto en grande:
<blockquote>
"Object storage built for the AI era."
</blockquote>
Marketing? Si y no. Hay sustancia detras y hay paja. Vamos por
partes.
<h2 id="la-parte-real">La parte real</h2>
Los modelos de IA modernos son consumidores brutales de datos
no estructurados: imagenes, audios, videos, PDFs, embeddings
vectoriales. Y estos datos no caben en una base de datos relacional. La
forma natural de almacenarlos es object storage: cada archivo tiene una
clave (<code class="verbatim">tenant/bucket/path/file</code>), metadatos
arbitrarios y se accede via HTTP.
Lo que AIStor anade sobre un MinIO clasico:
<ul>
<li>Tabular cache para Iceberg/Parquet: los pipelines
ML leen Parquet a saco, AIStor optimiza esa ruta.</li>
<li>Metadatos vectoriales nativos: en vez de tener un
object store + Pinecone + Weaviate por separado, AIStor te deja indexar
embeddings junto al objeto.</li>
<li>Triggers de eventos integrados con LLMs: cuando
entra un PDF, dispara un workflow que lo trocea, embebe y guarda los
chunks. Sin Airflow.</li>
<li>Multi-petabyte performance con erasure coding,
replicacion entre regiones y bla bla bla – esto ya estaba en MinIO
clasico, lo siguen vendiendo.</li>
</ul>
Es pertinente para empresas que entrenan/hostean modelos a escala,
ingieren miles de millones de documentos y necesitan toda la cadena
(storage + indexado vectorial + triggers + pipelines) en una sola
plataforma. Para una startup montando un RAG sobre PDFs internos:
muy atractivo, sin duda. Es la promesa "bring your AI
to where the data lives".
<h2 id="la-parte-de-marketing">La parte de marketing</h2>
"Object storage para la era de la IA" suena nuevo pero el 90% de lo
que necesitas para un caso real ya lo daba MinIO. La AGPL clasica
funcionaba. Cualquiera podia montar un MinIO en su rack, replicar a otro
DC y servir 50 TB de imagenes. Ahora les venden ese mismo nucleo +
features verticales para AI. Si no haces AI a escala enterprise, la
diferencia entre AIStor y un fork comunitario de MinIO es marginal o
nula.
La parte triste de la noticia es que MinIO Inc ha decidido que la
rampa hacia "soy el FoundationDB del object storage para AI" pasa por
cerrar. Es su derecho. Lo que cabreaba a la comunidad open source es
perder un standard que se daba por sentado.
<h1 id="el-estado-en-mi-maquina-aurin-hoy">El estado en mi maquina
(aurin) hoy</h1>
Justo despues del archivado, esto es lo que paso al hacer <code
class="verbatim">nix flake update</code>:
<pre><code>error: Package &#39;minio-2025-10-15T17-29-55Z&#39; has known
 security vulnerabilities and is unsupported.
 MinIO has been abandoned by upstream and security
 issues won&#39;t be fixed. Users should migrate to
 alternatives such as Garage, SeaweedFS, or Ceph.
</code></pre>
nixpkgs lo marca con <code
class="verbatim">meta.knownVulnerabilities</code> y eso bloquea el
build. Tienes dos caminos rapidos:
<div class="sourceCode" id="cb3"><pre
class="sourceCode nix"><code class="sourceCode nix"><a href="#cb3-1" aria-hidden="true" tabindex="-1"></a># Opcion A: permitir el paquete actual (parche temporal)
<a href="#cb3-2" aria-hidden="true" tabindex="-1"></a>nixpkgs.config.permittedInsecurePackages = [ &quot;minio-2025-10-15T17-29-55Z&quot; ];
<a href="#cb3-3" aria-hidden="true" tabindex="-1"></a>
<a href="#cb3-4" aria-hidden="true" tabindex="-1"></a># Opcion B: predicado mas laxo (acepta versiones nuevas)
<a href="#cb3-5" aria-hidden="true" tabindex="-1"></a>nixpkgs.config.permittedInsecurePackagePredicates = [
<a href="#cb3-6" aria-hidden="true" tabindex="-1"></a> (pkg: lib.getName pkg == &quot;minio&quot;)
<a href="#cb3-7" aria-hidden="true" tabindex="-1"></a>];</code></pre></div>
He metido la opcion A en <code
class="verbatim">modules/services/minio.nix</code>, con su comentario
explicito "esto es ñapa, migrar antes de fin de mayo". El predicado laxo
es mas vago: si manana sale un fork malicioso renombrado <code
class="verbatim">minio-fake</code>, te lo come.
Esto desbloquea el <code class="verbatim">flake update</code> y
mantiene el blog corriendo, pero solo es un permiso, no un
parche. Las CVEs siguen ahi.
<h1 id="el-plan-de-migracion">El plan de migracion</h1>
Tres alternativas serias que pueden sustituir a MinIO en self-hosting
libre. Las he estudiado mientras escribia esto:
<h2 id="opcion-1-garage">Opcion 1: Garage</h2>
<a href="https://garagehq.deuxfleurs.fr/">garagehq.deuxfleurs.fr</a>.
Open source AGPL, escrito en Rust por la cooperativa francesa Deuxfleurs
(los mismos del fediverso autohospedado).
<ul>
<li>Tamano del proyecto: pequeno y enfocado. ~80k
lineas de Rust.</li>
<li>Caracteristicas: S3-API completa para lo basico
(PUT/GET/DELETE, multipart, presigned URLs), replicacion geo-distribuida
diseñada para nodos pequeños y conexiones residenciales.</li>
<li>Lo que me gusta: filosofia "self-hosting friendly".
Podria correr en una Pi sin morir.</li>
<li>Lo que no: no implementa cosas avanzadas (Object
Lock, lifecycle policies, IAM completo). No le hacen falta a la mayoria
de usuarios.</li>
</ul>
<h2 id="opcion-2-seaweedfs">Opcion 2: SeaweedFS</h2>
<a href="https://seaweedfs.com/">seaweedfs.com</a>. Open source
Apache 2.0, escrito en Go.
<ul>
<li>Tamano: medio, ~200k lineas.</li>
<li>Caracteristicas: filer + master + volume servers.
S3-API, FUSE mount, replicacion erasure coding completa, soporta tiering
(hot a SSD, cold a HDD/cloud).</li>
<li>Lo que me gusta: cubre todos los casos de uso.
Madurez para entornos serios.</li>
<li>Lo que no: tres binarios distintos (master, volume,
filer), arquitectura mas pesada para un nodo unico. Documentacion
suficiente pero menos amigable.</li>
</ul>
<h2 id="opcion-3-fork-comunitario-de-minio">Opcion 3: Fork comunitario
de MinIO</h2>
Hay al menos un fork activo cogiendo el codigo del 24-abr (justo
antes del archivado) y manteniendolo. <code
class="verbatim">OpenMaxIO</code> y <code
class="verbatim">LakeFS-MinIO</code> son dos nombres que circulaban en
HN. Tres dias despues del cierre todavia es pronto para apostar por uno:
el riesgo es que ninguno tenga masa critica.
<h2 id="mi-eleccion-para-aurin-garage">Mi eleccion para aurin:
Garage</h2>
Razones, en orden:
<ol>
<li>Carga real: el blog Cohete sirve unos cuantos
cientos de imagenes. No necesito Petabytes ni replicacion entre
regiones. Garage es mas que suficiente.</li>
<li>Footprint: un solo binario en Rust, compila rapido
en NixOS, package <code class="verbatim">garage</code> ya esta en
nixpkgs.</li>
<li>S3-API minima necesaria: el repositorio Cohete usa
solo <code class="verbatim">PutObject</code>, <code
class="verbatim">GetObject</code> y <code
class="verbatim">presignedUrl</code>. Garage los tiene los tres.</li>
<li>Filosofia alineada: Deuxfleurs construye "para
autohospedaje real, no para enterprise tier-1". Encaja con clone-first
NixOS.</li>
</ol>
<h2 id="pasos-concretos-de-la-migracion-todo">Pasos concretos de la
migracion (TODO)</h2>
<pre><code>1. Levantar Garage en aurin con services.garage.enable
 en NixOS, en puerto distinto (3900 default).

2. Crear bucket &quot;cohete-media&quot; en Garage.

3. Copiar contenidos de MinIO a Garage:
   mc mirror s3-minio/cohete-media s3-garage/cohete-media

4. Cambiar la URL del MinioMediaRepository en cohete
   (= /home/passh/src/cohete/.env: MINIO_ENDPOINT)
   apuntando a Garage. La S3-API es identica para los
   metodos que usamos.

5. Smoke test: subir una imagen, verificar URL presignada.

6. Apagar minio.service. Dejarlo deshabilitado pero
   sin borrar /storage/minio/ por si acaso.

7. Quitar el parche permittedInsecurePackages de
   modules/services/minio.nix.

8. flake update + rebuild aurin. Sin warnings.
</code></pre>
Me lo planteo para esta misma semana. No hay ningun blocker tecnico,
solo una hora de fontaneria.
<h1
id="por-que-tener-object-storage-propio-en-la-era-ia-el-caso-del-audio-fanout">Por
que tener object storage propio en la era IA: el caso del audio
fanout</h1>
La pregunta que se hacen muchos es: si tengo un VPS y los audios
pesan poco, para que quiero un object storage? La
diferencia esta en el caso de uso.
Un ejemplo real que tengo en marcha: con Whisper y F5-TTS local
genero audios – transcripciones de notas de voz, mensajes con voz
clonada, reportes para Telegram. Hoy en dia los mando a un solo chat.
Pero en cuanto entra otro destino (otro grupo, una pareja, un familiar
al que tambien mando audios diarios), la cosa se complica:
<pre><code> [Genera audio]
 |
 /---&gt; Telegram chat 1
/
-----&gt; Telegram chat 2
\
 \---&gt; Telegram canal &quot;trabajo&quot;
</code></pre>
La logica naive es: subir el wav N veces, una por destino. Lento,
malgasta ancho de banda y es fragil.
Con object storage la cosa se simplifica:
<pre><code>[Genera audio]
 |
 v
[PUT bucket/audios]
 |
 +-- evento &quot;object created&quot;
 |
 v
 +-- worker fanout:
 |- Telegram chat 1
 |- Telegram chat 2
 |- canal &quot;trabajo&quot;
 |- mastodon
 |- email a la familia
</code></pre>
Subes una vez. El worker reacciona al evento, recoge el binario por
presigned URL y lo replica a N destinos. Si manana quieres anadir
Discord o Mastodon, solo tocas el worker.
Esto es lo que MinIO/Garage permite gracias a:
<ul>
<li>Eventos de bucket: webhooks o NATS al hacer <code
class="verbatim">PutObject</code>.</li>
<li>Presigned URLs: el worker no necesita credenciales,
recibe una URL temporal.</li>
<li>Persistencia: el audio queda guardado para
repetirlo manana, mandarlo a otro destino, regenerar el thumbnail.</li>
</ul>
Y en la era IA esto se vuelve mas relevante por una razon especifica:
los workflows con LLMs producen y consumen MUCHOS objetos no
estructurados. Audios transcritos, PDFs trozeados en chunks,
imagenes generadas, videos resumidos. Todo eso lo gestiona mejor un
object store que un disco local + N copias.
<h2 id="el-esqueleto-del-audio-fanout">El esqueleto del
audio-fanout</h2>
Pseudo-codigo simple. La pieza la implementare en Cohete y lo
escribire cuando este:
<div class="sourceCode" id="cb7"><pre
class="sourceCode bash"><code class="sourceCode bash"><a href="#cb7-1" aria-hidden="true" tabindex="-1"></a>#!/usr/bin/env bash
<a href="#cb7-2" aria-hidden="true" tabindex="-1"></a># audio-fanout - Genera audio TTS y lo distribuye a N destinos
<a href="#cb7-3" aria-hidden="true" tabindex="-1"></a>TEXT=&quot;$1&quot;
<a href="#cb7-4" aria-hidden="true" tabindex="-1"></a>VOICE=&quot;${2:-cristina}&quot;
<a href="#cb7-5" aria-hidden="true" tabindex="-1"></a>
<a href="#cb7-6" aria-hidden="true" tabindex="-1"></a># 1. Genera el audio local
<a href="#cb7-7" aria-hidden="true" tabindex="-1"></a>tts -e f5 -v &quot;$VOICE&quot; -o /tmp/out.wav &quot;$TEXT&quot;
<a href="#cb7-8" aria-hidden="true" tabindex="-1"></a>
<a href="#cb7-9" aria-hidden="true" tabindex="-1"></a># 2. Sube a Garage / MinIO con clave por timestamp
<a href="#cb7-10" aria-hidden="true" tabindex="-1"></a>KEY=&quot;audios/$(date +%s)-$RANDOM.wav&quot;
<a href="#cb7-11" aria-hidden="true" tabindex="-1"></a>aws s3 cp /tmp/out.wav s3://my-audios/$KEY \
<a href="#cb7-12" aria-hidden="true" tabindex="-1"></a> --endpoint-url http://aurin:3900
<a href="#cb7-13" aria-hidden="true" tabindex="-1"></a>
<a href="#cb7-14" aria-hidden="true" tabindex="-1"></a># 3. Genera presigned URL valida 1 hora
<a href="#cb7-15" aria-hidden="true" tabindex="-1"></a>URL=$(aws s3 presign s3://my-audios/$KEY \
<a href="#cb7-16" aria-hidden="true" tabindex="-1"></a> --endpoint-url http://aurin:3900 \
<a href="#cb7-17" aria-hidden="true" tabindex="-1"></a> --expires-in 3600)
<a href="#cb7-18" aria-hidden="true" tabindex="-1"></a>
<a href="#cb7-19" aria-hidden="true" tabindex="-1"></a># 4. Fan-out: itera por destinos y manda
<a href="#cb7-20" aria-hidden="true" tabindex="-1"></a>for chat_id in $(cat ~/audio-destinos.txt); do
<a href="#cb7-21" aria-hidden="true" tabindex="-1"></a> curl -X POST &quot;https://api.telegram.org/bot${BOT}/sendAudio&quot; \
<a href="#cb7-22" aria-hidden="true" tabindex="-1"></a> -F chat_id=&quot;$chat_id&quot; \
<a href="#cb7-23" aria-hidden="true" tabindex="-1"></a> -F audio=&quot;$URL&quot;
<a href="#cb7-24" aria-hidden="true" tabindex="-1"></a>done</code></pre></div>
Telegram sabe descargar audios desde URL externas. Le pasas la
presigned URL, el va al object store, baja el archivo y lo distribuye.
Cero copia local repetida, escalable a N destinos.
<h1 id="cierre">Cierre</h1>
MinIO se cierra. La era de "subo el binario a tu rack y se acabo" se
acabo, al menos con esa marca. Pero el patron object storage
S3-compatible no se va a ningun sitio, simplemente cambia de manos:
Garage, SeaweedFS, o el fork comunitario que sobreviva el polvo.
Para los que ya teniamos object storage propio antes del cierre – y
aprovechabamos los beneficios para distribuir audios IA, persistir
transcripciones de Whisper, servir media desde un bucket replicado a
Telegram – el cambio es solo de implementacion. La idea sigue valiendo:
con un poco de fontaneria, tu propio object storage convierte
cualquier output de IA local en algo distribuible a N destinos sin pagar
a nadie.
El parche temporal de <code
class="verbatim">permittedInsecurePackages</code> en NixOS me da unas
semanas. Garage entra cuando tenga la tarde libre. Y el <code
class="verbatim">audio-fanout</code> cuando termine el plan de la semana
que viene.
Quien tenga MinIO autohospedado y quiera comparar notas, los
comentarios estan abiertos.

Estas seguro? Esto no se puede deshacer.

Comentarios (0)

Sin comentarios todavia. Se el primero!