I would check out this page, near the bottom.
It walks through the steps to get it deployed. This does use a buildpack. If you want a docker image, you can create a
Dockerfile next to the fly.toml and it should be picked up. You may need to remove the buildpack from the build step and point to the Dockerfile.
You can also delete the fly.toml and run fly launch again and see if it generates it withou the buildpack, if that is the issue.
I had no issues with buildpacks when I have used them in the past. I typically use Docker now though.
A sample docker file might look like -
COPY main.py ./
COPY /tgbot ./tgbot
CMD [ "python", "./main.py"]
I don’t know what is in the /Procfile.
Procfiles are support in Buildpacks I think, but that may be V1, and not machines? Someone from fly would need to answer.
But if they are processes and different commands, you can use the process group setup.
web = "bundle exec rails server -b [::] -p 8080"
worker = "bundle exec sidekiqswarm"
In your fly.toml, you can add a process section for each one, and define your CMD. The CMD will replace the CMD in the Dockerfile. Or be added to the ENTRYPOINT and joined too it.
Every process will become a separate VM that has its own life cycle (auto start, scale, shutdown, etc). And can be scales horizontally and vertically separate.
The only downside to this approach is all VMs within the app share the same ENV files, and the Dockerfile may be more complex to handle supporting all processes, even if its only running one.
For example I launch a node container to run a compiled Go app, because the backend database GUI is in Node. So the image is larger for the Go app. And the Go app is exposed to all the ENV for the Node app.
Every process group needs a different port, because the proxy knows about the app, but not the process groups. So web might be 8080 and worker might get exposed on 3000. It needs atleast an internal port. You can communicate with process groups using internal networking,
See more details