---
title: "The Exit Interview: JP Phillips"
description: "JP Phillips leaves after four years at Fly.io, saying the company’s increasing focus on Managed Postgres and LLMs does not match the direction he hoped to see: a move toward cloud provision and larger established customers. He says his original goal—building Fly Machines to replace HashiCorp Nomad—has been accomplished, with the platform now capable of supporting the next iteration of products. His central engineering contribution was the Fly Machines API and flyd, an independently running orchestrator whose finite-state-machine invocations use deterministic, durable execution and log each step in BoltDB. He also discusses corrosion2, a Rust service that uses SWIM gossip and a CRDT-structured SQLite database to distribute near-real-time machine state. Phillips criticizes GraphQL, Elixir, inconsistent communication and shifting priorities, while defending BoltDB and praising Rust’s productivity."
---

# The Exit Interview: JP Phillips

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

**Type:** Announcement

## Summary

JP Phillips leaves after four years at Fly.io, saying the company’s increasing focus on Managed Postgres and LLMs does not match the direction he hoped to see: a move toward cloud provision and larger established customers. He says his original goal—building Fly Machines to replace HashiCorp Nomad—has been accomplished, with the platform now capable of supporting the next iteration of products. His central engineering contribution was the Fly Machines API and flyd, an independently running orchestrator whose finite-state-machine invocations use deterministic, durable execution and log each step in BoltDB. He also discusses corrosion2, a Rust service that uses SWIM gossip and a CRDT-structured SQLite database to distribute near-real-time machine state. Phillips criticizes GraphQL, Elixir, inconsistent communication and shifting priorities, while defending BoltDB and praising Rust’s productivity.

## Context

Phillips says his view of where Fly.io should be in three to four years—more directly positioned as a cloud provider and serving larger established companies—does not match the company’s current direction, particularly its focus on Managed Postgres and LLMs. He also says inconsistent communication, shifting priorities and unclear accountability made it difficult to identify valuable work and see projects through.

## Approach / What changed

Phillips describes building the Fly Machines API and flyd orchestrator, which runs on worker servers without central coordination. flyd represents operations as finite-state-machine invocations with callbacks and per-step logging in BoltDB, enabling deterministic, durable execution that can resume after deployments. He also discusses corrosion2, which propagates worker state using SWIM gossip into a CRDT-structured SQLite database.

## Takeaways

- flyd runs independently across thousands of worker servers and uses finite-state-machine invocations for operations such as creating, starting and cordoning Fly Machines.
- Phillips says BoltDB was preferable to SQLite for flyd because its narrower storage interface reduced the scope of possible state changes and avoided SQL updates across a host or fleet.
- corrosion2 uses SWIM gossip and a CRDT-structured SQLite database to make near-real-time information about Fly Machines available to platform components.

**Tags:** [Distributed Systems](https://yomu.fyi/topic/distributed-systems), [Fly Machines](https://yomu.fyi/topic/fly-machines), [Rust](https://yomu.fyi/topic/rust), [SQLite](https://yomu.fyi/topic/sqlite)

- Source: [Fly.io](https://fly.io/blog/the-exit-interview-jp)
- Source URL: https://fly.io/blog/the-exit-interview-jp
- Ingested by Yomu: 2026-09-03T01:25:25.470Z

[Read original post](https://fly.io/blog/the-exit-interview-jp)