Uploaded September 2025 | Updated September 2026, 2 weeks ago
Join us for a deep dive into the architecture of Fly.io's global infrastructure with JP Phillips, one of the key engineers behind Fly.io Machines.
What started as a fascinating "Exit Interview" blog post - fly.io/blog/the-exit-interview-jp - uncovering the human element behind a massive piece of technology, turned into this in-depth conversation about building and scaling a global, multi-tenant system.
In this conversation, JP shares his reflections on the evolution of Fly.io Machines, the critical design decisions that shaped the platform, and the trade-offs made along the way. We explore the journey from a Nomad-based architecture to the custom-built Fly.io Machines, the reasoning behind choosing BoltDB over SQLite, and the crucial role of fly-proxy in handling traffic at a massive scale.
We also take a look at some of the open-source components that power Fly.io, including a code walkthrough of the Finite State Machine (FSM) that manages the lifecycle of machines and volumes. JP explains how this simple yet powerful component ensures reliability and simplifies operations.
Whether you're a software engineer, a DevOps professional, or just curious about how large-scale distributed systems are built, this conversation is packed with valuable insights and hard-earned lessons.
If you enjoy this, there is more:
- Join πͺ© makeitwork.club for regular members-only discussions
- Tune into π§ https://makeitwork.fm for the podcast
- Sign-up at πΊ makeitwork.tv for more content
00:00:00 β It all started with The Exit Interview
00:03:24 β Have any of your thoughts refined since the blog post?
00:09:12 β How did Fly.io Machines start?
00:17:20 β Initial design considerations
00:28:21 β SQLite vs BoltDB
00:36:07 β Why no database for flaps?
00:38:50 β fly-proxy
00:46:21 β Open-source components
00:54:09 β Letβs look at the FSM code
01:06:57 β Something simple that works as designed
01:11:07 β Our take aways
Join us for a deep dive into the architecture of Fly.io's global infrastructure with JP Phillips, one of the key engineers behind Fly.io Machines.
What started as a fascinating "Exit Interview" blog post - fly.io/blog/the-exit-interview-jp - uncovering the human element behind a massive piece of technology, turned into this in-depth conversation about building and scaling a global, multi-tenant system.
In this conversation, JP shares his reflections on the evolution of Fly.io Machines, the critical design decisions that shaped the platform, and the trade-offs made along the way. We explore the journey from a Nomad-based architecture to the custom-built Fly.io Machines, the reasoning behind choosing BoltDB over SQLite, and the crucial role of fly-proxy in handling traffic at a massive scale.
We also take a look at some of the open-source components that power Fly.io, including a code walkthrough of the Finite State Machine (FSM) that manages the lifecycle of machines and volumes. JP explains how this simple yet powerful component ensures reliability and simplifies operations.
Whether you're a software engineer, a DevOps professional, or just curious about how large-scale distributed systems are built, this conversation is packed with valuable insights and hard-earned lessons.
If you enjoy this, there is more:
- Join πͺ© makeitwork.club for regular members-only discussions
- Tune into π§ https://makeitwork.fm for the podcast
- Sign-up at πΊ makeitwork.tv for more content
00:00:00 β It all started with The Exit Interview
00:03:24 β Have any of your thoughts refined since the blog post?
00:09:12 β How did Fly.io Machines start?
00:17:20 β Initial design considerations
00:28:21 β SQLite vs BoltDB
00:36:07 β Why no database for flaps?
00:38:50 β fly-proxy
00:46:21 β Open-source components
00:54:09 β Letβs look at the FSM code
01:06:57 β Something simple that works as designed
01:11:07 β Our take aways
