We’ve set up an app on fly using Turboku. Today, we deployed a new version of it in Heroku. The new version, however didn’t seem to have propagated to the fly instance.
In this particular case the deploy happens on Heroku when a git branch is pushed to. This is our staging app; for our production app, we use pipeline promotion in Heroku and need these to be reflected on Fly as well.
Could someone please look into this issue? Can send app details via DM.
Thanks a lot!
I’ll have a look!
Are you using Heroku CI? It is probably better to deploy to Fly in parallel in Heroku than it is to rely on the webhooks. That system has a lot of moving parts and the lag between Heroku → Fly deploy is substantial.
Thanks for your quick response and for having a look, @kurt!
The ease of deployment offered by Turboku is a large part of what convinced us to try migrating our production workload to Fly. Without it, we probably wouldn’t be here posting all these questions 
We’re a small team of Elixir devs and don’t want to deal with DevOps or deployment pipelines. Heroku has everything we need, but is also expensive and comes with multiple technical limitations, which is why we only want to deploy our web servers to Fly. All the deployment processes are well solved in Heroku.
Are you saying that the webhooks on Heroku’s side are unreliable and/or delayed?
Or is it that Turboku, i.e. everything that happens on Fly’s side when they are received, is a system with lots of moving parts and potential lags?
I’m just trying to understand to what degree it makes sense for us to keep betting on Turboku for our production workloads or not.
Thanks a lot for any help in coming to a conclusion here 
Another related question:
Should a fly.toml config file in the app root get picked up when deployed via Turboku?
We deployed an app to Heroku with a fly.toml with changed concurrency values. Subsequent fly config display commands on its Turbokued fly app, however, did not reflect these changes, even after multiple hours.
Turboku uses an old build system we’ve since replaced. We get a webhook, pull down the Heroku slug using AWS CodeBuild, then run some flyctl stuff there to make the deploy actually happen. There are quite a few moving parts, and parts that are a little opaque to us.
If it were me, I would figure out how to deploy separately. It’s very simple to deploy with GitHub actions (assuming you’re using GitHub), for example, and Heroku’s CI can even control the process: GitHub Integration (Heroku GitHub Deploys) | Heroku Dev Center
If you want help getting GitHub actions going we can show you some things!
I do not think we include fly.toml from Heroku. The source code looks like we don’t!
I’m going to keep investigating this today, we might have a relatively simple way to get you setup outside of Turboku, and it will definitely make other peoples’ lives easier too.
I’ve been debugging Heroku issues, found a few. I don’t see any record of a webhook from Heroku, though. I can see that Heroku says they delivered it, but nothing in our logs that says we got it! Which is super weird.
I went ahead and triggered a manual deploy. Will you post here next time you push to Heroku so I can see if the webhook went through properly?
Thanks @kurt, will do!
Also thank you for your honest and straight-forward communication 
Sounds good 
Hi @kurt, we’ve had a couple more deploys on Heroku side. Did any of these trigger webhooks?
Also, any news regarding this?
Curious to learn more
Still haven’t found a way to do a rails console when using Turboku also.
Is Turboku ready for it’s prime time? I am attempting to move redis instances to fly.io, maybe that’s a big no no, because Turboku assumes the Heroku app will still run as is and Redis in fly.io has no external access.
It is probably better to deploy to Fly in parallel in Heroku than it is to rely on the webhooks. That system has a lot of moving parts and the lag between Heroku → Fly deploy is substantial.
I went ahead and triggered a manual deploy
How on earth can I trigger a manual deploy? Running flyctl deploy -a <app-name> renders this error: “failed to fetch an image or build from source: app does not have a Dockerfile or buildpacks configured. See Fly Launch configuration (fly.toml) · Fly Docs”
The background my problem is that my Turboku app refuses to launch the latest version of the Heroku-app. The payload data from Heroku contains the latest (and correct) committ, and the dyno version is also correct.
Hey @arnodirlam Did you get the Turboku setup working? I’ve been running FlyCD for a few months and it’s already powering a few of Fly customers continuous deployment. It doesn’t yet have team support and there’s also a request from one of our premium users to allow promoting a review app to production.
You can check it out or let me know if you’d like to discuss this further.
You need a Dockerfile to build the app. With Heroku you didn’t need to because they use buildpacks. Flyctl doesn’t use buildpacks, and needs a Dockerfile to know how to build your app
This might be out of context because I don’t know if Turboku is still being maintained. What’s your usecase with Heroku? What about giving flycd.dev a try? Let me know if that helps.
Yeah, it’s kind of out of context since Fly.io’s Turboku gives you an interface to deploy Heroku apps without an Docker image.