drove-orchestrator: PhonePe’s Drove Orchestrator: A Lean, State-Driven Answer to Kubernetes Complexity

A deep look at how PhonePe split orchestration into a controller, executors, gateway, DNS, and epoch model to keep container infrastructure explicit, predictable, and production-ready.

10 to 12 min read • View on GitHub • More from PhonePe

A wide editorial illustration of a control tower made from stacked orchestration modules, with a controller at the top, executors on separate islands, a gateway gatehouse, a DNS tower, and a small epoch dial overseeing the system. It explains that Drove is intentionally modular, with each subsystem holding a narrow responsibility instead of hiding everything behind one giant control plane. — Drove reads less like a cloud OS and more like a set of tightly bounded machines.

Key Takeaways

Drove is interesting because it makes orchestration legible, splitting control, execution, discovery, and coordination into separate subsystems with clear jobs.
The repo’s real differentiator is not feature breadth but explicit state handling, with ZooKeeper and epochs helping keep placement and transitions predictable.
Local services, gateway routing, and DNS integration show that Drove is meant to be operable as a full runtime, not just a scheduler.
Compared with Kubernetes and Nomad, Drove optimizes for a narrower enterprise envelope where simplicity and operational clarity matter more than ecosystem size.

Why PhonePe Built a Smaller Orchestrator

The surprise is not that PhonePe built an orchestrator. It is that Drove looks intentionally smaller than the category usually allows. The project is built around a clear bet: some production environments need scheduling, discovery, and routing without inheriting the full complexity tax of Kubernetes.

Drove is a custom container orchestrator built at PhonePe to manage our containerized workloads. It is designed to be simple, scalable, and reliable.

PhonePe Tech Blog, Official Blog · Drove: Our journey to building a custom container orchestrator

That framing matters. Drove is not pitching itself as a universal platform. It reads like an internal system that was sharp enough to survive real operations, then narrow enough to be shared without pretending to replace the whole ecosystem.

The repository reinforces that idea. Instead of one sprawling control plane, the codebase is split into a controller, executors, gateway, CoreDNS integration, CLI tools, and epoch handling. The architecture is opinionated, but it is also legible.

The Architecture Is Split on Purpose

Drove’s structure is the first clue that this is a system built around bounded responsibilities. The controller decides, the executors act, ZooKeeper coordinates, DNS and gateway publish the result, and epochs keep the state transitions honest.

The control loop is explicit. One path decides placement, another publishes the result, and both are versioned through epoch state.

That split is not cosmetic. It is the design. A system like this stays understandable because each subsystem has a job you can name without stretching.

Drove is a container orchestration system designed for simplicity, scalability, and ease of use.

GitHub Repository README, Project Documentation · PhonePe/drove-orchestrator

Controller, Executor, ZooKeeper: The Real Control Loop

The controller is the brain. Executors are the hands. ZooKeeper is the coordination spine. That combination gives Drove a classic distributed-systems shape: a centralized decision-maker, node-level agents, and a shared source of truth for cluster state and versioning.

The executor layer is especially revealing because it talks to Docker directly. In practice, that means Drove does not hide the runtime behind a heavy abstraction stack. It schedules, then it asks the node to do the obvious thing.

Epochs matter here because they make state transitions explicit. In a cluster system, the failure mode is often not raw crashes. It is ambiguity. Epochs are a way to make stale decisions easier to reject and cluster changes easier to reason about.

Desired state -> Controller
Controller -> ZooKeeper (membership, placement, epoch)
Controller -> Executor(s)
Executor -> Docker daemon
Metadata -> Gateway / CoreDNS

Local Services Are the Tell

The most interesting noun in the repo may be local services. That phrase suggests Drove is not only managing replicated application workloads. It is also handling services with a node-aware or lifecycle-specific shape, which is a very different problem from plain app replicas.

A close-up mechanical split shows a deployment decision passing through an epoch stamp. On the left, the controller places an application instance. On the right, an executor turns that decision into a Docker container, while a separate side channel marks a local service path with a different lifecycle. It explains that Drove can treat workload classes differently instead of forcing every service into one replica model. — Local services hint at a second scheduling class, one that is more specific than ordinary stateless replicas.

That matters because it implies a richer operational model than generic orchestrators expose. Some workloads want portability. Some want locality. Some want both, but on different terms.

Concern	Drove	Kubernetes	Nomad
Control-plane complexity	Small and explicit	Large and layered	Moderate
Runtime assumption	Docker-first	Multi-runtime via CRI	Flexible task drivers
State coordination	ZooKeeper and epochs	etcd and controllers	Integrated server state
Service discovery	Gateway and CoreDNS integration	Built-in DNS and ingress	Usually external integration
Best fit	Narrow enterprise platform envelope	General-purpose ecosystem	Simpler multi-workload orchestration

Ingress and Discovery Are Not Afterthoughts

Drove does not stop at placement. Gateway and CoreDNS make the system usable by turning scheduled containers into reachable services. That is the difference between an internal scheduler and a production platform.

This is where the project stops feeling generic. If you have to bolt on traffic routing and name resolution later, the orchestration story is incomplete. Drove treats them as part of the same operational contract.

The result is a runtime that knows how to move from intent to reachability. That is the real loop a platform team cares about.

What Drove Reveals About Platform Design

Drove argues for a narrower kind of platform thinking. Not everything needs to become a universal abstraction. Sometimes the better system is the one that keeps state visible, responsibilities small, and transitions deterministic.

That is why the project feels less like an open-source clone of Kubernetes and more like an internal product with strong opinions. It is built for an environment where operational clarity is a feature, not a compromise.

The broader lesson is simple. Mature engineering teams do not always want more platform. They want less mystery.