I am building a service with Symfony and Doctrine. I want to be able to have two or more totally separate instances of my service for different domain names (not subdomains on a main domain!) and different admins. Each instance has its own database, CDN, etc. But they exist on the same server or cluster. Which, as I understand it, is a multi-tenancy problem.

I want to setup multi-tenancy such that:

• I have a single codebase. All tenants get the exact same codebase and are on the same version.
• Every tenant has their own database for both security reasons and simplicity.

I've thought about this quite a bit, and it seems like the easiest way to achieve this is by passing environment variables (chiefly DATABASE_URL and perhaps TENANT_ID) via my webserver, which is Caddy. I verified in a minimal setup that passing env DATABASE_URL=whatever for each host does work; a different database is definitely accessed depending on the URL hit.

(Edit: Thinking about it some more, it could be better to set a single environment variable in the Caddy configuration for each host that contains the file path for a .env file which contains more environment variables for that tenant. So you could end up with 1-50+ .env files. You have more encapsulation that way, which could be good or bad. Just depends on what is easier to implement in Kubernetes; is it easier to add/delete a .env file when creating/removing tenants, or is it easier to manage all the environment variables in Caddy?)

It needs to be a single codebase, because I want to deploy my service via Kubernetes to allow for horizontally scaling up and down depending on demand, so the app container needs to be identical so that the web container can route requests to the correct location, and it doesn't matter which node the load balancer redirects the user.

This way, the code remains the same regardless of whether there's a single tenant or 50.

(Edit: You would also have a tenants table in your app with one main "Control App" that has access to all the tenants for management purposes. It would have a tenant ID and a domain name column at least, I would think.)

Of course you need to consider Doctrine migrations and other commands per tenant, as the standard commands will not run against the right DB unless you prefix them with the right environment variables. There is probably some extra code to write to make it easier to run migrations/other commands. But before I think about that, I want to know if this approach is viable.

I'm an absolute beginner at Kubernetes, but through a lot of research, this is what I came up with.

Is there any reason this is totally stupid and won't work in a production environment? I couldn't find any official docs on this aside from this, which doesn't address my problem.

Passing environment variables with credentials in the webserver configuration is a little concerning to me, but the DATABASE_URL needs to live somewhere.