longhorn/longhorn-manager

Millions and millions of volumes orchestrated

Hosted by Cloud Native Computing Foundation · part of Linux Foundation

View on GitHub ↗Jump to charts ↓

longhorn/longhorn-manager has 200+ stars and 200+ forks on GitHub, is written in Go, and was last pushed on Oct 18, 2026. Data as of . Signed-in members get hourly updates — create a free account.

Summary Information

Updated 18 minutes ago
Added to GitGenius on October 15th, 2026
Created on May 3rd, 2017
Open Issues & Pull Requests: 52 (+0)
GitHub issues: Disabled - open counts may still include pull requests.
Number of forks: 226
Total Stargazers: 215 (+0)
Total Subscribers: 16 (+0)

Repository Insights (GitGenius)

Most active contributors

Sign in to see contributor activity.
Sign in

Related repositories by overlapping contributors

No overlapping-contributor repos identified yet.

Charts & Analytics

Fetching additional details & charts...

Issue Activity (beta)

GitHub issues are disabled for this repository, so issue analytics and the issue explorer are not available.

Detailed Description

Longhorn Manager is a Kubernetes storage orchestrator that provisions and manages distributed block storage volumes across a cluster.

The tool addresses the need for persistent storage in Kubernetes by implementing a distributed storage system where data is replicated across multiple nodes. It works by deploying manager components alongside CSI plugin components that handle volume provisioning, attachment, and lifecycle management. Volumes are stored on the filesystem using iSCSI and NFS protocols, with data replicated to provide fault tolerance.

Longhorn Manager suits clusters that need reliable persistent storage without external storage infrastructure. It works best on Kubernetes clusters running version 1.21 or later with mount propagation enabled, where nodes have iSCSI and NFS client tools installed and filesystems supporting file extents. The deployment is self-contained within a single kubectl command that installs the manager, instance manager, CSI components, and UI into the longhorn-system namespace. Teams should be aware that cleanup requires careful sequencing: volumes and workloads must be deleted first, the deleting-confirmation-flag setting must be enabled, and an uninstallation job must complete before removing remaining components to avoid cluster damage.

The project maintains active build and test infrastructure with unit tests covering affected modules and integration tests in a separate repository. Development follows a structured contribution process documented in the main Longhorn repository.