Turbocharge your Heroku Apps with New Turboku

In early 2020, before we launched our VM platform, we made a little landing page called Turboku. It was a one-click launcher to deploy a Heroku app on Fly.io. It let people try us out without spending time porting an app.

Many of our first customers found us through this page. Sadly, we neglected it for some time, but we’ve come back to give it some love. Today we’re excited to introduce you to New Turboku.

Where we’re coming from

Here’s how Turboku worked: you’d visit the landing page in your browser, authenticate with Fly.io and Heroku, select your coffee-bean recommender from a list of your Heroku apps, and click “Launch app on Fly.” At that point the build was farmed out to AWS CodeBuild.

CodeBuild is Amazon’s fully-managed build service. You specify (or provide) a build environment, source code and commands, and CodeBuild runs it on AWS hardware. Our CodeBuild builders were stock Linux CI VMs with scripts and a sequence of commands to run. We could have run all that on our hardware, except for one small detail: at the time, we didn’t have storage attached to our VMs.

When the build was done, the CodeBuild VM would deploy your convoluted bitter bean chooser on Fly.io.

Bringing it home

You may recall that, like Old Turboku, all our remote builds used to use CodeBuild. This worked, but CodeBuild builds were so slow that we hated subjecting our users to them. Fly Volumes changed the game, letting us run builders on our own hardware, which in turn turbocharged our remote builds.

We want Turboku builds to be fast, too. So we rebuilt Turboku with flyctl integration, skipping third-party services in favor of our speedy remote builders. flyctl lives on your local machine and talks to our API. It’s your CLI command center, and now it can deploy your Heroku app!

Here’s how that goes:

1. You call flyctl turboku with an app name and a token, so flyctl can query Heroku’s API for all the parts it needs to build and deploy a Fly-ified clone.
2. It decides where to deploy. If you specify a region with the --region option, it uses that. Otherwise it chooses the region nearest to your app on Heroku.
3. At this point your app gets created. It has a name and an organization and a preferred region - that’s about it so far.
4. The environment variables from your app’s Heroku config become fly secrets.
5. The Heroku slug gives us the rest of the ingredients we need to concoct and configure a Fly.io app. flyctl generates three files:
   • a fly.toml configuration file
   • an ephemeral Dockerfile, with your app’s Heroku stack (Heroku-20 or Heroku-18) for the base image, and the slug tarball to extract for your app’s source
   • a Procfile, reconstituted from the Heroku process map
6. With your confirmation, the deployment process starts:
   • The Docker image gets built, either locally or on a Fly.io remote builder.
   • We tell a worker host in the chosen region to spin up a VM running your coffee bean thing.

Turboku launcher joins the battle

Now Turboku is turbofast, and we love that you can do it all with flyctl, but we know that some people might see this as (gasp!) a step backwards from a web launcher.

We’re not offended. That’s fine! Because we also love Phoenix LiveView for building Fly.io web launchers.

We’ve already launched a launcher for Livebook, and one for Jupyter Notebooks, and users seem to dig them. Now we have a matching one for Heroku migration too.

When you connect to Heroku and Fly.io through the Turboku launcher, you don’t have to copy-paste your token, and we can give you a nice list of your Heroku apps to choose from. We’ll ask you for some minimal configuration, and then it’s time to smash that GUI deploy button!

Here’s where we’re pleased with our flyctl-loving selves. We could have rewritten the deployment code in Elixir, but that would be wasting good flyctl magic (and hard work!).

Instead, we spawn a Fly.io machine that runs flyctl for us! You can sit back and watch as it massages your Heroku app into shape for deployment on Fly.io. Turboku handles everything from creating the Dockerfile to building your app on our remote Docker builders.

The video above is in real time. It’s hard to catch without pausing, but it takes about two seconds for the launcher to spin up a new VM running flyctl. By about eight seconds in, it’s created and configured the app, and started the deploy process. It calls out to a remote builder and starts transferring Docker build context.

Granted, we’re not done yet. The actual build and the creation of a VM running your app on a worker take a further finite time.

A byproduct of this process is an app with a name like flyctl-host-personal-1234 . When the initial Turboku deploy is finished, this app sits around (for free) waiting for webhook updates or another Turboku deploy.

Taking stock

New Turboku makes migrating from Heroku faster and, if we say so ourselves, more elegant.

Turboku (still) doesn’t delete your Heroku app from Heroku. That part is up to you. You can keep it up in both places, if you really want to! And if you’re using Heroku’s Postgres with your app, or an add-on like Redis, its Fly.io incarnation should be able to use it too, because Turboku brings your app’s environment variables over with it.

As with Old Turboku, the new Turboku launcher sets up webhooks on the Heroku app for automatic updates on new Heroku deploys. We also watch for changes to environment variables like DATABASE_URL, which Heroku promise that they will change on you.

While the connection to your Heroku database has to happen over the internet, it should be very fast - we measured about a millisecond of added latency for a US-based app. The special sauce for this is that non-enterprise Heroku apps all live either in Dublin or Virginia, so Turboku will deploy in our closest region (London or Virginia) to be next door, unless you specify a different region.

But let’s face it: if your Postgres is still stuck in one region, it’s hard to take advantage of our global edge network to suggest sophisticated beans in Singapore. We don’t have a similarly painless solution for cloning and syncing databases! 🙀

Obviously, we hope that once you’ve tried Fly.io, you’ll be convinced it’s worthwhile to make the jump over and run Globally Distributed Postgres!

If you have a Heroku app you’d like to bring closer to your users, give the Fly Turboku Launcher a spin.