Dragonfly's Manager-free mode trades the control plane for a ConfigMap and a DNS record

Dragonfly, which accelerates file and container image distribution over peer-to-peer transfer ^[1], now supports a lightweight deployment that removes the Manager, MySQL and Redis and leaves the Scheduler as the sole coordination component, installable with a single Helm command ^[4]. That matters because the standing reason to skip P2P on a single cluster was never the data path; it was being asked to run a database stack to fix an image pull problem ^[2][3].

The traditional install puts a Manager in front of the three components that actually move bytes, the Scheduler, Seed Client and Client, with MySQL for persistence and Redis for caching and asynchronous job distribution ^[2][6]. Six deployed pieces become three ^[1]. According to the project's post on the CNCF blog ^[19], that control plane earns its keep at fleet scale, where it manages relationships across multiple P2P clusters, but is heavy for one cluster that only wants to stop hammering the registry ^[3][6].

The substitution is unglamorous and that is the point. Dynamic configuration, which in the single-cluster case is just YAML describing scheduling limits, blocklists and how Clients find Schedulers ^[7], moves into a ConfigMap mounted at /etc/dragonfly/dynconfig.yaml, read when manager.addr is unset, with defaults generated if the file is missing ^[9][10]. The Scheduler's file carries cluster-level knobs: seed peer concurrent upload limit 2000, candidate parent limit 3, filter parent limit 15, peer upload limit 200 ^[11]. Scheduler and Client reload on a refreshInterval that defaults to one minute, so ConfigMap edits reach running Pods without restarts ^[12], and the same values are exposed as Helm values for scheduler, seedClient and client dynconfig ^[13].

Discovery is the other half. Where Clients used to ask the Manager which Schedulers exist, the Client now points at the Scheduler's headless Service, resolves it via DNS to every Scheduler Pod IP, health-checks each endpoint and drops unhealthy ones ^[14][15]. Scaling the Scheduler StatefulSet up or down is picked up automatically ^[16]. Schedulers outside the cluster can be pinned with a static scheduler.addrs list, which takes precedence over DNS ^[17].

What you give up is stated by omission rather than in the summary. The Manager is what hosts the web console and the open APIs used for integrations such as registry-triggered preheating, and what handles multi-cluster relationships ^[6], so a Manager-free cluster does without all three ^[2]. If your workflow depends on pushing a preheat call from the registry after every image push, this mode is not for you yet. The demonstration in the post runs in a local kind cluster ^[5]; there are no production-scale numbers here, and the material is project-authored.

Worth watching: whether the migration path from lightweight to Manager-based is documented and non-disruptive, since teams that start on a ConfigMap will eventually add a second cluster; whether preheating gets a Manager-free trigger, which is the single feature most likely to force the heavy install back onto a single-cluster team; and whether one-minute config propagation ^[12] is fast enough when a scheduling limit is the thing causing an incident.