Alternativas auto-hospedadas para S3 em 2026 (RustFS, Garage, SeaweedFS, Ceph)
Escolhendo S3 auto-hospedado após o MinIO
O Amazon S3 tornou-se a API de facto para armazenamento de objetos. Após o repositório open source do MinIO ter sido arquivado em abril de 2026, sete alternativas credíveis de auto-hospedagem permanecem.
Estas opções não são intercambiáveis. Algumas são motores completos de armazenamento de objetos que possuem o seu próprio layout de dados; outras são gateways finos que expõem ficheiros que você já possui. Essa divisão — entre um armazenamento nativo e um gateway baseado em sistema de ficheiros — decide mais sobre backups, recuperação e migrações do que qualquer lista de funcionalidades.
Este artigo compara RustFS, Garage, SeaweedFS, Ceph RGW, VersityGW, S3Proxy e rclone. Cada secção cobre o modelo de armazenamento, a cobertura de funcionalidades S3, onde o projeto se encaixa e a limitação que geralmente decide a escolha. Um guia de decisão para implantações em servidor único e multi-servidor fecha o artigo.
Para uma visão mais ampla — incluindo armazenamento de objetos, bancos de dados, pesquisa e camadas de dados nativas de IA — veja Infraestrutura de Dados para Sistemas de IA.
Comparação de Armazenamento S3 Auto-hospedado
A pergunta mais importante é se você precisa de um object store distribuído ou de uma interface S3 à frente de um armazenamento que já existe.
| Software | Modelo de armazenamento | Distribuído | Compatibilidade S3 | Ficheiros planos no disco | Complexidade | Melhor uso |
|---|---|---|---|---|---|---|
| RustFS | Object store nativo | Sim | Alta, subconjunto testado | Não | Baixa a média | Substituição geral do MinIO |
| Garage | Object store nativo | Sim | Boa, API mais restrita | Não | Baixa a média | Pequenos clusters distribuídos |
| SeaweedFS | Armazenamento distribuído de blobs e ficheiros | Sim | Alta | Não | Média | Contagens enormes de ficheiros e armazenamento misto |
| Ceph RGW | Gateway de objetos Ceph | Sim | Alta | Não | Alta | Grande infraestrutura de armazenamento |
| VersityGW | Gateway S3 sobre POSIX | Dependente do backend | Boa | Sim | Baixa | S3 sobre ficheiros normais |
| S3Proxy | Camada de tradução S3 | Dependente do backend | Moderada | Sim com filesystem-nio2 | Média | Gateway e tradução de protocolos |
| rclone serve s3 | Gateway S3 | Dependente do backend | Básica, experimental | Sim com backend local | Muito baixa | Implantações simples e leves |
O RustFS é a substituição direta mais próxima para uma implantação convencional do MinIO. O Garage adapta-se a pequenos clusters distribuídos. O SeaweedFS e o Ceph resolvem problemas de armazenamento mais amplos. O VersityGW pode expor um sistema de ficheiros POSIX existente através do S3, mantendo os payloads de objetos como ficheiros ordinários. Para uma matriz de funcionalidades entre Garage, MinIO e AWS S3, veja Garage vs MinIO vs AWS S3.
Dois Tipos Diferentes de Armazenamento S3
Um object store nativo possui o seu layout de armazenamento:
RustFS, Garage, Ceph RGW e SeaweedFS pertencem a esta família. Os ficheiros visíveis nos discos subjacentes são detalhes de implementação, e as aplicações não devem manipulá-los diretamente.
Um gateway S3 baseado em sistema de ficheiros tem uma relação diferente com o armazenamento:
Com software como o VersityGW, o sistema de ficheiros pode permanecer a representação autoritativa. Um objeto como:
s3://archive/documents/2026/report.pdf
pode corresponder diretamente a:
/storage/archive/documents/2026/report.pdf
RustFS: A Substituição Mais Próxima do MinIO
O RustFS é um sistema de armazenamento de objetos distribuído escrito em Rust e lançado sob a licença Apache-2.0. Ele fornece um modelo operacional orientado a S3, familiar para utilizadores do MinIO, o que o torna o primeiro projeto a avaliar ao substituir o MinIO.
A sua implementação S3 atual cobre as operações que a maioria das aplicações espera: buckets, objetos, uploads multipart, pedidos condicionalmente, metadados de objetos, tags, versionamento, gestão de ciclo de vida, bloqueio de objetos, URLs presignadas, políticas de bucket, CORS, notificações, configuração de replicação e encriptação server-side.
O RustFS publica uma matriz de compatibilidade S3 que é um subconjunto testado, não uma afirmação de cobertura completa do Amazon S3. O snapshot verificado contra o commit 1e6f5f1e em 9 de agosto de 2026 lista 455 testes padrão implementados, 5 testes de comportamento de ciclo de vida, 17 testes padrão não implementados e 270 casos excluídos que não bloqueiam o portão de compatibilidade. As listas executáveis em scripts/s3-tests são a fonte de verdade quando essas contagens mudarem.
Onde o RustFS se encaixa
O RustFS é um candidato quando uma aplicação espera um object store S3 apropriado.
Usos típicos incluem armazenamento de objetos para aplicações, repositórios de backup, armazenamento de mídia, artefatos de IA e pipelines de dados, infraestrutura S3 interna, workloads de Kubernetes e substituição de endpoints MinIO existentes.
Funciona com AWS SDKs e clientes S3 comuns. As aplicações normalmente precisam de um endpoint personalizado, credenciais, configurações de região onde necessário e endereçamento por caminho (path-style addressing).
A limitação importante
O RustFS possui a representação de armazenamento. Os ficheiros abaixo do seu diretório de dados são internos do RustFS.
Isso torna o RustFS a resposta errada quando o requisito é que cada objeto S3 permaneça um ficheiro ordinário que você possa inspecionar, copiar, rsync ou recuperar sem o software de armazenamento de objetos. Esse requisito seleciona um gateway baseado em sistema de ficheiros.
Garage: S3 Distribuído Sem a Complexidade de Escala do Ceph
O Garage é um object store distribuído compatível com S3 para instalações auto-hospedadas pequenas e médias. A Deuxfleurs desenvolve-o sob a licença AGPL v3 e tem-no em produção desde as suas primeiras releases em 2020.
O Garage é construído para funcionar em vários servidores comuns, incluindo servidores em diferentes locais físicos. A replicação é parte do design.
O Garage é atrativo quando você tem três servidores pequenos em vez de um rack de hardware de armazenamento dedicado. Um caminho de configuração funcional, do Docker ao layout do cluster, replicação e TLS via um proxy reverso, está no quickstart do Garage.
Onde o Garage se encaixa
O Garage faz sentido para homelabs, pequenas plataformas de hospedagem, servidores geograficamente distribuídos, backups replicados e clusters onde o Ceph seria excessivo.
O seu escopo é mais restrito que o AWS S3. A tabela de compatibilidade do Garage deixa de fora políticas de bucket, ACLs e versionamento de bucket. Escolha o Garage em vez do RustFS quando a replicação leve multi-nó for o requisito principal. Escolha o RustFS quando um comportamento S3 mais amplo e a compatibilidade de aplicações semelhante ao MinIO forem mais importantes.
SeaweedFS: Mais do que um Object Store
O SeaweedFS começou armazenando enormes quantidades de ficheiros eficientemente. Agora é uma plataforma de armazenamento distribuído que expõe S3, um sistema de ficheiros FUSE, WebDAV, SFTP e HDFS. O SeaweedFS 4.48 foi lançado em 28 de setembro de 2026.
Os servidores de volume empacotam blobs em ficheiros de volume append-only. Os masters rastreiam volumes em vez de ficheiros individuais. Um filer fornece semânticas de sistema de ficheiros hierárquico. O design alvo é workloads com milhões ou bilhões de objetos relativamente pequenos.
Suporte S3
O SeaweedFS documenta versionamento, bloqueio de objetos, regras de ciclo de vida, tagging, CORS, checksums, URLs presignadas, uploads multipart, políticas de bucket, IAM, STS e vários modos de encriptação server-side.
O mesmo cluster pode servir buckets de tabela S3 e um catálogo REST embutido do Iceberg, permitindo que engines como Spark, Trino, DuckDB e similares usem tabelas Iceberg sem um Hive Metastore ou Glue separado. O exemplo de S3 de comando único do projeto escuta na porta 8333.
Onde o SeaweedFS se encaixa
Considere o SeaweedFS para web crawlers e arquivos, repositórios de imagens e documentos, bilhões de objetos pequenos, data lakes, workloads mistos de S3 e sistema de ficheiros, e armazenamento que cresce através da adição de servidores de volume.
Há mais componentes a entender do que numa instalação direta do RustFS. O SeaweedFS pode fornecer semânticas de sistema de ficheiros através do seu filer e montagem FUSE, mas os objetos são armazenados dentro do seu formato de volume. Ele não satisfaz o requisito de que cada objeto S3 permaneça um ficheiro ordinário independente no sistema de ficheiros do host.
Ceph RGW: A Opção de Escala de Infraestrutura
O Ceph é mais amplo do que o armazenamento S3. Um cluster pode fornecer dispositivos de bloco através do RBD, um sistema de ficheiros através do CephFS e armazenamento de objetos através do RADOS Gateway (RGW). O RGW apresenta uma API compatível com S3 suportada pelo RADOS.
O Ceph suporta replicação, codificação de erro, domínios de falha, múltiplos gateways, implantações multi-sítio, políticas de acesso e ferramentas de gestão de cluster.
Onde o Ceph se encaixa
O Ceph faz sentido quando o armazenamento de objetos é uma parte de uma plataforma de armazenamento maior: volumes persistentes de Kubernetes, discos de máquinas virtuais, sistemas de ficheiros partilhados, repositórios S3 grandes e clusters que precisam de domínios de falha explícitos.
Para um servidor único com vários terabytes, instalar o Ceph apenas para obter um endpoint S3 é difícil de justificar. Se você já opera Ceph, o RGW é a escolha óbvia de S3. Se não, o RustFS ou o Garage atinge um armazenamento de objetos útil com menos mecanismos.
VersityGW: S3 Sobre Ficheiros Ordinários
O VersityGW é a opção a avaliar quando o próprio sistema de ficheiros importa. É um gateway S3 licenciado Apache-2.0 que pode expor sistemas de ficheiros POSIX, ScoutFS, Azure Blob Storage, outros serviços S3 e backends personalizados.
O seu backend POSIX mapeia buckets e objetos S3 para diretórios e ficheiros. Por exemplo:
s3://website-assets/images/logo.png
mapeia para um caminho como:
/storage/website-assets/images/logo.png
O payload do logo.png permanece um ficheiro normal.
Por que ficheiros planos são úteis
Você pode inspecionar o armazenamento com ferramentas Unix comuns:
find /storage -type f
du -sh /storage/*
Você pode ler um objeto sem o servidor S3:
cat /storage/archive/2026/source.html
Ferramentas convencionais de backup de sistema de ficheiros aplicam-se diretamente: rsync, restic, borg, tar e zfs send. Se o software do gateway desaparecer, os payloads são ainda ficheiros numa árvore de diretórios.
Metadados S3 num backend POSIX
Os metadados S3 não cabem num ficheiro POSIX por si só. O VersityGW armazena-os em atributos estendidos por omissão. Desde março de 2026, os metadados do objeto são um único xattr user.metadata contendo JSON, porque um xattr por chave atingia limites de comprimento de chave no sistema de ficheiros. O comando versitygw utils convert-xattr-metadata reescreve os atributos por chave mais antigos. As leituras ainda caem de volta para o layout antigo quando o user.metadata está ausente.
Sistemas de ficheiros sem xattrs podem usar --sidecar (ou VGW_META_SIDECAR) para manter metadados numa árvore de diretórios separada. O projeto marca sidecar e --nometa como menos testados do que xattrs. --nometa desativa o armazenamento de metadados e visa hospedagem somente-leitura de um conjunto de dados que já existe; políticas de bucket e ACLs são metadados, por isso estão indisponíveis nesse modo.
Versões de objetos podem viver num diretório separado. O exemplo POSIX do projeto passa --versioning-dir para versões mais antigas, enquanto o payload atual permanece no seu caminho natural.
Alterar um ficheiro atrás do gateway pode deixar os metadados S3, incluindo ETags, inconsistentes com os novos bytes. Um modelo de operação viável é:
Application access:
Read through S3
Write through S3
Administrator access:
Read the filesystem directly
Inspect the filesystem directly
Back up the filesystem directly
Avoid modifying objects behind the gateway
O VersityGW 1.8.0, já a versão para a qual um lançamento de driver COSI em setembro de 2026 almejava, adiciona um serviço IAM independente (versitygw iam), STS AssumeRoleWithWebIdentity e condições de política IAM.
S3Proxy: Uma Camada de Tradução Geral
O S3Proxy implementa a API S3 e traduz pedidos para vários backends: ficheiros locais, Azure Blob Storage, Google Cloud Storage, OpenStack Swift, SFTP e outros serviços S3. Requer Java 17 ou superior.
O provedor em disco recomendado é filesystem-nio2. O provedor filesystem mais antigo está deprecado. As chaves de objeto tornam-se caminhos de sistema de ficheiros, e os metadados usam atributos estendidos de utilizador, de modo que os payloads permanecem ficheiros ordinários.
O backend de sistema de ficheiros recusa versionamento de objetos e encriptação server-side. O versionamento permanece não suportado (supportsVersioning() é falso, e esses pedidos permanecem HTTP 501) porque um layout de versionamento escrito num disco real se tornaria um formato que o projeto teria de manter. A encriptação server-side é recusada pela mesma classe de razão: reportar AES256 sobre um ficheiro em texto claro que alguém pode ler seria uma afirmação falsa. O backend em memória transient-nio2 implementa ambos, e os dados morrem com o processo. O README do projeto também lista políticas de bucket, tagging de objetos e ACLs, exceto private e public-read, como não suportadas.
O S3Proxy é a ferramenta quando você precisa dessa tradução entre backends. Para um gateway S3-para-POSIX direto, o VersityGW tem a superfície menor.
rclone serve s3: Leve mas Experimental
O rclone serve s3 expõe um backend rclone através de uma API compatível com S3. A documentação ainda rotula o comando como experimental.
Para um sistema de ficheiros local:
rclone serve s3 \
--addr :9000 \
--auth-key ACCESS_KEY,SECRET_KEY \
local:/srv/s3
Sem --addr, o servidor liga a 127.0.0.1:8080. --auth-key habilita Signature Version 4. Uploads multipart são escritos em ordem de número de parte para um objeto temporário e renomeados para o local ao completar, de modo que um upload falhado não substitui um objeto existente.
Objetos escritos através de um backend local tornam-se ficheiros sob esse caminho. O mesmo comando pode ficar à frente de outros remotes rclone. É uma escolha razoável para ferramentas internas, um laboratório ou um salto de migração temporário. É uma camada S3 permanente fraca para muitas aplicações de produção não relacionadas.
E o MinIO?
O repositório GitHub do MinIO foi arquivado em 13 de fevereiro de 2026, brevemente desarquivado e arquivado novamente em 25 de abril de 2026. É somente-leitura. O aviso do repositório aponta os operadores para o AIStor, a distribuição comercial do MinIO, e afirma que a edição comunitária é apenas código-fonte (source-only).
Uma implantação existente do MinIO pode continuar a funcionar, particularmente quando está isolada e o seu comportamento já é compreendido. A linha do tempo completa, o risco operacional e um plano de migração faseado estão em MinIO CE em 2026.
Para o comportamento S3 do sistema que você pode estar a deixar, MinIO como alternativa ao AWS S3 documenta como o MinIO se mapeia para o S3. A folha de dicas da linha de comandos do MinIO é o companheiro de auditoria para um cluster que ainda está ativo. Para uma nova instalação, uma alternativa ativamente mantida é a predefinição.
Ficheiros Planos vs Armazenamento de Objetos Nativo
Use RustFS, Garage, SeaweedFS ou Ceph quando o object store deve controlar durabilidade, metadados, distribuição e layout. Isso compra semânticas S3 mais ricas, replicação ou codificação de erro, escalonamento horizontal e versionamento onde o projeto o implementa. O custo é a dependência da representação em disco do motor.
Use VersityGW, S3Proxy ou rclone quando um sistema de ficheiros existente deve permanecer autoritativo. Isso compra ficheiros planos recuperáveis, backups convencionais, inspeção direta e compatibilidade com ZFS, XFS, ext4 e NFS. A durabilidade distribuída então tem de vir do sistema de ficheiros ou da matriz de armazenamento, não do processo S3. Numa servidor único ou num NAS, essa troca é muitas vezes a correta.
Escolhendo o Servidor S3 Auto-hospedado Certo
Para um servidor único que deve se assemelhar ao MinIO, comece com o RustFS.
Para três ou mais servidores modestos onde a replicação é o requisito principal, e a aplicação pode viver sem políticas de bucket e versionamento, escolha o Garage.
Para enormes quantidades de objetos pequenos, acesso misto a sistema de ficheiros ou um workload de data lake que pode crescer para tabelas Iceberg, considere o SeaweedFS.
Quando o mesmo cluster também deve fornecer dispositivos de bloco e um sistema de ficheiros distribuído, escolha o Ceph RGW.
Quando o requisito é especificamente uma API S3 sobre ficheiros ordinários — um NAS, um arquivo, um repositório de documentos, um crawler ou um alvo de backup — comece com o VersityGW.
Quando o trabalho é traduzir S3 para Azure, GCS, Swift, SFTP ou outro serviço S3, use o S3Proxy.
Quando a implantação é pequena, temporária e pode tolerar um servidor experimental, rclone serve s3 pode ser suficiente.
Arquitetura Recomendada para um Servidor de Armazenamento Único
Se as aplicações devem alcançar os dados apenas através do S3, o RustFS possui a camada de objeto e o sistema de ficheiros é um detalhe de implementação:
Se os próprios ficheiros devem sobreviver ao gateway, mantenha os dados numa árvore POSIX:
No segundo design, a redundância é um espelho ZFS, RAID, snapshots, replicação de sistema de ficheiros ou uma ferramenta de backup convencional. O serviço S3 pode ser substituído sem reescrever o formato de dados.
Pensamentos Finais
O S3 auto-hospedado mantido ainda existe após o repositório público do MinIO ter ficado somente-leitura. A escolha que importa é se o S3 possui os bytes ou apenas fica à frente de ficheiros que já existem. Toda a comparação acima segue dessa resposta.
