@mhdev Why do you have one codebase, but deploy them to two subdomains? Is it the same app deployed to both sub-domains? Or does the app just handle routing for two apps using two route groups, i.e.
Route::domain('subdomain1.example.com')->group(function () {
// Subdomain 1 routes...
});
Route::domain('subdomain2.example.com')->group(function () {
// Subdomain 2 routes...
});
Regardless, if you do deploy the application to two separate servers, then you want the database running in the same network to avoid latency. Otherwise, if you host one subdomain on a completely different server and it has to connect to the database over a network, then you may find connections and queries slower than you’d like.
When it comes to deployment, if you are deploying to two separate “sites” then this is going to cause complications as well. You need to nominate one server as the one to run commands such as migrations, but then you also need to a way to halt the deployment of both apps if say, migrations fails. You don‘t want to get in a situation where you deploy the app to subdomain 1, then try and run the migrations, migrations fail, and now you’re left in a weird, inconsistent state where the new code has been deployed to one server (and expecting tables/column that don’t exist because the migrations failed), whilst subdomain 2 still has the old code.
So, my advice is not to over-complicate things if you don‘t need to. Otherwise you just start to introduce more problems than you’re solving.