We’re building something ambitious at Fly.io: a new public cloud, running on our own hardware all over the world, built to make it easy to run apps close to users everywhere.

​

Fly Machines are containers running under hardware virtualization in our cloud. They’re so lightweight that, once created, they can be stopped and clean-started fast enough to respond to an incoming HTTP request. Unlike “function-as-a-service” platforms, they don’t have time budgets: you can run a Fly Machine for the duration of a single request, or for weeks or months.

​

The Fly platform connects Fly Machines to an Anycast network routing traffic into over 30 regions on all but one (guess) continent. There’s no load balancers to set up or network rules to write: you launch a Fly Machine and you’re live, worldwide, immediately.

We think they’re pretty neat, and we’re looking for people to work with us on them.

​

This Role

​

​

We’re looking for engineers to join the team working on Fly Machines and their orchestrator, flyd.

​

Most of this is Golang code. It has an elegant structure. On thousands of beefy “worker” servers in our fleet, each flyd is solely responsible for its own state — every server is the source of truth for its own workloads, without a global top-down orchestrator. Under the hood, flyd is a specialized database server that durably tracks the steps in a series of fine state machines, like “create a Fly Machine” or “cordon off an existing Fly Machine”.

​

Fly Machines connect up with our network infrastructure, which is written primarily in Rust, through a state distribution system called Corrosion, which is an open source project you can check out for yourself.

​

If you’re ambitious, you can also check out our infra-log to see every way this can go wrong, because being right in the middle of all this is the job you’d be signing up for.

​

What We’re Doing Now

​

​

Fly Machines are making a beeline towards enabling two big internal use cases for us.

​

The first is MPG, our upcoming Managed Postgres offering. Being a platform for managed database means being good both at managing compute resources and, especially, storage — and we’re chasing down a bunch of interesting ideas there. But more than anything else it involves making machines move, and improving and tooling up machine migration so we can transparently shuffle workloads.

​

The second use case is LLM execution environments. A crazy thing happens when you give a hallucination-prone LLM access to a secure, ephemeral environment with which to actually compile and run code: the LLM actually gets good at coding. Making this work well for customers means giving Fly Machines safe access to APIs and secrets without exposing them to untrusted code, and managing gigantic pools of machines.

​

We think these are fun problems. We can’t promise they won’t be stressful problems. If that’s a kind of bittersweet you’re interested in, let’s see if we’d work well together.

​

How We Hire

​

​

This is a senior, fully-remote, full-time position.

​

In order to optimize for pay equity, Fly.io doesn’t negotiate salaries. We have standardized salaries for each employee level. The salary for this role is $190 to $225k USD, depending on level. We offer competitive equity grants with a long exercise window. We provide health care benefits, flexible vacation time (with a minimum), hardware/phone allowances, the standard stuff.

​

Our hiring process may be a little different from what you’re used to. We respect career experience but we aren’t hypnotized by it, and we’re thrilled at the prospect of discovering new talent. So instead of resumes and interviews, we’re going to show you the kind of work we’re doing and then see if you enjoy actually doing it, with “work-sample challenges”. Unlike a lot of places that assign “take-home problems”, our challenges are the backbone of our whole process; they’re not pre-screeners for an interview gauntlet. (We’re happy to talk, though!)

​

There’s more about us than you probably want to know at our hiring documentation.

​

If you’re interested, mail jobs+platform-machines@fly.io. You can tell us a bit about yourself, if you like. Please also include your location (country), and your Github username, for work sample access.

We’re building something ambitious at Fly.io: a new public cloud, running on our own hardware all over the world, built to make it easy to run apps close to users everywhere.

​

Fly Machines are containers running under hardware virtualization in our cloud. They’re so lightweight that, once created, they can be stopped and clean-started fast enough to respond to an incoming HTTP request. Unlike “function-as-a-service” platforms, they don’t have time budgets: you can run a Fly Machine for the duration of a single request, or for weeks or months.

​

The Fly platform connects Fly Machines to an Anycast network routing traffic into over 30 regions on all but one (guess) continent. There’s no load balancers to set up or network rules to write: you launch a Fly Machine and you’re live, worldwide, immediately.

We think this is pretty neat, and we’re looking for people to work with us on it.

​

This Role

​

​

We’re looking for engineers to join the team working on our Anycast network and its core component, fly-proxy.

​

Our networking stack is almost entirely Rust (with a smattering of eBPF C). fly-proxy is a relatively complex and advanced async Rust codebase, built on Tokio and Tower. We automatically track and balance loads for hundreds of thousands of applications deployed worldwide, maintaining independent execution pools for each customer. We take incoming traffic at edges and backhaul it over HTTP/2 to the closest machine, which changes in real time.

​

Fly Machines, which are built primarily in Golang, connect up with fly-proxy through a Rust-based state distribution system called Corrosion, which is an open source project you can check out for yourself. Corrosion does SWIM gossip to drive a CRDT-structured SQLite database, with an end result that any component on any host in our fleet can get a real-time picture of what’s happening by making a native SQLite query.

​

If you’re ambitious, you can also check out our infra-log to see every way this can go wrong, because being right in the middle of all this is the job you’d be signing up for.

​

What We’re Doing Now

​

​

There are two big projects happening with our network stack right now.

​

The first is regionalization. We’ve gotten as far as we’re going to get with a single flat global topology. The next iteration of our proxy architecture runs multiple Corrosion instances, for each region, and publishes summary information to the global cloud; for a deep-cut analogy, think of how OSPF does areas. This has profound implications on how our proxies handle things like balancing and fly-replay.

​

The second big project is evolving our private networking primitives. This will involve giving Fly Machines stable addresses that can be moved from hardware server to hardware server, and providing finer-grained access control, so that it’s even easier to run untrusted workloads on Fly Machines without having to do fiddly things inside of Fly Machines.

We think these are fun problems. We can’t promise they won’t be stressful problems. If that’s a kind of bittersweet you’re interested in, let’s see if we’d work well together.

​

How We Hire

​

​

This is a senior, fully-remote, full-time position.

​

In order to optimize for pay equity, Fly.io doesn’t negotiate salaries. We have standardized salaries for each employee level. The salary for this role is $190 to $225k USD, depending on level. We offer competitive equity grants with a long exercise window. We provide health care benefits, flexible vacation time (with a minimum), hardware/phone allowances, the standard stuff.

​

Our hiring process may be a little different from what you’re used to. We respect career experience but we aren’t hypnotized by it, and we’re thrilled at the prospect of discovering new talent. So instead of resumes and interviews, we’re going to show you the kind of work we’re doing and then see if you enjoy actually doing it, with “work-sample challenges”. Unlike a lot of places that assign “take-home problems”, our challenges are the backbone of our whole process; they’re not pre-screeners for an interview gauntlet. (We’re happy to talk, though!)

​

There’s more about us than you probably want to know at our hiring documentation.

​

If you’re interested, mail jobs+platform-proxy@fly.io. You can tell us a bit about yourself, if you like. Please also include your location (country), and your Github username, for work sample access.

We’re building something ambitious at Fly.io: a new public cloud, running on our own hardware all over the world, built to make it easy to run apps close to users everywhere.

​

At Fly.io, the infra ops team builds and maintains the platform and tooling that allow our product engineers to build some really amazing stuff for users. In particular, that means making it so that product teams (machines, managed postgres, proxy/networking, etc.) can operate the products they’re building well. It also means keeping the servers running (along with all the important software on those servers).

​

Just like in every engineering role at Fly.io, as an infrastructure engineer, you’ll need to be user focused to the extreme. The only difference is, in the infra role, your user is other product teams (rather than customers who deploy their apps on Fly.io’s platform). In this role, you’ll have a ton of autonomy and direct your own work — you’ll use your user focus to help guide your work, so you’re working on the most impactful things.

​

Some things you might work on:

​

• Setting up and iterating on tooling for metrics/monitoring and alerting, so that product teams can reliably operate their products.
• Writing lots of “glue” code integrating various tools in ways that are valuable (and easy to use) for product teams.
• Piecing tools together in clever/new/interesting ways to solve product team needs.
• Helping refine capacity planning, and automating quick burst capacity (for when our capacity planning isn’t quite right).
• Building the underlying hosting infrastructure that allows product teams to run multi-tenant workloads without having to worry about individual hosts.
• Responding to hardware failures, and interfacing with our provider to get hardware changed out as needed.
• Making it easy and safe (and as automatic as possible) to make changes to critical system components (like upgrading the OS on our servers).
• Working with our upstream providers to debug hairy networking issues.

​

This role will be a good fit for you if:

​

• You’re good at figuring out what product teams really need in order to build and operate their products.
• You know core infrastructure tech concepts and tools (linux, networking, etc.).
• You’re good at debugging, figuring out weird stuff, picking up new tools and ways of doing things, and you can do it all under pressure.
• You can work autonomously — you can look at a big problem, and figure out a small piece to work on next, without being told what to do, and you can see the long-term vision of where to go after that.
• You are very effective at written communication. You can write concisely, focusing on the most important points, and you consider your audience.
• You are good at sharing ownership and working on a team.
• You move fast. This absolutely does not mean you over-work yourself (we want you to work normal human hours and take care of yourself), but it means that you’re decisive, work with purpose, and don’t let yourself get bogged down in less impactful work.

​

You’ll know you’re succeeding in your job if:

​

• You’re always thinking about how folks on the product teams are using the tools you’re building, and what problem you’re solving for them.
• Your solutions are broadly useful. You probably had one small initial use-case in mind, but the thing you built gets used again and again, by several different product teams.
• Product teams at Fly.io are able to build new features fast on top of the infrastructure you’ve built.
• Product teams at Fly.io are able to operate their products effectively. They know when their product is working (and when it’s not), and have the tools they need to quickly solve problems.

​

More details

​

This is a mid-level to senior, fully-remote, full-time position.

In order to optimize for pay equity, Fly.io doesn’t negotiate salaries. We have standardized salaries for each employee level. The salary for this role is $134 or 190k USD, depending on level. We offer competitive equity grants with a long exercise window. We provide health care benefits, flexible vacation time (with a minimum), hardware/phone allowances, the standard stuff.

​

Our hiring process may be a little different from what you’re used to. We respect career experience but we aren’t hypnotized by it, and we’re thrilled at the prospect of discovering new talent. So instead of resumes and interviews, we’re going to show you the kind of work we’re doing and then see if you enjoy actually doing it, with “work-sample challenges”. Unlike a lot of places that assign “take-home problems”, our challenges are the backbone of our whole process; they’re not pre-screeners for an interview gauntlet. (We’re happy to talk, though!)

​

If you’re interested, mail jobs+prod-infra@fly.io. You can tell us a bit about yourself, if you like. Please also include your location (country), and your Github username, for work sample access.

We’re building something ambitious at Fly.io: a new public cloud, running on our own hardware all over the world, built to make it easy to run apps close to users everywhere.

​

Don’t just skim this post. There are lots of different kinds of UX engineers, and we’re on the hunt for someone very specific.

For the past five years, we’ve been working on a public cloud platform that that has the ergonomics of “platform as a service” offerings like Heroku, but the power, flexibility, and economics of a hyperscaler cloud. Those goals are in tension, which makes working on UX here especially challenging.

​

This Role

​

A UX engineer at Fly.io is a primarily an Elixir developer. The work is primarily front-end and interaction design.

But Fly.io isn’t primarily written in Elixir, and every decision we make from button sizes to distributed consensus algorithms is driven by user needs. So you won’t just be thinking in Elixir: our CLI is a Go program, as is our API, and other components are in Rust and Ruby. You won’t own these components. But you’ll need to understand them, and to drive changes in them. It’s a daunting problem, so this is a senior role.

​

Fly.io has historically been a CLI-first company. The CLI isn’t going anywhere, but our emphasis is shifting. So, when we think about UX development, what’s in our head is: someone who makes sure our team is shipping, quickly, with a strong browser-based interface.

​

Finally, Fly.io is weird about product management, and that’s especially the case with UX. You will not have a PM to rely on for feature breakdowns or roadmaps. You’d need be prepared to come out of the gate with strong ideas about what’s going to make our users lives better, and what’s going to make them happy in the long run.

​

What We’re Doing Now

​

We’ve got two big product pushes happening in 2025.

The first is MPG, our upcoming Managed Postgres offering. Managed databases let users create databases and then not worry about them. Databases are complicated: lots of knobs, lots of flashing lights. We need the knobs simplified and the lights curated, so that MPG is telling the story users need to here, and not confusing them with other stuff.

​

The second use case is LLM execution environments. A crazy thing happens when you give a hallucination-prone LLM access to a secure, ephemeral environment with which to actually compile and run code: the LLM actually gets good at coding. We’ve got a handle on the core engine of generating code and getting it to run safely. But what is the UX of that as a product? What does it mean to start a new LLM-driven project, and what does it mean for it to be finished, put into production, maintained, and extended? We’re looking for somebody with takes.

​

Seriously, This Is A Fussy Role

​

We’re not afraid to talk you out of it. You’d need to be:

​

• Attuned to the needs of the kinds of users that ship things on public clouds. Check out our public community if you think that’s easy to do consistently.
• Relentlessly focused on shipping. We work with 2-week horizons here; 6 months from now might as well be the year 3000.
• Rock solid with Elixir/Phoenix. Unafraid of Go.
• Able to keep a model in your head of ambitious features that are implemented across many layers of software, many of which you don’t own; you have to be willing to get your brain dirty.

​

To us, all these things that make this job complicated also make it interesting. If we’ve held your attention this far, let’s see if we can make something work.

​

How We Hire

​

This is a senior, fully-remote, full-time position.

​

In order to optimize for pay equity, Fly.io doesn’t negotiate salaries. We have standardized salaries for each employee level. The salary for this role is $190 to $225k USD, depending on level. We offer competitive equity grants with a long exercise window. We provide health care benefits, flexible vacation time (with a minimum), hardware/phone allowances, the standard stuff.

​

Our hiring process may be a little different from what you’re used to. We respect career experience but we aren’t hypnotized by it, and we’re thrilled at the prospect of discovering new talent. So instead of resumes and interviews, we’re going to show you the kind of work we’re doing and then see if you enjoy actually doing it, with “work-sample challenges”. Unlike a lot of places that assign “take-home problems”, our challenges are the backbone of our whole process; they’re not pre-screeners for an interview gauntlet. (We’re happy to talk, though!)

​

There’s more about us than you probably want to know at our hiring documentation.

​

If you’re interested, mail jobs+ux@fly.io. You can tell us a bit about yourself, if you like. Please also include your location (country), and your Github username, for work sample access.