---
title: "Carving The Scheduler Out Of Our Orchestrator"
description: "Fly.io describes why it is carving scheduling out of its existing Nomad-based orchestrator and replacing it with a simpler system centered on flyd and AppsV2. It first reduces orchestration to a client-server supervisor, then explains centralized scheduling: workers register resources, while a server filters candidates by constraints and ranks them. The proposed design avoids jobs sitting pending or being placed in nearby but incorrect regions; requesting VMs in MAD yields MAD capacity or nothing. Policy-heavy behavior such as deployment spares, crash recovery across workers, and regional decisions moves into flyctl and other platform components rather than the scheduler. Fly Machines already exposes APIs to reserve, start, and stop individual VMs, with Nomad still used in January 2023 and flyd expected for deployments in December 2023."
---

# Carving The Scheduler Out Of Our Orchestrator

[Fly.io](https://yomu.fyi/company/fly-io) · Feb 1, 2023

**Type:** Explainer

## Summary

Fly.io describes why it is carving scheduling out of its existing Nomad-based orchestrator and replacing it with a simpler system centered on flyd and AppsV2. It first reduces orchestration to a client-server supervisor, then explains centralized scheduling: workers register resources, while a server filters candidates by constraints and ranks them. The proposed design avoids jobs sitting pending or being placed in nearby but incorrect regions; requesting VMs in MAD yields MAD capacity or nothing. Policy-heavy behavior such as deployment spares, crash recovery across workers, and regional decisions moves into flyctl and other platform components rather than the scheduler. Fly Machines already exposes APIs to reserve, start, and stop individual VMs, with Nomad still used in January 2023 and flyd expected for deployments in December 2023.

## Context

Fly.io needs to scale from running a single Docker-derived VM to running hundreds of thousands of jobs. The existing Nomad-based approach could make scheduling decisions that conflicted with the platform's regional requirements, including moving applications to different machines during connectivity problems.

## Approach / What changed

The proposed AppsV2 design uses flyd to expose basic VM operations and separates scheduling from broader platform policy. A centralized scheduler registers worker resources, filters workers against job constraints, ranks viable placements, and assigns jobs directly; deployment, recovery, and related policy-heavy behavior moves to flyctl and other components.

## Takeaways

- Orchestration is presented as a client-server process supervisor: workers poll for jobs, claim them, run them, and release them through HTTP endpoints.
- The centralized scheduler registers worker capacity, filters candidates by constraints such as CPU and disk space, and ranks the survivors instead of having workers compete to claim jobs.
- AppsV2 moves complex deployment and recovery decisions into flyctl and other platform components, while flyd exposes primitives to reserve, start, and stop individual VMs.

**Tags:** [Architecture](https://yomu.fyi/topic/architecture), [Distributed Systems](https://yomu.fyi/topic/distributed-systems), [Fly Machines](https://yomu.fyi/topic/fly-machines), [Nomad](https://yomu.fyi/topic/nomad)

- Source: [Fly.io](https://fly.io/blog/carving-the-scheduler-out-of-our-orchestrator)
- Source URL: https://fly.io/blog/carving-the-scheduler-out-of-our-orchestrator
- Ingested by Yomu: 2026-09-03T01:25:50.254Z

[Read original post](https://fly.io/blog/carving-the-scheduler-out-of-our-orchestrator)