---
title: "Turbocharge your Heroku Apps with New Turboku"
description: "New Turboku clones a Heroku app on Fly.io without requiring data migration, while the resulting app should be able to use services such as Heroku Postgres or Redis through transferred environment variables. The rebuilt workflow integrates flyctl with Fly.io’s remote builders instead of AWS CodeBuild: it queries Heroku, selects a region, converts config variables to secrets, and generates fly.toml, an ephemeral Dockerfile, and a reconstituted Procfile from the slug and process map. A Phoenix LiveView web launcher wraps the deployment by starting a Fly.io Machine running flyctl, while the CLI is available through flyctl turboku. The launcher also configures webhooks and watches environment-variable changes for automatic updates, whereas the CLI lacks webhook integration; the source reports about one millisecond of added database latency for a US-based app."
---

# Turbocharge your Heroku Apps with New Turboku

[Fly.io](https://yomu.fyi/company/fly-io) · Feb 8, 2022

**Type:** Announcement

## Summary

New Turboku clones a Heroku app on Fly.io without requiring data migration, while the resulting app should be able to use services such as Heroku Postgres or Redis through transferred environment variables. The rebuilt workflow integrates flyctl with Fly.io’s remote builders instead of AWS CodeBuild: it queries Heroku, selects a region, converts config variables to secrets, and generates fly.toml, an ephemeral Dockerfile, and a reconstituted Procfile from the slug and process map. A Phoenix LiveView web launcher wraps the deployment by starting a Fly.io Machine running flyctl, while the CLI is available through flyctl turboku. The launcher also configures webhooks and watches environment-variable changes for automatic updates, whereas the CLI lacks webhook integration; the source reports about one millisecond of added database latency for a US-based app.

## Context

The original Turboku used AWS CodeBuild for remote builds, but those builds were slow. Fly.io also lacked storage attached to its VMs at the time, preventing the builds from running on its own hardware. New Turboku was introduced to make Heroku migrations faster while preserving a simple launcher experience.

## Approach / What changed

The new workflow uses flyctl and Fly.io remote builders to query Heroku, choose a deployment region, copy Heroku config variables into Fly secrets, and generate a fly.toml file, an ephemeral Dockerfile, and a Procfile from the Heroku slug and process map. A Phoenix LiveView launcher runs flyctl inside a Fly.io Machine and adds webhook-based updates and environment-variable monitoring.

## Takeaways

- flyctl turboku accepts a Heroku app name and token, uses an explicit --region when provided or otherwise selects the region nearest to the Heroku app, and generates deployment files from the Heroku slug.
- The web launcher starts a Fly.io Machine running flyctl instead of duplicating the deployment implementation in Elixir, allowing users to authenticate both services and select a Heroku app through a GUI.
- The web launcher supports Heroku webhooks and watches changes to variables such as DATABASE\_URL; the CLI lacks webhook integration. The source measured about one millisecond of added database latency for a US-based app.

**Tags:** [Fly.io](https://yomu.fyi/topic/fly-io), [Heroku](https://yomu.fyi/topic/heroku), [Phoenix LiveView](https://yomu.fyi/topic/phoenix-liveview)

- Source: [Fly.io](https://fly.io/blog/new-turboku)
- Source URL: https://fly.io/blog/new-turboku
- Ingested by Yomu: 2026-09-03T01:26:36.428Z

[Read original post](https://fly.io/blog/new-turboku)