Quando contamos que estamos deixando o MinIO, a reação mais comum é a pergunta: por quê? Este texto responde com fontes e com o que vivemos na prática. É o artigo irmão do relato de execução: lá está o como, aqui está o por que saímos do MinIO. Um aviso: isto é um texto de opinião, escrito por quem paga as contas de um time pequeno, e as opiniões estão marcadas como tal.
O que aconteceu com o MinIO community
A edição community do MinIO foi perdendo coisas ao longo de 2025. Em junho, o Blocks and Files registrou que recursos de gerenciamento tinham saído do código da edição básica. Segundo a cronologia reunida pela ayedo, o projeto parou de publicar imagens Docker nos registries públicos em outubro, entrou em modo de manutenção em dezembro e, no início de 2026, passou a avisar que o repositório não é mais mantido. A InfoQ já falava, em dezembro, das alternativas compatíveis com a API S3. Confira as datas nas fontes: aqui usamos o resumo delas, não a nossa memória.
O que isso mudou para a gente
Na prática, quatro coisas. Primeiro, sem manutenção upstream, correções de segurança deixam de ser algo que você pode esperar. Segundo, a distribuição: quando um dos nossos times tentou baixar a imagem do MinIO para um teste de CI, encontrou todos os canais públicos fechados ou sem acesso anônimo. Terceiro, o console: a versão community já tinha perdido a interface completa de administração.
Quarto, e esta é opinião nossa: o caminho que o MinIO aponta é o produto comercial, o AIStor, e para um time pequeno esse preço é caro demais. Não vamos colocar número aqui, porque preço muda e depende de contrato: faça a sua conta. A nossa não fechou.
Nenhuma dessas coisas derruba um servidor hoje. Mas todas empurram o custo para o futuro, e time pequeno não tem folga para pagar esse custo de uma vez, numa madrugada ruim.
Os critérios da decisão
Partimos de três critérios. Zero mudança para os clientes: nossas aplicações, backups e o site falam S3 com chaves e hostnames fixos, então cada consumidor reconfigurado é risco. Rollback de verdade: tem que dar para voltar em um comando, com os dados intactos. E custo baixo, de operação e de licença: um time pequeno não aprende um sistema novo inteiro, nem paga uma assinatura que não cabe no orçamento, por causa de uma troca forçada.
O trade-off é honesto. Esses critérios favorecem a opção mais parecida com o que já temos, e isso nos deixa um passo atrás de uma arquitetura nova que talvez fosse melhor a longo prazo.
Por que o Silo agora, e RustFS ou Garage depois
O Silo é um fork comunitário mantido pela Pigsty que, segundo o próprio manifesto do projeto e a documentação, mantém a API S3, as variáveis de ambiente e o formato em disco, e restaura o console embutido, sob a licença AGPLv3. Como as fontes são do próprio projeto, validamos a compatibilidade nos nossos dados antes de confiar: o relato está no artigo de execução.
Isso encaixa nos três critérios, então o Silo é a nossa ponte. Ele não é o destino. Para depois, vamos olhar o RustFS, se quisermos algo parecido com o jeito MinIO de operar, e o Garage, se a prioridade virar vários locais com hardware modesto. Não avaliamos outras alternativas a fundo, então este texto não as recomenda nem descarta.
Fechando
Agora a cutucada: sim, a gente chama o time do MinIO de traidor do open source. Pegou um projeto aberto, foi esvaziando a edição community e empurrou todo mundo para o produto pago. É a nossa opinião, dita com a ironia de sempre. E, de novo, é só uma cutucada, uma brincadeira, não é para levar a sério. Aliás, o fim da história é bem open source: o código que eles abriram é justamente o que permite que um fork como o Silo exista.
A decisão em si é sobre risco, preço e tamanho de time. Se a sua situação é parecida, o melhor primeiro passo é simples: descubra quem depende do seu storage e escolha a troca que não obriga ninguém a mudar.