Hi there! Welcome to 2025 Fly.io: even more fun than last year's version. One of the (many) things we're doing is honing in on how we can benefit apps that use AI (perhaps you've heard of it?). More to come on a Cool Thing we're building in this space, but learn more here about how we can help in the meantime. (TLDR: you can run AI-generated code you aren't sure about, real secure and real fast, and plug it into a whole platform of other stuff.)

As usual, we read replies to this newsletter, so tell us what's on your mind!

Product updates

Our Fresh Produce page highlights what we've been shipping lately. Here are a few snippets:

• We've done some important stability updates on our unmanaged Postgres offering.
• There are now automatic sqlite3 backups for Rails applications using Litestream and Tigris and improved support for Prisma.
• The fly_app_concurrency metric is now more useful: every time series is now kept alive as long as the corresponding machine is started, and there's now a new label called `service`, making load of each exposed port in your app recorded separately.

Inside Flyball

• If you're building an app for Shopify (say, one that can be embedded in the Shopify admin or Shopify Point of Sale using App Bridge), we have good news: deployment on Fly.io now looks like this:
  

  Right now, this is only for Shopify apps using the Remix template with the Shopify CLI. Learn more over here.

• We've had a lot of feedback over time that folks really want to play around with our platform before giving us a credit card. Fair enough! We listened and built in a 7-day free trial for new users. If you've been waiting for something like this, come on down and kick some tires.

Feature story: Managed Postgres and Why We're Building it After Saying We Never Would

If there's one product decision in the history of the company we often wish we could revisit, it's how we've handled databases. In 2025, one of the biggest things we're doing is reversing that decision. So, here in this January newsletter, let's read you in to our plan.

For most of the life of this company, we've offered "unmanaged" (or, more charitably, "automated") Postgres. That's a system in which we help you stand up a Postgres cluster, optimized in some ways by us for the Fly.io platform, and then leave you to operate and scale it. We call that feature "Fly Postgres". Sometime in the relatively near future, we'll be superseding it with a managed database, called Fly MPG.

Real quick, let's recap how we got here.

People who have been with us for a long time might remember, we launched Fly.io without persistent storage of any kind. Back in 2020, we were an "edge compute provider", and our platform was optimized for stateless workloads, like image accelerators; we were a "CDN" code code.

All that changed starting in 2021, when two things happened: we launched persistent, directly attached storage, and Heroku launched the surface-to-air missile that blew up their free tier offerings. We quickly became part of an ecosystem of "Heroku alternatives", powered by a sugar rush of Heroku refugees eager to boot up full-stack apps on our platform.

What full-stack developers building on "Platform as a Service" providers want is a turnkey database, a thing they can light up and throw SQL queries at without thinking too much about it. What we had was persistent volumes, with which you could stand up your own database server. There is, obviously, a huge gap between those two things. We filled it with something weird.

The thing about the Fly.io team is, we are ourselves refugees from the managed database problem. Prior to Fly.io, many of us worked on a company called Compose.io (née MongoHQ), which did nothing but managed databases: first MongoDB, and then Postgres. That was, and still is, a whole company on its own. Not the company we were looking to build.

Our users wanted low-drama databases. The up-and-coming managed database companies had their hands full building their own platforms, and we were a bit young to partner with at the time. So instead we built "automated Postgres". Automated Postgres is Postgres that you run, manage, monitor, and scale, with assists from tooling we provide. It feels like a product feature (you create new databases with `flyctl postgres create`), and it sort of is, but under the hood it's not doing anything you couldn't do yourself.

This made sense to us at the time (it still does make some sense). We're building a whole public cloud here, on our own hardware, worldwide; that's a product direction that comes with a metric crapload of hard engineering problems. It did not seem reasonable to add to that all the problems we knew came with shipping a serious managed database.

The trap we set for ourself is glaringly visible in retrospect.

For a full-stack developer booting up a new app on Fly.io, Fly Postgres, our automated solution, had mostly the same UX/DX affordances as managed Postgres. To know it wasn't managed, you'd have to read the documentation, and for modern developers, documentation might as well be fine print. We set RDS expectations with something that was essentially just a bunch of scripts and `flyctl` Go code. When we couldn't meet managed database expectations, users were deeply disappointed.

We've been in the process of course-correcting this for a year now. The fact pattern that led us to do "automated" instead of "managed" Postgres is still there: we're a small team building an extraordinarily ambitious platform, and managed databases are a full-time problem of their own. For a time, we expected to solve this by partnering, with friends at Supabase. But we're not announcing Managed Supabase here, so: clearly that's not happening.

The Supabase story is pretty straightforward. Getting a database running on Fly.io is a Fun challenge that comes with a bunch of engineering tasks: managing multi-node multi-region clusters, dealing with attached storage, doing coordination. These things significantly complicate how you manage and monitor and recover databases. Supabase "natively" runs, for its own "direct" customers, on simpler public clouds where this work is less Fun.

There's an upside to all that Fun! You get highly-scalable multi-region global Postgres databases! But that's not really the core business Supabase is in. They're a Firebase alternative. Postgres is just a detail for them. Making a really, really good Postgres for Fly.io doesn't move their core business forward. And bridging Fly.io's platform to meet Supabase Postgres where it already is doesn't really move our business forward.

So, for the past several months, we've been building our own managed Postgres, Fly MPG.

Two big things make this tractable for us now, where it wasn't back in 2022.

First: last year, we shipped FKS, the Fly Kubernetes Service. We did FKS because we have customers that need K8s interfaces to manage their app stacks, and we did FKS because we discovered a really slick way to map K8s onto Fly Machines; we were nerdsniped. Either way, it's been a good thing, and so now we have K8s, and much of the K8s ecosystem, in our toolbelt. You'll read more about this when we get around to writing up Pilot, our new `init`.

Second: we have financial resources we didn't have back then, and can buy some of Fly MPG instead of building it. Specifically: we've built Fly MPG on Percona, with their backing and support. By running on Percona's K8s operator infrastructure, we get to inherit all the work they do on deployment, dynamic scaling, monitoring, backup, and cluster management.

So what are we going for here? If we pull this off, you'll get a Postgres, and it'll just… continue working for you. And if it blows up because of entropy or hardware failures (or your own fumble fingers), we want to notice before you do and recover everything. That's it.

It has been a long time coming, but after biting this bullet, we're finally closing in on a point where we can offer new applications instant access to a Postgres database that doesn't need developer babysitting. And, yes, this is a table-stakes feature for a lot of other platforms. But rolling this out on Fly.io and Fly Machines has us excited for idiosyncratically Fly.io reasons, not just because we can make them globally fast, but because we can integrate them deeply into our platform and security logic. You'll probably see it early this year from us, but at some point, we're going to make an LLM pull a database out of its butt, and it's going to just work and not be a horrifying security liability. Fun!

Anyways, if you're interested in Fly MPG, it'll be ready to play with within the next month-ish. We read replies to this newsletter! Hit us up if you're interested in early access.