@iampopal, you’re seeing the first because our proxy just picked it as the closer to you. You fly.toml, from the perspective of our proxy, thinks both processes are the same app so doesn’t matter which it routes to, it should be fine. But knowing your use case, that’s not true.
Managing multiple apps, each for a customer can be challenging indeed, especially with deployments and I totally can see why you’d want to make all machines on the same host so here are some notes about it:
You need a way of routing URLs per customer
Say you have two stores: App Store and People Store. Whenever someone goes to restless-firefly-7869.fly.dev you’'d need to know how to serve each machine. If you are going to provide your customers with custom domains that makes it slightly easier, you could use Fly-Replay
It could be something like this: if your app detects the user comes from app-store.com and the machine is not the correct one, respond with Fly-Replay: instance=correct_machine_id.
But as you can see it requires your app to be changed to do this Fly.io specific thing.
Another way you can handle this is a simple nginx/caddy or any other reverse proxy setup if you’d like but I’d still recommend Fly-Replay because it’s on proxy level so wouldn’t cost you CPU cycles.
Do security concerns your use case?
Both machines will be on the same app which means they share some resources such as environment variables and secrets. If this is something that would be concerning I’d recommend creating two apps on different networks with fly apps create --network any-string-goes-here.
This is getting too complicated!
If you feel like the recommendations above are not a good fit for a simple use case, I would recommend you to try to handle this at application level. You could add some code that just changed the DB connection based on URL or something like that.
Your use case feels like our Web Terminal
Each customer who goes to fly.io/terminal gets a secret app with a secret machine under a private network, that’s how our web terminal works. We had to do a bit of management on our side to handle thousands of machines being created. But in your use case you seem to need two apps for now, maybe a simple enough solution is just making a CI to deploy things on both?