Fly with Rugwiro Valentin

Episode Description

Rugwiro Valentin shares his journey from learning to code in Rwanda to working at Fly.io, explaining how Fly deploys apps globally using Docker, Firecracker, and WireGuard.

Episode Summary

In this episode, Rugwiro Valentin, a developer based in Rwanda and employee at Fly.io, shares his path from writing code on paper without a computer to contributing to open source and landing a job at a cloud infrastructure company. The conversation traces his self-taught journey through Python, Django, and Go before discovering Fly through its blog while researching Firecracker microVMs. The hosts and Valentin then break down how Fly works under the hood — taking Docker images, converting them into Firecracker VMs via HashiCorp Nomad, and distributing them across global edge servers connected by a Rust-based proxy. They compare Fly's developer experience to Heroku and traditional VM providers like DigitalOcean and AWS, arguing that Fly offers the simplicity of a platform-as-a-service while scaling with you so you never need to migrate. Key topics include the Twelve-Factor App methodology, Buildpacks and their pre-Docker origins, WireGuard private networking, and how Fly handles different traffic types beyond just HTTP. The episode closes with a mention of an emerging Redwood-Fly integration and Valentin's ongoing work on a proxy tool to simplify private network access.

Chapters

00:00:00 - Meet Valentin and Introduction to Fly.io

Rugwiro Valentin introduces himself and provides his own perspective on what Fly.io does as a cloud provider. He describes Fly as similar to Heroku but with a key distinction: it takes users' applications, packaged as Docker images, and runs them on physical servers distributed across the globe, as close to end users as possible. His analogy of Fly as a CDN for web applications rather than static content captures the core value proposition in an accessible way.

Anthony notes that Docker has a steep learning curve but becomes powerful once the basics click, and he sets the stage for hearing Valentin's personal story. The fact that Valentin is joining from Rwanda adds a unique global perspective to the conversation, and Anthony invites him to share how he first got into programming and what drew him toward software development.

00:02:21 - Learning to Code in Rwanda and the Path to Fly

Valentin recounts how he became interested in computers around ninth grade in 2012, recognizing that software required fewer physical resources than fields like biology or physics. Without a computer of his own, he wrote code on paper and typed it in when he got access to a machine. A pivotal moment came through a bootcamp run by two MIT students at Kepler University, where he learned Python by working on a solar panel optimization project for rural Rwandan communities.

After the bootcamp, he taught himself Django and Flask before a friend introduced him to Go in 2018, which became his primary language. His interest in open source led him to discover Fly while searching for a Heroku alternative built on technology he admired. He began contributing code and engaging actively on the Fly community forum, and his enthusiasm caught the attention of the Fly team, eventually leading to a job offer — a story that echoes the power of open source participation as a career pathway.

00:08:01 - Understanding Docker, VMs, and Firecracker

Anthony steps back to define foundational infrastructure concepts for listeners, walking through the differences between virtual machines, containers, and Firecracker microVMs. He explains that VMs virtualize entire operating systems on bare metal, while containers offer a lighter-weight alternative that runs applications as isolated processes. Firecracker sits between the two — small enough to be efficient but providing VM-level isolation, making it ideal for running many containers securely.

Chris shares that he's not a Docker expert and prefers PM2 as a process manager, which prompts a brief discussion of Docker Compose as a higher-level tool for orchestrating multiple containers. Valentin then bridges the gap to Fly, explaining that the flyctl CLI offers a familiar Docker-like API, but behind the scenes, Docker images get "transmogrified" into Firecracker VMs and deployed across Fly's global infrastructure. The conversation highlights how Docker familiarity translates directly into ease of use on Fly.

00:13:34 - How Fly Works Under the Hood

Valentin walks through Fly's deployment pipeline in detail: a Docker image is uploaded to Fly's registry, then HashiCorp Nomad — used instead of Kubernetes — schedules Firecracker VMs built from that image combined with a Linux kernel Fly provides. He explains how the fly.toml configuration file defines handlers for HTTP, TCP, TLS, or even UDP traffic, giving developers flexibility beyond what typical platforms offer, including the ability to run DNS servers or Postgres databases on Fly.

The Fly Proxy, written in Rust using the Tokio async runtime, emerges as the central piece of infrastructure. It runs on edge servers and routes incoming traffic to the correct worker nodes based on the configuration. Valentin also covers volumes for persistent storage, secrets management, and environment variables, painting a picture of a platform that handles the operational complexity that would otherwise require significant DevOps expertise on providers like AWS.

00:18:24 - Why Use Fly Over Traditional Cloud Providers

The conversation shifts to the practical question of why someone would choose Fly over spinning up an EC2 instance or using DigitalOcean. Valentin speaks from experience as a former customer, explaining that configuring VMs manually — installing packages, setting up load balancers, managing databases — was overwhelming for a solo developer. Fly and Heroku's approach of abstracting that away through Buildpacks and simple deployment commands made shipping code dramatically easier.

He also introduces the Twelve-Factor App methodology as a guiding philosophy, explaining how it encourages separating code from configuration and secrets. Anthony expands on this, noting that modern developers often follow these principles without realizing their origin. The discussion establishes that for small teams or solo developers, platforms like Fly remove enormous operational burden while still offering the flexibility to grow into more complex architectures like microservices and private networking.

00:23:06 - Scaling, Pricing, and Heroku Comparisons

Chris asks whether Fly might be overkill for very small applications, and Valentin argues it's actually the right starting point because it scales with you. Unlike Heroku, where costs balloon as you add features like log aggregation, Fly charges primarily for consumed resources — RAM, CPU, and storage. This means a small API and a large-scale production app can coexist on the same platform without requiring a migration to a different provider as needs grow.

The group then unpacks what a "Heroku app" really means and how Fly turbocharges that model. Valentin defines it broadly as anything that accepts traffic and returns responses, then explains how Fly extends this by supporting raw TCP and UDP handlers alongside HTTP. Anthony adds historical context about Buildpacks predating Docker by two years and their evolution into Cloud Native Buildpacks, connecting the dots between Heroku's innovations and the modern container ecosystem that Fly builds upon.

00:28:23 - GraphQL, Dogfooding, and the Fly Proxy

Chris asks about Fly's support for GraphQL with Redis and Apollo, and Valentin explains that Fly aims to stay out of your way regardless of your API technology. He reveals that Fly's own API runs on its own infrastructure — a practice known as dogfooding — which serves as strong evidence that the platform handles production workloads well. The Fly Proxy's ability to handle HTTP, TCP, and TLS traffic means GraphQL works out of the box with no special configuration needed.

Valentin highlights that the proxy is built with Rust and the Tokio async runtime, which Anthony connects to his knowledge of Deno's architecture. The discussion reinforces that Fly's flexibility comes from its proxy layer rather than opinionated application constraints, and Chris confirms that both beginners deploying their first app and experienced engineers managing large-scale deployments should find the experience smooth, a claim Valentin backs up with feedback from friends early in their careers.

00:31:38 - WireGuard, Private Networking, and Flicker Proxy

Anthony asks about WireGuard, which Fly uses to create private networks between applications and infrastructure. Valentin explains that WireGuard is a userspace networking stack that reduces latency compared to kernel-level networking, making it well-suited for infrastructure providers. Fly uses WireGuard Go to mesh together all hosts and edge workers, and each organization on Fly gets its own subdivided private network with internal DNS mapping app names to IPv6 addresses.

Valentin then describes his current project, Flicker Proxy, which aims to simplify connecting to private network resources like Postgres databases without exposing them to the public internet. Currently, users must generate certificates and configure Ethernet devices manually — a complex process he's working to streamline by leveraging WireGuard Go directly. This project exemplifies how Fly continually improves developer experience around its networking capabilities.

00:35:59 - Redwood Integration and Closing Thoughts

Anthony mentions that a Redwood-Fly integration has been in development, representing Redwood's first official Docker deployment path. While a full CLI command is still being refined, developers can already create a Dockerfile and deploy a Redwood app to Fly today. Valentin shares that reviewing the integration code introduced him to Redwood for the first time and sparked his interest in exploring the framework further.

The episode wraps with Valentin sharing his Twitter handle, "a code chef," inspired by his mother's love of cooking. Anthony encourages listeners to check out Fly's generous free tier and explore the documentation, praising Valentin's performance on his very first podcast. Valentin expresses gratitude for the opportunity, noting it as a personal milestone, and credits Kurt for recommending him as a guest — a fitting end to a story about community connections opening doors.

Transcript

00:00:00 - Rugwiro Valentin

My name is Rugwiro Valentin. I think Valentin would be easier.

00:00:16 - Anthony Campolo

Valentin, welcome to the show.

00:00:18 - Rugwiro Valentin

Thank you.

00:00:19 - Anthony Campolo

It's great to have you. This is your first time on a podcast, so that's super exciting. We're very honored to have you join FSJam for your first podcast interview. You work for the company Fly, or Fly.io. It's a really great global deployment company that I've been learning a little bit about over the last couple months. I'd love to hear a little bit about what Fly is, and then we can get into your background and how you learned to code.

00:00:46 - Rugwiro Valentin

I'm going to give a perspective on Fly as I see it. There's what we like to give to our customers, and then there's Fly as I understand it.

Fly is a cloud provider in the same image as the likes of Heroku. The unique thing about Fly is that we take people's applications and run them close to their users. We have different physical servers around the world, in different regions, and the app runs there. We take the app as a Docker image and run it as close to your users as we can.

To paraphrase that, I think Fly is like a CDN, but for web applications instead of content.

00:01:30 - Anthony Campolo

That's a great way to put it: a CDN for web applications and for Docker and containers. I'm someone who has just been learning Docker recently. I went through a boot camp, and they don't really teach you Docker in boot camps. Maybe they do a little bit in some, but I didn't really get that kind of experience. I found that Docker has a steep learning curve, but once you get the basics down, it's really nice and can be incredibly powerful and do a lot for you with just a couple simple commands.

You live in Rwanda, so we're really happy to get the perspective of someone in a very different area than where I'm from. I'd love to know how you got into coding, how you learned to code, and what compelled you to go down this journey.

00:02:21 - Rugwiro Valentin

Around 2012, I think in senior three, so that's like ninth grade, me and a couple of my friends were interested in computers and science in general. But looking at the resources that I had at the time, I thought maybe I couldn't make as much of an impact in something like biology or physics because it required resources that I didn't have. I thought I could do a lot with just a computer and a connection, so I started then.

My parents didn't get it. Around here, parents think if you're not a doctor or an engineer, what the hell are you doing with your life? So I had to climb that mountain to convince them. By the time I was done with secondary school in 2016, there was this university called Kepler. It's supported by, I think, a British university. I don't remember the name, but they had two MIT students who were on vacation and wanted to make an impact outside of school.

[00:03:34] So it was maybe their last year of uni. They decided to do something with their time off and started a boot camp. They were teaching us Python and how to use it to collect data, analyze it, and do something with it. At the time, there was a company that was trying to introduce solar panels, solar electricity, in remote areas in Rwanda where the grid doesn't reach. Our job was to collect data from their solar panels and try to create the best-case scenarios in which they could put the solar panels to generate as much electricity as possible.

It was the first real experience I had with code. Otherwise, I could only read books at the time. I didn't even have a computer, so I had to write code on paper. When I got the computer, I would go and write the code I had on my papers. Starting in 2016, I was coding in Python after the boot camp, which was about four months. I continued and taught myself Python, Django, and Flask, and started writing some web applications.

[00:04:54] But in 2018, there was this friend of mine. He was studying at a university in America, in Nebraska, and he came to me and said, "You gotta check this thing out, this thing called Go." I was like, "Go? No, Python is the language." But since we had been friends since secondary school, I tried it and I loved it. From 2018, I programmed mostly in Go on my own projects. Friends told me to do some projects for them. What moved me to the next stage, I think, was trying to contribute to open source.

Contributing to open source is how I found out about Fly. I was looking for an alternative to Heroku, but an alternative that was using the technology that I like. I like to complain about the tech I use a lot. So if I'm using Google or AWS, people like to complain about the AWS documentation. I was complaining about those things too. That's when I discovered Fly.

[00:06:06] It was eye-opening. Besides the fact that it was easy to use, it was very familiar because I used Heroku a lot. The technology they were using behind the scenes and talking about on their blog attracted me. At the time, I was trying to get into infrastructure, mainly Docker and, I think, Firecracker. Firecracker is a virtual machine manager out of AWS. They use it on the Lambda product. Basically, it runs very small microVMs. It's open source.

I was looking for an article about Firecracker. By accident, I discovered it on the Fly blog and decided I should move all my applications to Fly. Once I was on Fly, I really liked to talk with them on the community forum. I asked questions, tried to solve some problems I had encountered. This one time, there was someone who was complaining about something about logs, collecting logs and pushing them to external services like S3, for example.

[00:07:22] I took that up. I contributed some code because I needed those logs myself. So I decided I was going to contribute the code that I needed to use the application. The folks at Fly, I think they liked it. What showed me that they liked it? I saw a posting on Slack talking about how they liked this dude who was asking a lot of questions and bugging them all day long.

I thought to myself, this is the post that actually got me hired. My journey is like that. There's a lot I would like to share, but in a few words, that's all.

00:08:01 - Anthony Campolo

That's an awesome story, and it's great that they recognized you and that they saw that you were interested in this and wanted to bring you on. It's also awesome to hear that open source was a way to get in, because that's a huge part of my story. I got involved with open source through Redwood, and that's what led to me eventually getting noticed for my job.

You mentioned a couple pieces of tech there that we should dig into a little more and define some terms for people, because Docker is something that you can use without really knowing how it works. Or you can learn how it works under the hood and never really learn how to use it. But I think it's pretty useful to have at least a basic understanding of why it was even invented in the first place.

You always hear these conversations about the difference between a container and a VM. A VM is a virtual machine. When we think of things like Amazon EC2, those are VMs. The idea is that they take bare metal, make a machine for you, and load up a virtual operating system on top of it.

[00:09:08] So you could have any kind of Linux you want. You don't necessarily need to have one specific box to run one specific type of Linux. You can run any kind of them because you're virtualizing the machine itself, but then you're taking up this whole machine to run what could be a very simple hello-world application.

What you want to do is take a machine and partition off different pieces of it for different applications. This is where we get into containers. It's a way to have almost just a process running that is your application.

What's interesting, though, is that we're running Docker containers on VMs, and the reason why this actually isn't a dumb thing to do is because we have this thing called Firecracker. Firecracker is what's known as a quote-unquote microVM, which is something that I don't really know a ton about. But I know the broad idea is it's like splitting the difference down the middle between the VM and the container.

[00:10:05] It's like the smallest kind of VM you can get that's not quite a container. So then you can run a bunch of containers on it. I'd be curious, Chris, what your experience is like. You obviously have run Docker before. I don't know if you've used it a ton. How do you tend to think of this split between VMs and Docker?

00:10:24 - Christopher Burns

I'm definitely not a Docker expert. I'd class myself as having hacked it enough to get it working, and that's about it, using Docker Compose. If you ask me, what's the difference between Docker and Docker Compose, I have no clue. Docker Compose is just like this YAML file that tells it what to do, in my eyes. And it works.

I've used Docker in the past, but my process manager of choice at this stage in my development career is actually PM2. I know both of them are quite controversial to each other.

00:10:54 - Anthony Campolo

Yeah, you could dockerize PM2 if you wanted to, so you can mix and match these things. What you're saying about Docker Compose: Docker Compose is a higher-level abstraction on Docker. You can have a Dockerfile that contains a Node application. You can also have another Dockerfile that is your React app. Then you can create a Docker Compose file that will run both of those containers simultaneously and package them together into one thing.

00:11:24 - Rugwiro Valentin

The difference is just the API. If you're in development mode, you can use Docker and Docker Compose. You have your Docker daemon running on your machine. But if you want to move to production and you want to use Fly, the API doesn't change a lot. We use a command called flyctl. It's what we use to fly your applications on the platform. It's almost the same as Docker.

People who have used Docker don't take too much time to start using Fly. Behind the scenes, it's not actually a Docker engine that we are running. You take your Docker image or Dockerfile and it gets transmogrified. That's the term we like to use. I don't remember who invented it. We transform them into Firecracker VMs that we run on different physical infrastructure around the world. If you are a Docker user like Chris here, I think you would get Fly right away.

00:12:31 - Anthony Campolo

Yeah. The times I messed around with it, what I liked about it is, as you say, if you already know Docker, you can get going pretty easily because what it will do is you'll install the Fly CLI, flyctl, which I think is influenced by kubectl, which is a Kubernetes command-line tool. But it's not really like running Kubernetes at all. It's much more like just running Docker.

That's a whole other giant rabbit hole we could go down between Kubernetes and Docker, but when you just have a Dockerfile, you can run fly launch, and then it will look at your app and spit out this fly.toml file. The fly.toml file is your infrastructure-as-code thing. We see this with Render, you have a render.yaml. You see this with Netlify, you have a netlify.toml. It's just some sort of hunk of code that is configured to do something with the platform.

So can we get a little bit into what Fly is doing and how you introspect an application, how you figure out what needs to happen with it?

00:13:34 - Rugwiro Valentin

I would like to go a little behind the infrastructure and maybe give us an overall picture of how things look. When you run deploy, we receive a Docker image. Maybe you have Docker on your machine and we use Docker to build your application. Then we upload that image to the registry, the Docker registry that is running on Fly. From there, we take that image and run it with HashiCorp Nomad. Instead of running Kubernetes, we are using Nomad because Nomad can be configured to use another driver, which is not Docker.

Instead of using Docker or another application running behind, we use Nomad to drive a bunch of Firecracker VMs. So the image we downloaded from the registry builds a file system. The file system is a combination of the content of your image and a Linux kernel that we provide. Then we boot the init that is provided by that kernel. Everything else from there runs as it has been set by your Docker image.

[00:15:01] We need to get traffic to that. The primary role of Fly is to provide the HTTP configuration to get traffic to your application. There is a section called handlers. It may have a TCP handler or an HTTP handler depending on your application. Maybe you want to run a Postgres DB that you want to expose to the public. In that section, you are going to put TCP as your handler. Or maybe you want to run TCP or UDP. Some people are running DNS on Fly, and that's actually possible.

What happens is there is this application, which is one of the reasons I actually joined Fly. Fly Proxy is written in Rust. It runs on our edge servers and on our workers. On the edge servers, it directs traffic back to the workers that are running user applications. Depending on what has been defined in the fly.toml, it decides which port to direct traffic to that is coming from the edge.

[00:16:18] So that's the primary role of Fly. Another thing you can do is use volumes. We added them not long ago. People were asking for them and we added them. Now we have a Postgres database that is available on the platform, but you can also define volumes in that fly.toml.

00:16:41 - Anthony Campolo

Fly volumes are like storage. Is that what volumes are?

00:16:45 - Rugwiro Valentin

Yeah. Storage. The API actually looks like the volumes that are in Docker, but behind the scenes there are LVM volumes on each host. Some hosts have them, but some don't. Nomad decides where to schedule your application depending on which hosts have volumes available.

For the most part, those are the things that you define in Fly. You can also define environment variables in there. But if you have things that are secrets, we recommend that you use Fly secrets. For example, your passwords would not be a good thing to put in that file. So we also have secrets. Basically that's everything that you can define in Fly. But reading the documentation, there are a lot of possibilities, which is why people always surprise us with the things they can do with it.

One example is me. Trying to see what I could do with Fly, I tried to run a Kubernetes cluster on my machine, and I wanted to give it a load balancer on Fly.

[00:17:56] I wanted to deploy a proxy on Fly, and it would use the WireGuard network, that private network Fly uses to connect to its hosts. It would take traffic that's coming from the internet, from a Fly app, and send it back to me on my machine. That's one of the reasons I wanted to try Fly, because it could make something like that possible.

00:18:24 - Anthony Campolo

That's great. I want to get into the WireGuard stuff in a little bit. But before we go any deeper and get any more technical, we should set a couple baselines here and just say, like, why would someone want to do this? Why do you need containers? Why do you need a global network? Why can't I just spin up an EC2 like we've been doing for over a decade? What's the point of all this stuff?

00:18:47 - Rugwiro Valentin

I'm going to speak from my own perspective because before I became an employee at Fly, I was a customer. Running VMs is actually harder than running containers because if you look back in history, I think Heroku were the first people who popularized containers, not as Docker containers, but containers in general. Deploying on Heroku was a very good experience. You just provided the git repository and they did everything else.

When I tried to deploy something on DigitalOcean, most people around here try to use DigitalOcean. It's more popular than AWS. The AWS documentation is notorious. DigitalOcean was easier than AWS, but when I tried it, I spent a lot of time configuring the VM itself, installing packages. On something like Heroku or Fly, you don't have to deal with that. You have an image. If you are an experienced Docker user, you can use that.

But there is this thing called Buildpacks. It was introduced by Heroku later on. They made it open source. It detects the kind of app you are running and just uses the right runner. So if you are using Deno or Node.js, maybe Flask, it detects which one you're using, uses it to build your application, and deploys it. For people who don't want to learn Docker, I think that's a great start.

[00:20:00] The other reason I used Fly instead of going with DigitalOcean or AWS EC2: the team I was working on was very small. It was just me. I was the whole entire team, so I couldn't deal with configuring load balancers or databases. It was too much for me, and all I wanted was to write the code. Discovering Fly basically put in place everything I needed, and all I had to do was provide my code and the configuration.

I think it builds into that philosophy that Heroku introduced, the 12-factor app manifesto.

00:21:03 - Anthony Campolo

Yeah.

00:21:03 - Rugwiro Valentin

The Twelve-Factor App manifesto. When I first discovered it, I ran away with it because when you are a small team, you don't want to deal with those other things. I spoke about databases and load balancers, but there are other things too. Maybe you want a Redis cache. You want a private network for your apps. Maybe you're building microservices and you don't want to expose parts of your infrastructure. If you're on AWS, you are going to have to learn how to configure that. That's a lot of work for someone who is working on a small team. I think that's the main reason that anyone would want to use Fly.

00:21:45 - Anthony Campolo

Awesome. Yeah, it's a lot of really great stuff. We'll link to the Twelve-Factor App methodology in the show notes. That's something that I think we have gotten to the point where a lot of people will just learn to create projects that way, without realizing that it was ever done any other way.

The idea with 12-factor apps is you separate your app from your configuration and from your secrets. You'll have code that can live in a git repo, like a public git repo that anyone can see. When you actually want to run it, then you spin it up on some sort of infrastructure and put in your keys. If you watch lots of programming tutorials these days, that's just kind of how they show you how to do things. That's basically how I learned how to do things in my boot camp. There are a lot of benefits that the Heroku team goes into in the 12-factor manifesto.

[00:22:40] For me, I really like the fact that it makes it possible to decouple the application itself and have other people work on it. There's so much that goes into just getting an application running in an environment. If you can get it so it's agnostic to its environment, then that's really useful in terms of both deploying it in different places and having different people work on it.

00:23:06 - Christopher Burns

One of my biggest questions is, we just spoke about EC2s and just booting up an Ubuntu image on a cloud provider and how Fly is different. Would you say that Fly can be a bit overkill for a very small app? You're a business and you know this app will only be used by ten people. B2B, that sometimes happens. Is Fly a bit overkill for running a tiny API and a tiny project, if that makes sense? Does it make more sense for scaling applications than small applications, or is it no matter what size the application is, it will scale and price to that size?

00:23:45 - Rugwiro Valentin

I might be biased, but I think Fly is the right thing to start with because it grows with you. We have a very generous free tier, but you can grow with it. I started using Fly coming from Heroku, and I think most people are using Heroku for very small apps, APIs, or maybe just a website or web application.

Fly provides the same services as Heroku, but I think it grows with you. There are things that Fly makes easy to implement if you want to add them later on, without migrating from the platform you started with. Most people start on Heroku and later on they outgrow it and go to something else, like a virtual machine provider such as DigitalOcean or AWS EC2. But if you start with your small app on Fly, I think it's not overkill. It's the right size, and this time you don't have to migrate as you grow. Fly will grow with you because of those things that they have made simple that you were going to have to implement yourself on another platform like EC2.

[00:25:03] On Heroku, I think they have that also. But in my experience, it gets very expensive as you grow. You want to add logs and log aggregation, you have to pay extra bucks for that. On Fly, the only thing they tax you for is the resources that you are consuming: the RAM and CPU and, for some apps, the storage.

00:25:30 - Christopher Burns

On Fly's documentation and on the website, it says that it can turbocharge your Heroku apps. Heroku is obviously a company, but what does a Heroku app actually mean? Is it a front end and a back end that has been configured to run on the Heroku platform?

00:25:49 - Rugwiro Valentin

To explain this, I think I'm going to come back to that Twelve-Factor App manifesto. Your app itself could be anything, anything you can define in an image. I said that Heroku is actually using Buildpacks, which I think they invented, but later on many people adopted them and now they are being combined with Docker images to help people who don't want to deal with Docker directly deploy their app.

If I'm going to define a Heroku app, I think it could be anything that accepts traffic and gives back a response. You define a port. From that port, your app is listening and it responds to requests from users. So I think I can define a Heroku app as anything that accepts traffic.

00:26:37 - Anthony Campolo

Yeah, just real quick to jump in with some history here. The Buildpacks were created in 2011, and this is actually really interesting because Docker wasn't created until around 2013. So you're right that this actually predates containers in a lot of ways. Then they've now created something called Cloud Native Buildpacks. So I guess that's probably closer to what we're doing today when we're using them.

00:27:02 - Rugwiro Valentin

I don't actually know the whole history of how they turned into Cloud Native Buildpacks, but I think Heroku played a big part in that. People came to realize that it was a great way to define and deploy applications, especially after microservices architecture was popularized. I don't have a long career in software engineering, but I tried to read the history. Before microservices, the Heroku people used to define their apps as a single virtual machine and deploy the whole thing together.

00:27:39 - Anthony Campolo

Majestic monolith as they would say.

00:27:42 - Rugwiro Valentin

Yeah, I think so. With microservices coming in, I think people wanted modular things and they copied the Heroku model. With the likes of Kubernetes coming in, that's how the Cloud Native Buildpacks were born.

Going back to the turbocharging thing, I think most Heroku apps accept only HTTP traffic. On Fly, you can define a service that takes raw TCP packets or maybe even UDP packets. We can allow you a larger range of ports for your app to listen on compared to Heroku.

00:28:23 - Christopher Burns

That sounds awesome. My next question is regarding GraphQL. You say that with Fly, you can back up Fly with Redis and Apollo to enable rapid GraphQL endpoints. Is that something that you're only going to get if you use that technology stack from the start? Or could you adopt those things later, quite easily with Fly, as in putting Redis in front of your potential already made GraphQL endpoint?

00:28:49 - Rugwiro Valentin

What Fly tries to do is get out of your way so you can build anything you want. I think so. We actually use GraphQL ourselves on the Fly API. I didn't have experience with GraphQL before joining, so sometimes I had to copy queries other people had written for me.

To give you a picture of how Fly is flexible when it comes to the type of APIs you are running, we actually run the Fly API on our own infrastructure. I think they call it dogfooding.

00:29:23 - Christopher Burns

Yes. When you use your own service to build your service.

00:29:27 - Rugwiro Valentin

Yeah. The fact is, we are just behind the scenes. The most important piece when it comes to the kind of traffic we accept on Fly is the Fly Proxy. It's written in Rust and it uses Tokio. I'm hoping there are some Rust listeners to this podcast. You're going to like the fact that we use Tokio a lot.

00:29:50 - Anthony Campolo

Yeah, Tokio is the event loop because I learned about that from Deno.

00:29:54 - Rugwiro Valentin

Yeah. We take the traffic that comes on the edge. There are some parts of the infrastructure that I haven't been able to explore intensively, but the most important piece is the Fly Proxy. It can take, I think, three types of handlers. One handles HTTP and TCP traffic. Sometimes there's TLS. Some people want to handle TLS termination themselves, so we let them do that. Most of the time, we can do that for you. If you are running a GraphQL app, I think it's something you can do out of the box without any changes to your code.

00:30:39 - Christopher Burns

If we were to recommend Fly to somebody who is either really brand new and has built their application and now they need to deploy it, or somebody that has deployed 50,000 applications, you would be quietly optimistic that both parties would have a very good experience on Fly.

00:31:01 - Rugwiro Valentin

I have actually tried to recommend it to some of my friends who are maybe very early in their career. My job is basically, most of the time, I'm working on flyctl, and flyctl is the door to our whole platform. If they run fly launch, then fly deploy, the feedback they give me is it's actually quite easy for people who are starting to deploy their first applications.

00:31:36 - Christopher Burns

Anthony, do you have any more questions?

00:31:38 - Anthony Campolo

Yeah, I was just curious to get a little bit into WireGuard. This is something that I saw in the docs and played around with a little bit. This is a networking kind of thing. As a boot camp student, networking is the absolute farthest thing from what they're actually teaching you. So I didn't really know what it was or why I needed it. I'd be really curious to get a little bit into that.

00:31:59 - Rugwiro Valentin

One of the reasons I wanted to join Fly was the fact that they were using WireGuard. I joined Fly, as most engineers join companies, of course, because they want to make money. But you have to be interested in the technology first. I think that's one way to be happy in your job.

I want to get further in my career concerning networking. I had used VPNs before, but I didn't actually know how to define WireGuard before I joined. To put it in simple terms, I think WireGuard is a userspace networking stack on Linux. Most of the networking is controlled by the kernel, and it adds some latency to your infrastructure. For people like us who are building infrastructure for other people to run on, having something like WireGuard helps us remove that latency. I think the API is very simple.

[00:33:05] So the first and most used implementation of WireGuard, I think there is this WireGuard paper. I don't have a link.

00:33:14 - Anthony Campolo

I can find that and we'll put it in the show notes afterwards.

00:33:16 - Rugwiro Valentin

So there is the WireGuard paper, and there is the first implementation of WireGuard, which is WireGuard Go. We use that userspace networking stack to mesh together all our hosts and our edge workers. At some point, we decided that it would be a good idea to make it available to users so they can connect to our platform.

I want to talk about something I actually have experience with. I'm currently working on Flicker Proxy. I don't know if you have ever used ngrok.

00:33:56 - Anthony Campolo

ngrok. Yeah, I've used ngrok. It's a way to basically tunnel your localhost to the internet.

00:34:01 - Rugwiro Valentin

Ngrok, yeah. I'm currently working on Flicker Proxy. That will give the same experience. For example, if you have a Postgres database running on Fly, each organization has its own private network that's only accessible by apps and users in that organization on Fly. That proxy would allow you to connect to your Postgres database without exposing it to the internet.

There is a WireGuard network that is subdivided per organization, and your apps have access to it. In the WireGuard network, each app has an IPv6 address, and we run an internal DNS to map the names of your apps to those IPv6 addresses.

What we're actually trying to do is make it so you can connect to the apps that do not have that handler defined for them. If you don't define a handler in that fly.toml file, your app is only available from inside that private network. To access it, maybe you want to test. Maybe it's a Postgres database.

[00:35:21] You have to connect to the WireGuard network. Currently, we use the tooling around WireGuard that we use, and you generate a certificate and create an Ethernet device on your machine that you connect through to access that network. It's very complex. I'm trying to use the proxy to leverage WireGuard Go so that people could directly connect to the private network without going through all that gymnastics.

00:35:59 - Anthony Campolo

Awesome. That's a really interesting project. I can see why, once you find out about a company like this, if you're into this kind of stuff, it's just an endless playground of stuff to play with.

The one last thing that I wanted to mention, and we'll drop a link to this, is that we actually have a Redwood Fly integration that has been in the works for quite a while. Kurt and Josh have helped out a ton with this, and this is our first real official Redwood Docker integration, because we've had users who have messed around with Docker using their own application, but we haven't really had a Docker opinion for Redwood. But this is now in the forums.

I wrote up a little tutorial of how to do this. We're still kind of honing it to get an actual Redwood CLI command that will set it up for you. But if you are so inclined right now, today, you can spin up a Redwood app, create a Dockerfile, and deploy it to Fly, and it works seamlessly.

00:36:58 - Rugwiro Valentin

I actually just had to look at the code he had written. I didn't even know what Redwood was. I had to explore it because when I was reviewing the code, I found something new about Redwood. I'm going to play around with it when we are done here.

00:37:16 - Anthony Campolo

Cool. Awesome. Hit me up if you got questions. We'd love to help out with that.

00:37:21 - Christopher Burns

Yeah, I guess my final question is where can the users find you on the internet? If they have any questions, where can we send them on Twitter?

00:37:31 - Rugwiro Valentin

My handle is "a code chef." That's where I like to hang a lot. I'm always on Twitter.

00:37:41 - Anthony Campolo

That is "a code chef." Yes, "a code chef," like a chef who cooks code.

00:37:47 - Rugwiro Valentin

Yep, I think my mom inspired that. She likes to cook, so I thought maybe I'm not a great cook, but I can be a cook. And there is my GitHub handle.

00:38:00 - Anthony Campolo

It's great. We'll have links to that in the show notes. And of course just fly.io if you want to check out Fly. I really recommend any listeners who think that this may be something they need to check out. Fly, as you mentioned, has a very generous free tier. I've got like four or five apps running on Fly right now. It's really sweet. It's really cool tech.

I've learned a bunch just from poking around the docs and trying to figure out how it works, and you did a really awesome job for your first podcast. This is a super interesting conversation. I've already got a ton of things I want to follow up with and look at. So listeners, check out the show notes. We got a lot of links in there. Thank you so much for being here.

00:38:39 - Rugwiro Valentin

Thank you very much for inviting me. Actually, this is like a milestone for me. I'm very grateful to you and Kurt because he is the one who recommended me. I was nervous at first, but I thought everything has to start somewhere, so I went for it.

00:38:58 - Anthony Campolo

Awesome, man. Well, you did a great job.