Check out this link, they literally have the exact same issue that was solved.

http://stackoverflow.com/questions/14524181/laravel-4-multiple...

The second answer is a lot simpler than the first, you might want to explore doing that instead of the chosen answer.

Thanks for the reply @ayyoboro, but non of the answers deals with the problem of migrating tenant DBs through commandline.

On a side note, I have successfully managed to use tenant DBs within the app, the only problem is about migrating them.

budhajeewa said:

Thanks for the reply @ayyoboro, but non of the answers deals with the problem of migrating tenant DBs through commandline.

On a side note, I have successfully managed to use tenant DBs within the app, the only problem is about migrating them.

In the accepted answer of that thread, there is a second update that explains how to do that. It is actually spot on with what you ideally wanted:

Update 2

The laravel developers are amazing and I should have definitely got the urge to check this out sooner than later. You can do migrations and seed on any database connection you've created.

artisan migrate --database='userConnectionName' 
artisan db:seed --database='userConnectionName'
Looking at Barry's answer, that is probably a good deal simpler than extending the DatabaseManager.

If you want to see all the options for these commands just run:

artisan help migrate
artisan help db:seed

I don't believe there is a way around adding the extra connections in database.php at that point.

The config settings can be modified at run time (the changes don't persist between connections or write to the file system). Because of this we can modify the DB connections at run time and have them available to the migrator. This is what I've done for this in the past. I wrote about it in this thread: http://laravel.io/forum/09-13-2014-create-new-database-and-tab.... Have a read there and hopefully it helps!

ayyobro said: I don't believe there is a way around adding the extra connections in database.php at that point.

Unfortunately, there is exactly what I am looking for, ayyobro. :(

Imagine I have some hundreds of tenant DBs, and I have managed to update the tenant DB's name at the login time; I feel it is a waste of time and resources, and an unscalable "solution" -- work around? -- to define separate database connections for migration purpose only.

@JohnathonKoster: Does your solution work in commandline migrations as well?

Nice looking package. And yes, I've used that method successfully with the command line.