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
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.
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!)
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.