I am trying to bend my mind around getting silverstripe to work in a Software as a service configuration where essentially there is one set of silverstripe files, but many databases and different themes, i.e.

client1.domain.com
client2.domain.com
client3.domain.com

all share the same SS3 core files (inc mysite) but each has a different theme, asset folder and database.

The purpose is so that when we upgrade the software (i.e. our modules within mysite, etc) then we only have to do it to one location and not to 100 different locations. We can the run a batch /dev/build command to update every site.

Do you think this is possible?

Thanks for any input!

This may not be an appropriate solution, but I thought it was worth a suggestion - could the subsites module do what you need? https://github.com/silverstripe/silverstripe-subsites

No unfortunately not, needs to be separate DBs for a number of technical and legislation reasons.

Another thought I had, would be to make exact copies of the site (i.e. all the files, copied from a core packaged zip that gets unpacked), then have some sort of "patch" or "package~ updater that (a lot like wordpress) downloads the latest edition, unpacks it, uploads the files and runs a dev/build. Has this been done in SS?

I've not done anything like this, but we considered the SaaS approach for a previous project. The idea we had was to simply use our _ss_environment.php file to switch out which database and assets folder is being used based upon the current domain name. Something like:

$domain = getenv(DOMAIN_NAME); // 'setEnv DOMAIN_NAME www.sitex.com' in vhost config
switch($domain) {
	case 'www.site1.com':
		define('SS_DATABASE_NAME', 'site1');
		define('ASSETS_DIR', 'assets_s1');
		break;
	case 'www.site2.com':
		define('SS_DATABASE_NAME', 'site2');
		define('ASSETS_DIR', 'assets_s2');
		break;
}

Cool - sounds good. We will extend this to do a DB look up to get the switch statement (as there are going to be 100s of accounts) then probably store it in a session so we dont have double hit the DB everytime. Didnt even know that existed! Going to help our dev process too.