Chances are, unless you nginx is doing something fancy or you need a feature of it for your purposes that Fly Proxy can’t handle, you can just use the built in Fly proxy.
The backend and frontend would be separate apps, most likely folders in the same repo, or separate repo each with their own fly.toml and Dockerfile.
You would configure and scale each independently.
There is a concept of process groups that you can look up, which lets you use one Dockerfile to deploy two separate apps with different port configurations. And many commands can target a individual process within a app. But this is typically used for more sidecar style applications, like Sidekick with Rails.
I use Docker Compose locally for testing, including mimicking some features of the fly proxy. When I deploy, I go into the folder in my monorepo of the app that I am trying to deploy.
I then run the fly command from that folder. The same Dockerfile used for Frontend or Backend, is also used for deploying to fly. I also use Nginix and Redis locally, but on fly.io, I use the built in proxy, and Upstash managed redis.
I did the “backend and frontend as separate apps” approach and that works. However, my team wants to go with a hybrid approach: serve React build folder through Django’s static files.
Do you see this approach as possible? So far we only succeed to do it locally, but we haven’t been able to deploy it successfully in Fly.io.