Dragonfly
Dragonfly is a cloud-native peer-to-peer distribution system for files and container images. It shares downloaded data between machines so a large fleet does not repeatedly pull the same content from one source.
itCloud native tools and technologies | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Don't Panic
Don't Panic: Dragonfly
Dragonfly is a peer-to-peer distribution system for cloud-native data. Its job is less mystical than its name suggests: stop a registry, object store, or HTTP server from being asked for the same large artifact by every machine in a rollout. The origin still owns the content. Dragonfly merely arranges a more sociable route to it.
The useful picture has four characters. The Manager keeps track of cluster relationships and dynamic configuration. The Scheduler decides which Peer can help a download. A Seed Peer can fetch cold content from the original source. A Peer downloads, caches, and uploads pieces. None is a decorative title. If any of these paths is unavailable when the cache is cold, the source path is suddenly very much part of the plan.
On the first request, a Peer registers a task and the Scheduler can direct a Seed Peer to fetch from the source. The content is divided into pieces. Later Peers can receive those pieces from several parents and assemble the result. A local cache hit is the least dramatic outcome, which is exactly what you want from infrastructure. Repeated demand moves from one origin path to a network of peers, without appointing Dragonfly the owner of the artifact.
The surprise is that the P2P layer does not abolish capacity planning. It adds services, peer storage, network paths, client integration, and a controlled route back to the source. For a small fleet with rare downloads, that is a lot of machinery to admire while direct pulls continue behaving perfectly well. For repeated image pulls, OCI artifacts, dependencies, files, or model data, the calculation changes quickly.
Read the Intro when you need the full request path and the limits of each role. Use the slides to keep the cold and repeated flows straight. The Cheatsheet is the compact map for task, piece, parent Peer, cache, and back-to-source vocabulary. The Reference tab leads from the official Kubernetes deployment to architecture and Scheduler details. Start with one cold download and one repeated download. The system will then cease to be an elaborate diagram and become a testable path.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://d7y.io/docs/
Supports
- Dragonfly purpose, supported distribution use cases, architecture roles, and request flow
- Manager, Scheduler, Seed Peer, and Peer responsibilities
- First-time, repeated, and locally cached download behavior
- https://d7y.io/docs/reference/commands/scheduler/
Supports
- Scheduler task management, source notification, P2P-network maintenance, and peer selection
- Scheduler command interface and default configuration-file path
- https://d7y.io/docs/getting-started/quick-start/kubernetes/
Supports
- Official Kubernetes deployment path for Dragonfly services
- https://d7y.io/docs/operations/architecture/architecture/
Supports
- Detailed subsystem responsibilities and client proxy and gRPC integration modes
- https://github.com/dragonflyoss/dragonfly
Supports
- Maintained upstream project repository, releases, issues, and contribution material
- https://github.com/spegel-org/spegel
Supports
- Spegel's cluster-local OCI registry mirror role, node cache sharing, containerd focus, and MIT licensing
- https://goharbor.io/docs/main/administration/configure-proxy-cache/
Supports
- Harbor proxy-cache behavior for registry content and its relationship to upstream availability
- https://docs.jfrog.com/artifactory/docs/jfrog-container-registry
Supports
- JFrog Container Registry local, remote, and virtual repository roles for OCI artifacts
- https://docs.docker.com/docker-hub/usage/
Supports
- Docker Hub pull limits and their relevance to repeated image downloads
- https://www.cncf.io/case-studies/kuaishou-technology/
Supports
- Kuaishou's production Dragonfly and Nydus deployment, runtime integration, availability-zone placement, and registry bandwidth observations
- https://www.cncf.io/blog/2026/08/13/lightweight-dragonfly-deployment-p2p-distribution-without-the-database-stack/
Supports
- The operational cost of the standard Dragonfly dependency stack and the lightweight deployment alternative
