Self-Hosted Alternatives to S3 in 2026 (RustFS, Garage, SeaweedFS, Ceph)

Wybór self-hostowanego S3 po MinIO

Page content

Amazon S3 stał się standardem de facto w zakresie interfejsów API do przechowywania obiektów. Po zarchiwizowaniu otwartego repozytorium MinIO w kwietniu 2026 roku pozostaje siedem wiarygodnych, samodzielnie hostowanych alternatyw.

Opcje te nie są ze sobą zamienne. Niektóre to w pełni funkcjonalne silniki przechowywania obiektów, które samodzielnie zarządzają strukturą danych; inne to cienkie bramki (gateway), które udostępniają pliki, które już posiadasz. To rozróżnienie — natywna pamięć obiektów versus bramka oparta na systemie plików — decyduje o zapasach, odzyskiwaniu danych i migracjach bardziej niż jakakolwiek lista funkcji.

Samodzielnie hostowane przechowywanie S3: obiekty i bramki systemów plików za jednym API

Ten artykuł porównuje RustFS, Garage, SeaweedFS, Ceph RGW, VersityGW, S3Proxy i rclone. Każda sekcja omawia model przechowywania, zakres wsparcia funkcji S3, zastosowanie projektu oraz ograniczenie, które zazwyczaj decyduje o wyborze. Artykuł zamyka przewodnik decyzyjny dla wdrożeń na pojedynczym i wielu serwerach.

W celu ujęcia szerszego kontekstu — przechowywanie obiektów, bazy danych, wyszukiwanie i natywne dla AI warstwy danych — zobacz Infrastruktura danych dla systemów AI.

Porównanie samodzielnie hostowanego przechowywania S3

Najważniejszym pytaniem jest to, czy potrzebujesz rozproszonego magazynu obiektów, czy interfejsu S3 przed istniejącym już systemem przechowywania.

Oprogramowanie	Model przechowywania	Rozproszony	Zgodność z S3	Zwykłe pliki na dysku	Złożoność	Najlepsze zastosowanie
RustFS	Natywny magazyn obiektów	Tak	Wysoka, testowany podzbiór	Nie	Niska do średniej	Ogólny zamiennik MinIO
Garage	Natywny magazyn obiektów	Tak	Dobra, węższe API	Nie	Niska do średniej	Małe rozproszone klastry
SeaweedFS	Rozproszony magazyn blobów i plików	Tak	Wysoka	Nie	Średnia	Ogromna liczba plików i mieszane przechowywanie
Ceph RGW	Bramka obiektów Ceph	Tak	Wysoka	Nie	Wysoka	Duża infrastruktura przechowująca
VersityGW	Bramka S3 nad POSIX	Zależy od backendu	Dobra	Tak	Niska	S3 nad zwykłymi plikami
S3Proxy	Warstwa translacji S3	Zależy od backendu	Umiarkowana	Tak z filesystem-nio2	Średnia	Bramka i translacja protokołu
rclone serve s3	Bramka S3	Zależy od backendu	Podstawowa, eksperymentalna	Tak z backendem lokalnym	Bardzo niska	Proste i lekkie wdrożenia

RustFS jest najbliższym bezpośrednim zamiennikiem konwencjonalnego wdrożenia MinIO. Garage nadaje się do małych rozproszonych klastrów. SeaweedFS i Ceph rozwiązują szersze problemy przechowywania. VersityGW może udostępniać istniejący system plików POSIX przez S3, pozostawiając obiekty jako zwykłe pliki. W celu macierzy funkcji Garage, MinIO i AWS S3 zobacz Garage vs MinIO vs AWS S3.

Dwa różne typy przechowywania S3

Natywny magazyn obiektów włada swoją strukturą przechowywania:

flowchart TD A[Aplikacja] -->|API S3| B[Magazyn obiektów] B --> C[Wewnętrzne metadane] B --> D[Chunki lub układ obiektów] C --> E[Dyski] D --> E

RustFS, Garage, Ceph RGW i SeaweedFS należą do tej rodziny. Pliki widoczne na dyskach bazowych to szczegóły implementacyjne, a aplikacje nie powinny manipulować nimi bezpośrednio.

Bramka S3 oparta na systemie plików ma inny związek z przechowywaniem:

flowchart TD A[Aplikacja] -->|API S3| B[Bramka S3] B --> C[System plików POSIX] C --> D[przechowisko] D --> E[ścieżka] E --> F[zwykly-plik.dat]

W przypadku oprogramowania takiego jak VersityGW system plików może pozostać wiarygodnym reprezentantem danych. Obiekt taki jak:

s3://archive/documents/2026/report.pdf

może bezpośrednio odpowiadać:

/storage/archive/documents/2026/report.pdf

RustFS: Najbliższy zamiennik MinIO

RustFS to rozproszony system przechowywania obiektów napisany w Rust i wydany na licencji Apache-2.0. Zapewnia model operacyjny orientowany na S3, znany użytkownikom MinIO, co czyni go pierwszym projektem do oceny przy wymianie MinIO.

Jego bieżąca implementacja S3 obejmuje operacje, których oczekują większość aplikacji: przechowiska (buckety), obiekty, wieloczęściowe wgrywanie (multipart uploads), żądania warunkowe, metadane obiektów, tagi, wersjonowanie, zarządzanie cyklem życia, blokadę obiektów, podpisywane URL-e, polityki przechowisk, CORS, powiadomienia, konfigurację replikacji oraz szyfrowanie po stronie serwera.

RustFS publikuje macierz zgodności z S3, która jest testowanym podzbiorem, a nie twierdzeniem o pełnym pokryciu Amazon S3. Zrzut ekranu zweryfikowany względem commita 1e6f5f1e z 9 sierpnia 2026 r. wymienia 455 zaimplementowanych testów standardowych, 5 testów zachowania cyklu życia, 17 niezaimplementowanych testów standardowych i 270 wykluczonych przypadków, które nie blokują bramki zgodności. Wykonywalne listy pod scripts/s3-tests są źródłem prawdy, gdy te liczby się zmieniają.

Gdzie pasuje RustFS

RustFS jest kandydatem, gdy aplikacja oczekuje odpowiedniego magazynu obiektów S3.

Typowe zastosowania obejmują przechowywanie obiektów aplikacji, repozytoria kopii zapasowych, przechowywanie mediów, artefakty AI i pipeline’ów danych, wewnętrzną infrastrukturę S3, obciążenia Kubernetes oraz wymianę istniejących punktów końcowych MinIO.

Działa z SDK AWS i popularnymi klientami S3. Aplikacje zazwyczaj wymagają niestandardowego punktu końcowego, poświadczeń, ustawień regionu (jeśli wymagane) oraz adresowania w stylu ścieżki (path-style).

Ważne ograniczenie

RustFS włada reprezentacją przechowywania. Pliki w katalogu danych są wewnętrznością RustFS.

To sprawia, że RustFS jest błędną odpowiedzią, gdy wymaganie polega na tym, aby każdy obiekt S3 pozostał zwykłym plikiem, który można sprawdzić, skopiować, zsynchronizować za pomocą rsync lub odzyskać bez oprogramowania do przechowywania obiektów. To wymaganie wskazuje na bramkę opartą na systemie plików.

Garage: Rozproszone S3 bez skomplikowania na skalę Ceph

Garage to zgodny z S3 rozproszony magazyn obiektów dla małych i średnich samodzielnie hostowanych instalacji. Firma Deuxfleurs rozwija go na licencji AGPL v3 i wykorzystuje go produkcyjnie od początkowych wydań projektu w 2020 roku.

Garage został zaprojektowany tak, aby działał na kilku zwykłych serwerach, w tym na serwerach w różnych lokalizacjach fizycznych. Replikacja jest częścią projektu.

flowchart LR A[Aplikacje] --> B[Punkt końcowy S3] B --> C[Węzeł Garage 1] B --> D[Węzeł Garage 2] B --> E[Węzeł Garage 3] C <--> D D <--> E E <--> C

Garage jest atrakcyjny, gdy masz trzy małe serwery, a nie szafę z dedykowanym sprzętem do przechowywania. Sprawny ścieżka wdrożenia, od Docker przez układ klastra, replikację, po TLS za pomocą serwera odwrotnego (reverse proxy), znajduje się w Szybkim starcie z Garage.

Gdzie pasuje Garage

Garage ma sens dla laboratoriów domowych (homelabs), małych platform hostingowych, geograficznie rozproszonych serwerów, replikowanych kopii zapasowych i klastrów, w których Ceph byłby nadmierny.

Jego zakres jest węższy niż AWS S3. Tabela zgodności Garage pomija polityki przechowisk, ACL-e i wersjonowanie przechowisk. Wybierz Garage zamiast RustFS, gdy lekka replikacja wielowęzłowa jest głównym wymaganym. Wybierz RustFS, gdy szersze zachowanie S3 i kompatybilność aplikacji typu MinIO są ważniejsze.

SeaweedFS: Więcej niż magazyn obiektów

SeaweedFS zaczął od efektywnego przechowywania ogromnej liczby plików. Jest teraz rozproszoną platformą przechowującą, udostępniającą S3, system plików FUSE, WebDAV, SFTP i HDFS. SeaweedFS 4.48 został wydany 28 września 2026 roku.

Serwery wolumenów pakują bloby w pliki wolumenów tylko z dołączaniem (append-only). Mistrzowie (masters) śledzą wolumeny, a nie poszczególne pliki. Filer zapewnia semantykę hierarchicznego systemu plików. Projekt jest skierowany do obciążeń z milionami lub miliardami stosunkowo małych obiektów.

Wsparcie S3

SeaweedFS dokumentuje wersjonowanie, blokadę obiektów, reguły cyklu życia, tagi, CORS, sumy kontrolne, podpisywane URL-e, wieloczęściowe wgrywanie, polityki przechowisk, IAM, STS oraz kilka trybów szyfrowania po stronie serwera.

Ten sam klastor może obsługiwać tablice przechowisk S3 i wbudowany katalog REST Iceberg, dzięki czemu silniki takie jak Spark, Trino, DuckDB i podobne mogą używać tablic Iceberg bez osobnego Metastore Hive lub Glue. Przykład jednoprowadowy S3 projektu nasłuchuje na porcie 8333.

Gdzie pasuje SeaweedFS

Rozważ SeaweedFS do programów pełzających po sieci (web crawlers) i archiwów, repozytoriów obrazów i dokumentów, miliardów małych obiektów, jezior danych (data lakes), mieszanych obciążeń S3 i systemów plików oraz przechowywania, które rośnie poprzez dodawanie serwerów wolumenów.

Jest więcej komponentów do zrozumienia niż w prostej instalacji RustFS. SeaweedFS może zapewnić semantykę systemu plików przez filer i montowanie FUSE, ale obiekty są przechowywane wewnątrz jego formatu wolumenów. Nie spełnia wymaganie, aby każdy obiekt S3 pozostał niezależnym zwykłym plikiem na systemie plików hosta.

Ceph RGW: Opcja na skalę infrastrukturalną

Ceph jest szerszy niż przechowywanie S3. Klastor może zapewniać urządzenia blokowe przez RBD, system plików przez CephFS i przechowywanie obiektów przez RADOS Gateway (RGW). RGW prezentuje zgodne z S3 API obsługiwane przez RADOS.

flowchart TD A[Aplikacje] -->|S3| B[Ceph RGW] B --> C[RADOS] C --> D[OSD 1] C --> E[OSD 2] C --> F[OSD 3]

Ceph obsługuje replikację, kodowanie korekcyjne, domeny awarii, wiele bramek, wdrożenia wielosiedliskowe, polityki dostępu i narzędzia do zarządzania klastrami.

Gdzie pasuje Ceph

Ceph ma sens, gdy przechowywanie obiektów jest częścią większej platformy przechowywania: wolumeny stałe Kubernetes, dyski maszyn wirtualnych, współdzielone systemy plików, duże repozytoria S3 i klastry, które wymagają jawnych domen awarii.

W przypadku pojedynczego serwera z kilkoma terabajtami instalacja Ceph tylko po to, aby uzyskać punkt końcowy S3, jest trudna do uzasadnienia. Jeśli już operujesz Cephem, RGW jest oczywistym wyborem S3. Jeśli nie, RustFS lub Garage osiąga przydatne przechowywanie obiektów z mniejszą mechaniką.

VersityGW: S3 nad zwykłymi plikami

VersityGW to opcja do oceny, gdy sam system plików ma znaczenie. To zgodna z S3 bramka (gateway) na licencji Apache-2.0, która może udostępniać systemy plików POSIX, ScoutFS, Azure Blob Storage, inne usługi S3 oraz niestandardowe backendy.

Jej backend POSIX mapuje przechowiska i obiekty S3 na katalogi i pliki. Na przykład:

s3://website-assets/images/logo.png

odpowiada ścieżce takiej jak:

/storage/website-assets/images/logo.png

Obciążenie logo.png pozostaje normalnym plikiem.

Dlaczego zwykłe pliki są przydatne

Możesz badać przechowywanie zwykłymi narzędziami Unix:

find /storage -type f
du -sh /storage/*

Możesz odczytać obiekt bez serwera S3:

cat /storage/archive/2026/source.html

Konwencjonalne narzędzia do kopii zapasowych systemu plików działają bezpośrednio: rsync, restic, borg, tar i zfs send. Jeśli oprogramowanie bramki zniknie, obciążenia są nadal plikami w drzewie katalogów.

Metadane S3 na backendzie POSIX

Metadane S3 same w sobie nie mieszczą się w pliku POSIX. VersityGW przechowuje je domyślnie w rozszerzonych atrybutach. Od marca 2026 r. metadane obiektu to pojedynczy xattr user.metadata przechowujący JSON, ponieważ jeden xattr na klucz natrafił na limity długości kluczy systemu plików. Polecenie versitygw utils convert-xattr-metadata przepisuje starsze atrybuty per klucz. Odczyty nadal odwołują się do starego układu, gdy user.metadata jest nieobecne.

Systemy plików bez xattr mogą używać --sidecar (lub VGW_META_SIDECAR), aby utrzymywać metadane w osobnym drzewie katalogów. Projekt oznacza sidecar i --nometa jako mniej testowane niż xattr-y. --nometa dezaktywuje przechowywanie metadanych i jest skierowany do tylko do odczytu hostowania zbioru danych, który już istnieje; polityki przechowisk i ACL-e to metadane, więc są niedostępne w tym trybie.

Wersje obiektów mogą znajdować się w osobnym katalogu. Przykład POSIX projektu przekazuje --versioning-dir dla starszych wersji, podczas gdy bieżące obciążenie pozostaje na jego naturalnej ścieżce.

Zmiana pliku za bramką może zostawić metadane S3, w tym ETag-i, niespójne z nowymi bajtami. Działający model operacyjny to:

Dostęp aplikacji:
    Odczyt przez S3
    Zapis przez S3

Dostęp administratora:
    Odczyt systemu plików bezpośrednio
    Badanie systemu plików bezpośrednio
    Kopia zapasowa systemu plików bezpośrednio
    Unikanie modyfikacji obiektów za bramką

VersityGW 1.8.0, już wersja, na którą celowała wersja sterownika COSI z września 2026 r., dodaje samodzielny serwis IAM (versitygw iam), STS AssumeRoleWithWebIdentity i warunki polityk IAM.

S3Proxy: Ogólna warstwa translacji

S3Proxy implementuje API S3 i tłumaczy żądania na kilka backendów: pliki lokalne, Azure Blob Storage, Google Cloud Storage, OpenStack Swift, SFTP i inne usługi S3. Wymaga Javy 17 lub nowszej.

flowchart TD A[Klient S3] --> B[S3Proxy] B --> C[filesystem-nio2] C --> D[System plików lokalny]

Zalecanym dostawcą na dysku jest filesystem-nio2. Starszy dostawca filesystem jest nieaktualny. Klucze obiektów stają się ścieżkami w systemie plików, a metadane używają rozszerzonych atrybutów użytkownika, dzięki czemu obciążenia pozostają zwykłymi plikami.

Backend systemu plików odmawia wersji obiektów i szyfrowania po stronie serwera. Wersjonowanie pozostaje niewspierane (supportsVersioning() to false, a te żądania pozostają HTTP 501), ponieważ układ wersji zapisany na prawdziwym dysku stałby się formatem, który projekt musiałby podtrzymywać. Szyfrowanie po stronie serwera jest odrzucane z tego samego typu powodu: raportowanie AES256 nad plikiem jawnym, którego ktoś może przeczytać, byłoby fałszywą twierdzeniem. Backend w pamięci transient-nio2 implementuje oba, a dane umierają z procesem. README projektu wymienia również polityki przechowisk, tagowanie obiektów i ACL-e inne niż private i public-read jako niewspierane.

S3Proxy to narzędzie, gdy potrzebujesz tej translacji między backendami. Dla prostej bramki S3-do-POSIX, VersityGW jest mniejszą powierzchnią działania.

rclone serve s3: Lekki, ale eksperymentalny

rclone serve s3 udostępnia backend rclone przez zgodne z S3 API. Dokumentacja nadal oznacza to polecenie jako eksperymentalne.

Dla lokalnego systemu plików:

rclone serve s3 \
  --addr :9000 \
  --auth-key ACCESS_KEY,SECRET_KEY \
  local:/srv/s3

Bez --addr serwer wiąże się z 127.0.0.1:8080. --auth-key włącza Sygnaturę Wersji 4. Wgrywanie wieloczęściowe jest zapisywane w kolejności numerów części do tymczasowego obiektu i przemianowywane w miejsce po zakończeniu, więc nieudane wgrywanie nie zastępuje istniejącego obiektu.

Obiekty zapisane przez backend local stają się plikami pod tą ścieżką. To samo polecenie może stać przed innymi zdalnymi (remotes) rclone. To rozsądny wybór dla wewnętrznego narzędziowania, laboratorium lub tymczasowego przeskoku migracyjnego. To słaba, stała warstwa S3 dla wielu niepowiązanych aplikacji produkcyjnych.

Co z MinIO?

Repozytorium MinIO na GitHub zostało zarchiwizowane 13 lutego 2026 r., krótko odarchiwizowane, a następnie zarchiwizowane ponownie 25 kwietnia 2026 r. Jest tylko do odczytu. Powiadomienie repozytorium kieruje operatorów do AIStor, komercyjnej dystrybucji MinIO, i stwierdza, że edycja społecznościowa jest tylko źródłowa.

Istniejące wdrożenie MinIO może nadal działać, szczególnie gdy jest odizolowane i jego zachowanie jest już rozumiane. Pełna oś czasu, ryzyko operacyjne i fazowy plan migracji znajdują się w MinIO CE w 2026.

Dla zachowania S3 systemu, z którego możesz odejść, MinIO jako alternatywa AWS S3 dokumentuje, jak MinIO mapuje się na S3. Ściągawka z poleceń wiersza poleceń MinIO jest towarzyszem audytowym dla klastra, który jest nadal uruchomiony. Dla nowej instalacji aktywnie utrzymywaną alternatywą jest domyślność.

Zwykłe pliki vs Natywne przechowywanie obiektów

Używaj RustFS, Garage, SeaweedFS lub Ceph, gdy magazyn obiektów powinien kontrolować trwałość, metadane, dystrybucję i układ. To daje bogatszą semantykę S3, replikację lub kodowanie korekcyjne, skalowanie poziome i wersjonowanie tam, gdzie projekt je implementuje. Kosztem jest zależność od reprezentacji na dysku silnika.

Używaj VersityGW, S3Proxy lub rclone, gdy istniejący system plików powinien pozostać wiarygodny. To daje zwykłe, odzyskiwalne pliki, konwencjonalne kopie zapasowe, bezpośrednie badanie i kompatybilność z ZFS, XFS, ext4 i NFS. Rozproszona trwałość musi wtedy pochodzić z systemu plików lub macierzy przechowującej, a nie z procesu S3. Na pojedynczym serwerze lub NAS, ta transakcja jest często tą właściwą.

Wybór właściwego samodzielnie hostowanego serwera S3

Dla pojedynczego serwera, który ma przypominać MinIO, zacznij od RustFS.

Dla trzech lub więcej skromnych serwerów, gdzie replikacja jest głównym wymaganiem, a aplikacja może obejść się bez polityk przechowisk i wersjonowania, wybierz Garage.

Dla ogromnej liczby małych obiektów, mieszanego dostępu do systemu plików lub obciążenia jeziora danych, które może urosnąć do tablic Iceberg, rozważ SeaweedFS.

Gdy ten sam klastor musi również zapewniać urządzenia blokowe i rozproszony system plików, wybierz Ceph RGW.

Gdy wymaganie dotyczy konkretnie API S3 nad zwykłymi plikami — NAS, archiwum, repozytorium dokumentów, programu pełzającego po sieci (crawlera) lub celu kopii zapasowej — zacznij od VersityGW.

Gdy zadaniem jest translacja S3 na Azure, GCS, Swift, SFTP lub inną usługę S3, użyj S3Proxy.

Gdy wdrożenie jest małe, tymczasowe i może tolerować eksperymentalny serwer, rclone serve s3 może wystarczyć.

Zalecana architektura dla pojedynczego serwera przechowującego

Jeśli aplikacje powinny mieć dostęp do danych tylko przez S3, RustFS włada warstwą obiektów, a system plików jest szczegółem implementacji:

flowchart TD A[Aplikacje] -->|S3| B[RustFS] B --> C[Przechowywanie lokalne] C --> D[System plików lub RAID]

Jeśli same pliki muszą przetrwać bramkę, utrzymuj dane w drzewie POSIX:

flowchart TD A[Aplikacje] -->|S3| B[VersityGW] B --> C[System plików POSIX] C --> D[ext4, XFS, ZFS, NFS] D --> E[Zwykłe pliki]

W drugim projekt, redundancja to lustro ZFS, RAID, migawki (snapshoty), replikacja systemu plików lub konwencjonalne narzędzie do kopii zapasowych. Usługa S3 może zostać wymieniona bez przepisywania formatu danych.

Podsumowanie

Utrzymywanym samodzielnie hostowane S3 nadal istnieje po tym, jak publiczne repozytorium MinIO stało się tylko do odczytu. Wybór, który ma znaczenie, polega na tym, czy S3 włada bajtami, czy tylko frontuje pliki, które już istnieją. Każde porównanie powyżej wynika z tej odpowiedzi.