O repositório do MinIO não é mais mantido

 (github.com/minio)
2 pontos por GN⁺ 2026-02-14 | 1 comentários | Compartilhar no WhatsApp
  • O arquivo README.md foi modificado para deixar explícito que o projeto não é mais mantido
  • O texto anterior de “modo de manutenção” foi removido e, no lugar, foi adicionado o aviso “THIS REPOSITORY IS NO LONGER MAINTAINED”
  • No topo do README, são apresentadas duas opções alternativas: AIStor Free e AIStor Enterprise
  • Erros de links na documentação foram corrigidos, e a URL do canal no Slack foi ajustada corretamente
  • Com essa mudança, foi confirmado que o repositório open source do MinIO foi colocado em estado somente leitura (archive)

Principais mudanças no README.md

  • A seção anterior “Maintenance Mode” foi removida por completo e substituída por um novo bloco de observação

    • O novo bloco inclui a frase “THIS REPOSITORY IS NO LONGER MAINTAINED”
    • Em “Alternatives”, são listados dois produtos substitutos
      • AIStor Free: versão independente gratuita para a comunidade
      • AIStor Enterprise: versão distribuída com suporte comercial

  • O link de orientação de assinatura relacionado ao AIStor que existia na documentação anterior foi removido e substituído por uma explicação alternativa mais concisa

Outras correções e ajustes

  • O link do Slack foi corrigido de https//slack.min.io para https://slack.min.io
  • No exemplo de variável de ambiente, o erro de digitação (GOARCh) foi corrigido para GOARCH
  • No texto da licença AGPLv3, o erro ortográfico (liabilites) foi corrigido para liabilities
  • Uma linha em branco foi adicionada à seção “Legacy Binary Releases”, melhorando a legibilidade

Estado do repositório

  • No topo da página do GitHub, aparece a mensagem “This repository was archived by the owner on Feb 13, 2026. It is now read-only.”
  • Isso significa que o repositório foi arquivado e não aceita mais alterações nem contribuições

Significado

  • Junto com a alteração no README, o repositório passou oficialmente para o estado de fim de manutenção e arquivamento
  • Em vez da versão open source do MinIO, a migração orientada é para a linha de produtos AIStor Free/Enterprise
  • O suporte da comunidade continua sendo oferecido via GitHub e Slack em regime de best-effort

Leituras relacionadas

1 comentários

 
GN⁺ 2026-02-14
Comentários no Hacker News

  • Acho que não há problema no fato de a MinIO ter fechado o código-fonte
    Há gente demais no mundo todo usando de graça
    Tenho testado alternativas há alguns meses e, depois da MinIO, acho que a RustFS será a vencedora
    Comparei Garage, SeaweedFS, Ceph e RustFS; RustFS e SeaweedFS foram as mais rápidas, e a instalação e o console da RustFS foram os mais convenientes
    O Ceph é complexo demais, então é difícil implantá-lo sem entender o código-fonte em profundidade
    Há críticas de que o CLA da RustFS é uma “isca”, mas não acho exagerado como mecanismo para reduzir risco legal
    A Milvus também avaliou a RustFS de forma muito positiva e, olhando para os indicadores técnicos, acredito que a RustFS acabará vencendo
    Texto da Milvus avaliando a RustFS

    • Como mantenedor da Milvus, quero compartilhar algumas opiniões
      O problema dos usuários gratuitos existe de fato e, na era da IA, ficou ainda mais sério
      Muitos usuários usam o projeto de graça, mas a taxa de conversão para clientes pagantes é muito baixa
      A Milvus precisa de um object storage melhor para estabilidade e desempenho, e a RustFS é uma forte candidata
      Mas, no longo prazo, se o ecossistema não atender a isso, também teremos de considerar construir algo próprio
      Precisamos discutir a sustentabilidade do modelo de licenciamento open source
      O modelo da era Apache 2.0 está mostrando seus limites, e simplesmente “esperar que as empresas apoiem” já não funciona mais
      A decisão da MinIO merece atenção como sinal dessa mudança
    • Eu opero Ceph em um cluster k8s, com 4 nós e dois SSDs de 4 TB em cada um
      A configuração foi complexa, mas agora está muito estável
      O Claude Code é excelente para administrar Ceph e lida facilmente com recuperação e até com ajustes no mapa CRUSH
      Acho exagerada a afirmação de que “não dá para implantar sem entender o código-fonte em profundidade”
      Se o Ceph for adequado ao seu caso de uso, recomendo muito testar
    • Instalar o Garage é muito simples
      Basta instalar um binário único e escrever o arquivo de configuração /etc/garage.toml
      Você pode executá-lo com garage server ou até pedir para uma IA escrever o script de init
      O AIStore da NVIDIA também é um excelente sistema compatível com S3, e pode ser visto no site oficial do AIStore
      É mais rápido que a MinIO, mas um pouco menos eficiente em uso de espaço
      O SeaweedFS passa muito a impressão de projeto pessoal, e pode ser arriscado se você não fizer backups com frequência
      Quero evitar a RustFS por causa da questão do CLA, porque parece uma repetição do caso MinIO
    • O SeaweedFS é baseado no design Haystack do Facebook e é voltado para um objetivo específico: minimizar buscas de metadados
      Ele opera por volume, e as atualizações também são feitas por volume
      Já um object storage mais geral também é usado como backend para analytics, então precisa de varredura rápida
      Portanto, o SeaweedFS tem trade-offs diferentes dos de um object storage de uso geral
    • Foi dito que o CLA da RustFS reduz risco legal, mas tenho curiosidade sobre que riscos legais específicos isso reduziria

  • Quando parei de operar um serviço open source, a fadiga crônica desapareceu
    Trabalhar de graça não era prazeroso, e manter ao mesmo tempo a versão paga e a versão comunitária também era difícil
    A relação com usuários que não pagam acabava sendo estressante
    Parece que a equipe da MinIO aprendeu a mesma lição

    • A equipe da MinIO não trabalhou de graça
      Era um modelo de COSS (Commercial Open Source Software), oferecendo a versão básica de graça e vendendo recursos pagos para clientes corporativos
      A mudança para código fechado foi apenas uma decisão de negócio
      Usei SeaweedFS em produção por muito tempo e hoje o opero junto com Wasabi
      O SeaweedFS continua excelente para uso com armazenamento local rápido
    • Cobrar pelo produto é natural, mas acho problemático promovê-lo primeiro como FOSS e depois fazer mudança de licença
      Isso deveria ter sido deixado claro desde o começo
      Caso contrário, o certo é cumprir o compromisso anterior
    • Mantenho um sistema de armazenamento open source há alguns anos e ainda faço isso com prazer
      Administro um storage engine chamado TidesDB, e mesmo com dor nas costas continuo porque gosto
    • Se você cria um projeto open source popular para ganhar dinheiro, então não entendeu de verdade o espírito do open source
    • Participo de software livre há quase 30 anos, e a experiência de trabalhar com a comunidade foi muito gratificante
      Isso é subjetivo, claro, mas definitivamente pode ser algo prazeroso

  • Migrei com sucesso da MinIO para o Ceph
    Também testei SeaweedFS, mas ao analisar bugs com a ajuda do Claude, percebi que a estrutura do código era uma bagunça
    SeaweedFS nunca deveria ser usado além de testes. O risco de perda de dados é grande

    • O SeaweedFS é um projeto antigo, então talvez você só tenha visto traços de uma base de código legada
    • Ceph é o OG do object storage
      Houve várias tentativas de substituí-lo, mas no fim o Ceph é quem resolve melhor a complexidade do problema

  • Recentemente estou migrando da MinIO para o Ceph
    Montei um cluster Ceph de 3 servidores com cephadm e estou replicando 120 TB de dados a 420 MB/s
    O Ceph é mais complexo que a MinIO, mas tem excelente escalabilidade e é estável
    É uma pena que o console da MinIO tenha desaparecido
    Escolhi Ceph porque o Elasticsearch não gosta dos snapshots S3 do Garage

    • O Ceph é complexo, mas a camada de consenso é muito sólida
      Só é preciso tomar cuidado para que os discos dos nós não encham

  • É impressionante como tanta gente ainda está testando às pressas alternativas não comprovadas em produção
    O verdadeiro risco da dependência de infraestrutura não é código fechado, e sim o custo de mudança
    Mesmo com compatibilidade S3, migrações reais levam de semanas a meses por causa de diferenças sutis
    Fico curioso para saber quantos usuários da MinIO realmente documentaram um plano de migração

  • AIStore foi mencionado como alternativa à MinIO
    Além dele, há várias outras alternativas open source:
    Garage, RustFS, SeaweedFS, Supabase Storage, Scality Cloudserver, Ceph

    • Sou o autor do Filestash
      Ele oferece um gateway S3 e faz proxy de chamadas S3 para SFTP, FTP, NFS, SMB, IPFS, Dropbox, Google Drive etc.
      É totalmente stateless e pode se conectar a diversos backends
    • A RustFS tem muitos recursos e até permite gerenciamento de chaves próprio, mas ainda está em desenvolvimento
      Já existe no código uma preparação para futura mudança de licença
      O Ceph é o mais parecido com o S3 em funcionalidades, mas sua configuração é complexa e ele é sensível à latência
      O Garage é bom para armazenamento simples, mas não tem recursos avançados do S3, como ACLs sofisticadas ou restrições por caminho
      O clustering é amigável a WAN, mas não exige configuração por rack como o Ceph
    • Além da MinIO, já usei Garage e Ceph, mas preciso de um sistema de arquivos S3 simples para testes locais
      Ainda não parece existir uma alternativa realmente simples para isso
    • Uso SeaweedFS em uma única máquina como armazenamento compatível com S3
      Ele carece de recursos de administração, mas, em termos de integridade dos dados, confio mais no Ceph
      O Ceph parece ter sido feito por gente que realmente entende muito bem sistemas distribuídos
    • Adicionei a lista de alternativas acima ao repositório da MinIO em um Pull Request
      Link do PR

  • Se você olhar o thread anterior no HN, já dava para perceber que a MinIO havia entrado em modo de manutenção
    Desde então, a mudança para código fechado já estava praticamente anunciada

    • Mas modo de manutenção e “não é mais mantido” são coisas diferentes

  • A MinIO já tinha pouca transparência e estava distante do espírito open source, apagando issues críticas ou bloqueando comentários
    Por isso, assim que entrou em modo de manutenção, migrei para Garage
    Estou preparando um PR, mas ainda não o enviei

    • Projetos assim exigem conhecimento técnico avançado, então não vejo motivo para lidar com usuários gratuitos
      A maioria dos projetos open source sérios recebe apoio da indústria, e é difícil para um desenvolvedor web comum contribuir

  • Recomendo fazer um fork e guardar localmente caso o repositório da MinIO venha a ser apagado
    Forks de repositórios públicos no GitHub permanecem se o original for apagado, mas desaparecem se ele virar privado
    Algo parecido aconteceu com a gem prawn_plus no ecossistema Ruby
    Veja a documentação da política de forks do GitHub
    Para quem usava a MinIO só em testes locais, isso pode virar uma armadilha que vai se fechando aos poucos

  • Se você opera soluções de observabilidade (Observability) que exigem object storage, como Thanos, Loki, Mimir e Tempo
    talvez valha considerar VictoriaMetrics, VictoriaLogs e VictoriaTraces no lugar
    Elas são baseadas em block storage, escalam até a faixa de petabytes e oferecem alto desempenho e disponibilidade sem necessidade de gerenciamento manual