Forem: arash ezazi

MinIO Alternatives (Open Source, On-Prem, Real-World Credible): SeaweedFS, Garage, RustFS, and Ceph RGW (Rook)

arash ezazi — Fri, 26 Dec 2025 10:24:59 +0000

Introduction
Choosing the right tool for your storage layer is one of the most consequential decisions in modern infrastructure. If your data footprint is large—or moving that data is expensive, slow, or operationally risky—it’s often better to pause and validate assumptions early. Rushed storage decisions can create outcomes that are not only costly and time-consuming, but sometimes genuinely hard to reverse. On the other hand, if you have multiple migration paths, you’ve assessed risks realistically, and you have rollback options if one approach fails, then a structured comparison can help you make a more informed decision. The most important principle is simple: do not decide based on feature lists alone. Decide based on your workload, your failure model, and your operational constraints—and confirm with a PoC.
Criteria of This Article
This article focuses on MinIO alternatives that are open source, deployable on-premise, and credible in real-world scenarios rather than just demos or marketing narratives. The options covered are SeaweedFS, Garage, RustFS, and Ceph Object Gateway (RGW) deployed on Kubernetes via Rook.

Option One: SeaweedFS
SeaweedFS is a distributed storage system designed to handle both small and large files, and it is often framed closer to a distributed filesystem plus object gateway approach than a pure “S3-first” product. At a high level, it combines a volume/blob layer with additional services (such as filer and gateways) to support multiple access methods, including S3 and file-oriented interfaces. In practice, SeaweedFS can be a strong fit when your workload is file-heavy or multi-access-pattern and you want architectural flexibility. It is commonly discussed as valuable for very large datasets and for workloads where colder data dominates, such as archives, backups, or large media libraries with low access frequency. The trade-off is that operational complexity can be higher than MinIO depending on how you deploy it, because the system is modular and many workflows are CLI and configuration driven rather than UI-driven. UI maturity is generally weaker than MinIO Console, so if your team prefers UI-first day-2 operations, you should plan for that gap. Authentication and IAM-like expectations are an area where the safest stance is to assume you must validate the exact auth flow you need in your environment, including the behavior of access keys and any OIDC-style integration you intend to rely on. For durability, SeaweedFS is often framed as replication-oriented for hot data, with erasure coding as a strategy you can apply for warm or cold tiers, but that typically requires deliberate lifecycle and tiering design rather than a simple toggle. Performance is also highly workload-dependent; community reports vary, so the only reliable conclusion is to benchmark your own workload with your object sizes, concurrency profile, metadata intensity, and failure scenarios. Overall, SeaweedFS can shine in file-heavy contexts and large-scale datasets, but you should expect less polished UI and more operational design effort than MinIO.

Option Two: Garage
Garage is a lightweight Rust-based object storage system designed with reliability and geo-distributed replication as a core focus. It frequently comes up in self-hosted discussions because it aims to be self-contained and resilient across multiple zones or sites, often on relatively modest hardware, with replication serving as the primary resilience model. The most important constraint to internalize is S3 feature completeness: Garage is unusually explicit about which parts of the S3 API it supports and which are incomplete, which is great for transparency, but it also means you should plan for the possibility that a workflow depending on advanced S3 capabilities may not work as-is. If your environment depends on specific tooling and S3 edge behaviors—such as backup tooling with strict API requirements, lifecycle policies, versioning nuances, or policy/ACL expectations—Garage should be treated as “PoC required” rather than “assume it will be compatible.” In IAM/OIDC terms, Garage is not generally positioned as an integrated IAM/OIDC console-first experience, so if you need external identity integration you will often end up building it around Garage via proxies or gateways. The same minimalism applies to UI expectations; Garage is commonly operated CLI-first, which some teams prefer, but UI-driven operations teams should plan for that operational style. Performance insights are mostly community-driven rather than benchmark-driven, and one repeatedly practical lesson is that metadata performance matters disproportionately; if metadata lands on low-IOPS storage, behavior can degrade in unpleasant ways, while placing metadata on SSD/high-IOPS storage can significantly improve stability and throughput. In summary, Garage can be a strong fit for multi-site and geo-distributed deployments when you value resilience and operational simplicity, but it demands careful validation of S3 completeness and disciplined storage choices for metadata.

*Option Three: RustFS RustFS *
is an open-source, S3-compatible distributed object storage system written in Rust, positioning itself around performance, simplicity, and security. It has attracted significant attention, but like any newer entrant, it should be evaluated with a production mindset that includes a real PoC, monitoring, and an explicit rollback plan. In its own documentation, RustFS presents a high-level architectural framing that distinguishes centralized-metadata and decentralized-metadata approaches and positions itself as decentralized and scalable, often alongside MinIO in that category. RustFS uses the Apache-2.0 license, which can be lower-friction for many organizations compared to copyleft licenses, particularly when internal distribution, embedding, or modifications are considerations. Operationally, one practical advantage RustFS claims over more minimal systems is a management console/dashboard, which can matter a lot for day-2 operations if your team expects visibility and routine actions through a UI. Performance is where RustFS messaging can be attractive, but it must be handled responsibly: project-published throughput figures should be treated as project-reported benchmark claims tied to specific test conditions, not as guaranteed outcomes. The only correct approach is to benchmark your own workload with realistic object distributions, concurrency, network conditions, and actual storage media (NVMe versus HDD, and the real IOPS budget). The overall picture is that RustFS may be appealing if you want an Apache-2.0, performance-oriented S3 store with a stronger UI story than minimal alternatives, but it requires more PoC discipline and version-specific validation to avoid surprises.

*Option Four: Ceph RGW on Kubernetes via Rook Ceph Object Gateway (RGW)
*
is the object storage interface for Ceph, providing an S3-compatible REST API backed by Ceph’s storage cluster. When deployed on Kubernetes via Rook, RGW becomes especially compelling if you already operate Ceph or want a unified storage platform covering block, file, and object under one umbrella. RGW tends to be viewed as “enterprise-like” not because it is simple, but because it sits in a mature and widely deployed ecosystem with deep durability and operational concepts. That maturity comes with real trade-offs: compared to single-purpose object stores, Ceph is heavier operationally, has more moving parts, and benefits strongly from solid monitoring, capacity planning, and failure drills. Rook helps by providing Kubernetes-native deployment patterns and CRDs for Ceph components, including object stores and related workflows. If your team can afford the operational footprint, RGW is often the choice that maximizes ecosystem depth and long-term flexibility, especially when object storage is not an isolated component but part of a broader storage strategy.
**What to Validate in a Real PoC
A credible decision requires a measurable PoC. Define your workload concretely by testing realistic object sizes and access patterns, not just a single synthetic benchmark. At minimum, validate small-object behavior, medium objects, and large objects, because metadata and multipart behavior can dominate real performance. Test read-heavy, write-heavy, and mixed workloads, and include metadata-heavy operations such as listing and delete patterns if your applications do them. Run concurrency levels that reflect production clients, and treat latency sensitivity as a first-class requirement if your applications have tight timeouts or synchronous request patterns. Compatibility must be tested against your actual toolchain and “non-negotiable” S3 expectations, including backup tools, lifecycle rules, versioning, replication requirements, encryption expectations, and multipart uploads. Just as importantly, run failure and recovery drills: take nodes down, simulate zone loss, introduce network instability, and observe behavior while the system is rebalancing or recovering, because many systems look fine until recovery pressure reveals weak points. Finally, validate day-2 operations explicitly, including provisioning, secret and key rotation, observability (metrics/logs/alerts), upgrade procedures, and time-to-recover targets under realistic failure events.

nsswitch.conf

arash ezazi — Sun, 19 Jan 2025 22:04:34 +0000

The Importance of nsswitch.conf in Linux

The /etc/nsswitch.conf file plays a critical role in Linux systems by defining how the system resolves various types of information, such as users, groups, hosts, or services. This file specifies the order and method by which these lookups are performed, enabling administrators to control how the system interacts with different data sources.

Have you ever configured tools like FreeIPA or OpenLDAP to manage users and permissions on your Linux systems? Or have you ever needed to lock down access to specific hosts on your servers? This is where the importance of nsswitch.conf becomes evident. This file allows you to control how lookups are performed for data sources like ldap, dns, files, and more.

However, neglecting proper configuration of this file can lead to serious security risks. For instance:

Adding an untrusted LDAP source might allow attackers to gain root access to your system.
Misconfiguring mdns can cause services to connect to malicious or unintended destinations.

In this article, we will explore the structure of the nsswitch.conf file, its critical parameters, and how to properly configure it. For a deeper understanding of how DNS lookups work in Linux, you can refer to Anatomy of a Linux DNS Lookup - Part I and Part II.

Structure of `nsswitch.conf`

The nsswitch.conf file consists of lines defining a database and its associated lookup sources. Each line follows this general format:

<database>: <source> [<option>] ...

<database>: Specifies the type of information being resolved (e.g., users, groups, hosts).
<source>: Indicates the source or service used for lookups (e.g., files, ldap, dns).
<option>: Provides additional behavior or conditions for lookups (e.g., [NOTFOUND=return]).

You can also refer to Oracle’s documentation on Name Service Switch for a broader understanding of this system.

Key Sources in `nsswitch.conf`

1. `files`

The files source uses local files to retrieve information. For example:

User and group data is retrieved from /etc/passwd and /etc/group.
Hostnames are resolved using /etc/hosts.

This is the fastest and most secure option and is often listed first in most configurations.

2. `dns`

The dns source queries DNS servers to resolve hostnames into IP addresses. This is commonly used in the hosts database.

Example:

hosts: files dns

This tells the system to first check /etc/hosts and, if the hostname isn’t found, query the DNS server.

The details of how DNS resolution works, including its interaction with tools like getaddrinfo and resolv.conf, are extensively covered in Anatomy of a Linux DNS Lookup - Part I and Part II.

3. `ldap`

The ldap source queries an LDAP server to retrieve user, group, or other data. It’s commonly used in networked environments to manage users centrally.

Example:

passwd: files ldap

This configuration instructs the system to first look for user data in /etc/passwd and then query the LDAP server.

Security Note: Misconfiguring or adding an untrusted LDAP server can allow attackers to inject privileged users into the system.

4. `nis` and `nisplus`

The nis and nisplus sources retrieve information using the Network Information Service (NIS) or its enhanced version, NIS+. These are often used in older networking environments.

Example:

netgroup: nis

This instructs the system to retrieve network group information from NIS.

5. `mdns` and `mdns4_minimal`

The mdns source enables Multicast DNS (mDNS), used to resolve hostnames on local networks without requiring a central DNS server.

Example:

hosts: files mdns4_minimal [NOTFOUND=return] dns

mdns4_minimal resolves IPv4 addresses using mDNS.
[NOTFOUND=return] stops further lookups if no record is found, improving efficiency and security.

6. `db`

The db source retrieves data from local databases in Berkeley DB format. This is used for databases like protocols and services.

Example:

services: db files

This instructs the system to first query the services.db file and then fall back to /etc/services.

7. `compat`

The compat source provides backward compatibility for older NIS systems, combining local file data with NIS queries.

8. `hesiod`

The hesiod source retrieves data from DNS for user and group information. It is rarely used in modern systems.

Options in `nsswitch.conf`

[NOTFOUND=return]

This option instructs the system to stop querying other sources if a lookup fails to find the requested data.

Example:

hosts: files mdns4_minimal [NOTFOUND=return] dns

In this example, if mdns4_minimal cannot resolve the hostname, the system stops looking and does not query DNS.

Example `nsswitch.conf` Configuration

Below is a typical configuration for nsswitch.conf:

passwd:         files systemd
group:          files systemd
shadow:         files
gshadow:        files

hosts:          files mdns4_minimal [NOTFOUND=return] dns mymachines
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

passwd, group, shadow, gshadow: User and group data is retrieved first from local files.
hosts: Hostnames are resolved using /etc/hosts, mdns4_minimal, and then DNS.
protocols, services, ethers, rpc: Network information is retrieved from Berkeley DB files and local text files.

Conclusion

The nsswitch.conf file is one of the most important configuration files in Linux. It controls how the system resolves critical information and can significantly impact security and performance. Misconfigurations in this file can lead to severe issues, such as unauthorized access or misrouting of services. By understanding the available sources and their behaviors, administrators can configure their systems to be both efficient and secure.

For further reading on DNS resolution and the intricacies of how Linux handles lookups, check out Anatomy of a Linux DNS Lookup - Part I and Part II.

https://docs.oracle.com/cd/E88353_01/html/E37852/nsswitch.conf-5.html

Forem: arash ezazi

MinIO Alternatives (Open Source, On-Prem, Real-World Credible): SeaweedFS, Garage, RustFS, and Ceph RGW (Rook)

nsswitch.conf

The Importance of nsswitch.conf in Linux

Structure of nsswitch.conf

Key Sources in nsswitch.conf

1. files

2. dns

3. ldap

4. nis and nisplus

5. mdns and mdns4_minimal

6. db

7. compat

8. hesiod

Options in nsswitch.conf

[NOTFOUND=return]

Example nsswitch.conf Configuration

Conclusion

Structure of `nsswitch.conf`

Key Sources in `nsswitch.conf`

1. `files`

2. `dns`

3. `ldap`

4. `nis` and `nisplus`

5. `mdns` and `mdns4_minimal`

6. `db`

7. `compat`

8. `hesiod`

Options in `nsswitch.conf`

Example `nsswitch.conf` Configuration