Suporte Técnico
Documentação
Entrar
Entre em contato conosco
Vá direto para um resumo gerado por IA desta postagem do blog 
Em 13 de fevereiro de 2026, a MinIO Inc. arquivou a comunidade minio repositório. O projeto ultrapassou 59.000 estrelas e mais de um bilhão de downloads do Docker. A base instalada abrange armazenamento de objetos no Kubernetes, repositórios de artefatos de CI/CD, registros de modelos de ML e data lakes locais. Tudo isso agora é executado em uma base de código que não recebe mais correções de segurança do upstream.
Para as equipes que optaram pelo MinIO para executar armazenamento de objetos compatível com S3 nos servidores que gerenciam, a questão prática é: onde encontrar suporte contínuo e manutenção de segurança para o MinIO, agora que o suporte do projeto original não é mais oferecido? Esta publicação explica o que mudou, quais são as opções viáveis e como o Suporte de Ciclo de Vida Ilimitado da TuxCare se encaixa nesse contexto.
O que mudou e quando
A mudança ocorreu em etapas ao longo de cerca de quinze meses.
No início de 2025, a MinIO Inc. removeu a maioria dos recursos administrativos do console web da edição comunitária, deixando apenas um navegador de objetos básico. Os recursos completos de gerenciamento foram transferidos para o produto comercial da empresa. As versões binárias pré-compiladas foram gradualmente descontinuadas durante o mesmo período; a edição comunitária passou a ser disponibilizada apenas como código-fonte.
Em 3 de dezembro de 2025, a empresa colocou o repositório da comunidade no modo de manutenção. O desenvolvimento de novos recursos foi suspenso, e as correções de segurança passaram a ser tratadas caso a caso, em vez de seguirem um cronograma definido.
Em 13 de fevereiro de 2026, o repositório foi arquivado no GitHub. Agora ele está em modo somente leitura: não há novos commits, nem novas solicitações de pull, nem novas correções de segurança da MinIO Inc. no código-fonte da comunidade. O suporte oficial do MinIO passou a ser inteiramente fornecido pelo AIStor, o sucessor comercial.
Várias vulnerabilidades (CVEs) já foram divulgadas em relação à última versão da comunidade, incluindo CVE-2026-39414, CVE-2026-34204, GHSA-9c4q-hq6p-c237 e GHSA-hv4r-mvr4-25vw. A MinIO Inc. disponibilizou correções para algumas dessas vulnerabilidades no AIStor, mas nenhum patch está chegando à base de código arquivada da comunidade na qual a base instalada existente está sendo executada. Para equipes que desejam manter sua implantação atual, essa é uma clara lacuna no suporte da MinIO.
Por que isso é importante para as operadoras
Há duas pressões que se somam para qualquer equipe que utilize o MinIO em produção.
O primeiro é a conformidade. PCI DSS, HIPAA, SOC 2 e FedRAMP impõem prazos de correção para vulnerabilidades conhecidas — normalmente 30 dias para constatações de alta gravidade, às vezes menos. Uma política “caso a caso” já era um desafio para esses prazos. Um repositório arquivado, sem correções adicionais, é inviável. As constatações de auditoria começam a se acumular no momento em que um novo CVE é registrado e o prazo começa a correr.
O segundo é a evolução do risco. Cada nova vulnerabilidade CVE divulgada após o último lançamento da comunidade torna a posição operacional mais difícil de defender internamente. As equipes de segurança elevam o nível de alerta. Os registros de risco aumentam. A inércia tem seu próprio prazo, determinado pela próxima auditoria que vier à tona.
As opções em jogo
Atualmente, os operadores que utilizam o MinIO têm quatro opções viáveis.
| Opção | Custo | O que é necessário | Compromisso |
|---|---|---|---|
| Continue com a versão arquivada | $0 | Nada | A exposição a vulnerabilidades CVE aumenta; isso não é viável na maioria dos regimes de conformidade |
| Migrar para o AIStor | Estimado em cerca de US$ 96 mil/ano para ≤400 TiB utilizáveis + custos de migração | Migração de produtos, novos licenças, reciclagem profissional | Produto diferente, modelo operacional diferente |
| Migrar para uma alternativa de software de código aberto | Tempo de engenharia | Transferência de dados, validação da compatibilidade com o S3, recertificação | Projeto de grande porte; não há alternativa que consista em uma substituição direta |
| Inscreva-se em um programa de manutenção de terceiros | Taxa de assinatura | Continue executando o MinIO já instalado | Depende do escopo e do modelo de execução do programa |
Entre as alternativas de código aberto que merecem ser consideradas estão o SeaweedFS, o Garage, o RustFS e o Ceph RGW. Cada uma delas é um projeto concreto, com mantenedores ativos e uma arquitetura diferente da do MinIO. Nenhuma delas é um substituto direto.
A quarta opção — suporte ao MinIO por terceiros — abrange programas que criam um fork do código-fonte da comunidade e continuam a aplicar correções nele. Seu escopo, formato de entrega e compromissos variam. O Endless Lifecycle Support (ELS) da TuxCare para o MinIO é um desses programas. O restante deste post explica o que ele oferece e como se diferencia das alternativas.
O que o ELS para MinIO oferece
O suporte de ciclo de vida ilimitado da TuxCare para o MinIO permite que os clientes continuem utilizando a base de código do MinIO que já executam. Os patches são fornecidos como pacotes binários (RPM, DEB e binários Go) que podem ser integrados diretamente em implantações existentes em máquinas virtuais, servidores físicos e no local, sem a necessidade de reestruturar o ambiente de execução.
Cada assinatura inclui:
- Resposta rápida a vulnerabilidades (CVE) com suporte do SLA enquanto o cliente precisar da versão suportada
- Cobertura completa tanto das dependências diretas quanto das transitivas, sem custo adicional
- Atualizações testadas que preservam a compatibilidade com as implantações existentes
- Integração do tipo “plug-and-play” com fluxos de trabalho e pipelines de CI/CD existentes
- Atualizações assinadas e à prova de adulteração provenientes de repositórios hospedados pela TuxCare
- Uma Lista de Materiais de Software (SBOM) é fornecida junto com cada versão atualizada. Como o MinIO é um binário em Go com dependências integradas, a SBOM oferece aos operadores e auditores um manifesto único e oficial do que realmente está presente em cada versão.
- Contexto do Vulnerability Exploitability eXchange (VEX) que mostra quais CVEs na SBOM já foram corrigidos, para que as equipes de segurança possam concentrar sua atenção nas áreas onde ainda é necessário agir
- Suporte especializado 24 horas por dia, 7 dias por semana, abrangendo triagem de CVEs, solicitações de patches personalizados e solução de problemas
Os patches são de responsabilidade dos engenheiros da TuxCare e são lançados em um ritmo garantido por um SLA. O cliente continua executando a base de código que validou, com o suporte ao MinIO ficando a cargo de um fornecedor que oferece suporte comercial ao trabalho.
Como o ELS se diferencia de outras opções de suporte ao MinIO
Três características definem a forma como a ELS aborda a manutenção do MinIO.
- O primeiro é o modelo de distribuição. O ELS é fornecido como pacotes binários. Programas de manutenção alternativos são fornecidos apenas como imagens de contêineres reforçadas, o que é adequado para ambientes nativos do Kubernetes, mas não se adapta a implantações que executam o MinIO em VMs, bare metal ou no local. Um cliente que execute o MinIO fora de contêineres não pode adotar uma solução exclusivamente baseada em contêineres sem reprojetar a implantação.
- O segundo aspecto é o escopo da cobertura. O ELS se compromete a fazer o backport de correções tanto para dependências diretas quanto transitivas como parte da assinatura padrão. O MinIO inclui uma árvore extensa de dependências em Go, e os CVEs relacionados a essas dependências fornecidas pelo fornecedor frequentemente exigem backports não triviais. Esse trabalho faz parte do compromisso padrão do ELS, não sendo um item com custo adicional.
- O terceiro é o compromisso com a entrega. As correções são disponibilizadas em uma frequência publicada e respaldada por um SLA, com tempos de resposta vinculados ao nível de gravidade. Estruturas de conformidade como PCI DSS, HIPAA, SOC 2 e FedRAMP estabelecem prazos rígidos para correção, e um cronograma de entrega previsível é o que permite que os operadores os cumpram.
Essas características são as mais importantes para os operadores que executam o MinIO fora de contêineres, especialmente quando enfrentam pressões relacionadas à conformidade.
O que fazer a seguir
Se você estiver utilizando o MinIO em produção e precisar de suporte contínuo ao MinIO além do arquivamento do upstream, o Suporte de Ciclo de Vida Ilimitado da TuxCare já está disponível.
Saiba mais ou entre em contato com nossa equipe para discutir os requisitos do seu ambiente pelo e-mail: https://tuxcare.com/endless-lifecycle-support/minio-eol-support/.
