Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.
So my answer to multitenancy is that each tenant will literally get their own instance (I fully expect them to request this level of segregation anyway, and it makes a lot of things simpler). So there'll be a client app that allows them to sign up and pay, and this will run a queue system which drives Forge/Ploi or similar to set up a new tenant.
So far, so good. But the concept I'm struggling with is the methods that the client might instigate certain events (for example, creation of the first account, changing service level, etc). Should it be push or pull; how would it be secured.
I think I'm settling on the instances calling home periodically to check for queue items, and then importing and acting on them, perhaps reporting back to close them.
If anyone's interested, I'd welcome thoughts, ideas or discussion on how best to achieve this!
@kurucu I don’t really understand the problem. If each customer has their own instance of your application, then what is the need for “calling home”?
If they change the service level, then they change the service level. The application instance should allow/deny features based on the service level the customer’s selected.
Aha, then I think I have not explained myself well.
So there are any number of tenant instances, all running the same app code on their own servers (all owned, hosted and run by me, for them).
Tenants can set up, tear down, and update billing in a central (different) Client app, that serves everyone.
They they make a billing change (e.g. add more projects) in the central app, the tenant instances need to know about this change.
use a simple post request with a shared secret?
It does mean that you need to come up with an api for communication
I think this is my preferred approach so far (having thought about it a fair bit!). I don't mind the API side too much - but what about, for example, changing stale keys across 100 tenants?
you can pass a unique key per tenant when it is provisioned. aging out the key would seem unnecessary to me as these are only ever sent over private connections and using tls ?
However you could have a method to send a new secret to the tenant using the existing secret
@kurucu I really don’t understand why each tenant is a separate application if the billing logic is centralised and you’re running the servers any way. This approach completely defeats what “multi-tenancy” is supposed to solve. Multi-tenancy exists so you don’t have to maintain multiple instances of the same software.
The term "software multitenancy" refers to a software architecture in which a single instance of software runs on a server and serves multiple tenants.
What you’re doing isn’t “multi-tenancy”.
Please or to participate in this conversation.