After we have created an app using Turboku, how can I proceed from here?
For example, how can I attach a volume to my app? How can I have a Dockerfile with the image that is used to run the app? How can I edit the application files that is brought over from heroku?
When you run Turboku by then you will have a regular Fly app with one more magic: it syncs code and SECRETS with Heroku. In case you don’t want this to happen you will want to go to your Heroku app and disable webhooks that point to Fly.io
Now you’d want to set up deployments on Fly directly. To do this first I’d recommend you go o your project folder and run fly config save -a <your app name> so you have a fly.toml ready for you.
By now you can do everything as if there’s not Turboku. Create and attach volumes using our CLI, create a Dockefile and deploy your app again for it to be used…
That’s something not quite possible, using Turboku you pretty much have a copy of your latest state from Heroku updated via webhooks. If you aim to have changes specifically for Fly I’d suggest detaching the webhooks and deploying to Fly directly.
May I ask if your app uses a database?
Hopefully these informations will be helpful for you 
Indeed, it is very helpful.
Yes, my app uses mysql database, and it doesn’t accept postgresql.
Interestingly, I could not find a webhook for that from my app. Also, the Turboku interface shows a list of apps from my Heroku account but not the full list, I had to edit the dom (the select element) to add it in and bring it to fly.
One more thing, the current fly engine doesn’t work well with php-fpm bought from heroku, as the php-fpm starter script detects the memory of the host by looking at /sys/fs/cgroup/memory/memory.limit_in_bytes, while heroku gives the right number, fly always gives 9223372036854771712 bytes (9223372TB wow), which is incorrect. Not sure where to send this feedback to or if there is an easy fix with dockerfile. This is why I asked how can I change the application files. I guess I had to so some sed for this to work at this point.
Thanks for the help
Thanks for this feedback, I will add this to my list of things to look up!
Oh thanks for reporting that, we might need to take a look at this too
Interesting!
We can see here where cgroup appears in the PHP Heroku buildpack: Search · cgroup · GitHub
It looks like it may call this little autotune.php file which calculates a values that is eventually set to as a WEB_CONCURRENCY environment variable.
At some point, the WEB_CONCURRENCY env var sets max_children in php-fpm.
Here’s the important part: It looks like if we set the WEB_CONCURRENCY env var ourselves, it skips the automatic calculations. (example here)
So, we can do something lazy like pretend a PHP request takes like 100m of ram, and divide by the amount of MB of ram in an instance, and use that value to set WEB_CONCURRENCY ourself.
For example, 1gb ram Fly instance would be 1000mb (we’re being lazy here, remember), so we’d set WEB_CONCURRENCY to 10. (IDK how env vars are set in turboku, I haven’t touched that stuff yet personally!)
Thanks, this is quite a neat workaround.
However, I think the root of the issue here is that fly vm/docker is giving the wrong (or not suitable) information in cgroup file that needs to be fix. There could be a more apps/systems that relies on that file.
That is the default value for /sys/fs/cgroup/memory/memory.limit_in_bytes. You’ll get the same value on any linux machine where a cgroup is not restricting system memory.
Heroku’s buildpack is doing a buggy thing here. The right way to check memory limit is to get the equivalent of min(group_limit, system_memory). The best thing to do here is to submit a PR to Heroku that fixes the buildpack behavior.