CubeFS is an Apache-2.0, CNCF-graduated cloud-native distributed file and object storage system written in Go, built for teams that need POSIX, HDFS, S3, and REST access to a single storage layer across datacenters, private and hybrid clouds, and Kubernetes.

What it is

CubeFS, known in Chinese as 储宝, is an open-source cloud-native distributed file and object storage system hosted by the Cloud Native Computing Foundation as a graduated project. It is written in Go under the Apache-2.0 licence and developed in the open on GitHub, where it carries 5,660 stars, 714 forks, and 265 open issues. Documentation is published in English and Chinese, the project holds a bi-weekly community meeting with public schedule and minutes, and its community runs through a mailing list at [email protected], Slack at cubefs.slack.com, WeChat, and Twitter. Its topics — distributed-file-system, distributed-storage, object-storage, kubernetes, fuse, hybrid-cloud, erasure-coding, ai-native-storage, data-orchestration — say where it is meant to live.

The problem it solves is the split between file and object storage. Instead of running separate systems for POSIX workloads, HDFS-style access, and S3 object access, CubeFS serves all of them from one distributed backend behind a shared metadata service with strong consistency. It also places file system semantics and cache acceleration on top of public cloud object storage such as S3, so workloads that expect a filesystem can consume cloud storage without changing their access model. That same layer supports separating storage from compute for databases, search systems, and AI/ML applications, which the project presents as a core use case.

Key capabilities

• Multiple access protocols in one system: POSIX, HDFS, S3, and a native REST API.
• FUSE support, listed among the project topics, for POSIX-style mounting from Linux clients.
• A highly scalable metadata service with strong consistency.
• Performance optimization for large and small files and for sequential and random writes.
• Multi-tenancy with better resource utilization and tenant isolation.
• Hybrid cloud I/O acceleration through multi-level caching.
• Flexible storage policies that choose between high-performance replication and low-cost erasure coding.

Who uses it and how

• As a datacenter filesystem, providing the storage layer for an entire site or cluster.
• As data lake storage infrastructure behind analytics and processing jobs, which is where data-orchestration applies.
• As private or hybrid cloud storage, with erasure coding available for capacity-heavy tiers.
• Inside public cloud services, where it adds file system semantics and cache acceleration on top of object storage such as S3.
• As shared storage under databases, search systems, and AI/ML applications that need storage and compute scaled independently.

Getting started

The documented deployment path is the Helm chart published on Artifact Hub at artifacthub.io/packages/helm/cubefs/cubefs. Reference material lives at cubefs.io/docs/master/overview/introduction.html in both English and Chinese.

How it compares

No comparable projects and no list of commercial products it replaces appear in the facts for this entry, so it stands alone in this registry on that basis. Evaluation should rest on the capability list above rather than on any substitution claim.

When to use it — and when not to

Expect to operate real infrastructure: a metadata service, storage nodes, multi-level caching, and a policy decision between replication and erasure coding, none of which is a single-binary install. The 265 open issues and the short README mean quickstart steps live in the external documentation site rather than on the repository front page. Teams that want a drop-in managed service or a minimal-footprint store should look elsewhere.