Spin Multitenancy

[akulmehta]

Let's say we have an app which is currently built on Spin. Currently when we provision or deploy the application we do so for only 1 client i.e. 1 server. Would it be possible to have a Spin command so that Spin could be used to create the same application for several clients or deploy updated code to multiple servers?

I think this would be very powerful for building SaaS where isolated VMs are required (either for load reasons or privacy reasons).

A related discussion #137 talks about multiple apps to be deployed on the same server, but I am talking about the possibility of having the same application deployed for different clients (maybe via multiple .env files) to different servers?

[jaydrogers]

Stay tuned 😃

We're currently testing SelfHost Pro. This is for if you want to sell a self-hosted software and have the user set this up themselves.

We've also done "managed deployments" where we built our own tooling to ship the same SaaS to managed customers (managed by the SaaS) company: https://www.youtube.com/watch?v=TEnO2jPwt-c

[akulmehta]

@jaydrogers I went through the video and it seems to be doing what spin is basically doing. However, if we have different clients with different .env settings, can we still use this approach? I am thinking there should be something like "Spin Manager" which can take a spin application and if you provide it another yaml file or some other .env files it will automatically use this yaml to push the code to all the client servers.

Here is a basic thought on how it would be used:

1] spin manager provision - when run would provision a new server. However, instead of saving the keys, and the server information into the .spin.yml file, it stores it somewhere else, let's say .spin.manager.yml file. Therefore the .spin.manager.yml file stores all the servers onto which the code needs to be deployed. You can specify some .env file as well to use as a specific .env file for this server, which it would save in a separate folder or a parent folder with the code for the project in a sub folder.

2] spin manager deploy - when run would deploy the code to all the servers in the .spin.manager.yml file.

4] spin manager delete --server="xyz" - should delete the code on a specific server "xyz"

4] spin manager remove --server="xyz" - if we lose a client, then we would probably want to remove their server from getting updates. In this case, this command could be used to remove a specific client (maybe based on server name) from the .spin.manager.yml file.

Just putting my thoughts out there. If these things will be handled by spin or some other tool it would be awesome. Let me know your thoughts or if I should just make my own solution for this.

[vesper8]

I've also asked for this before. I think we're going to have to do this part ourselves. Managing env variables and secrets for multiple customers and swapping them in before using the deploy command.

[akulmehta]

I am OK with doing it myself if @jaydrogers is not planning this within Spin. I always prefer first party solutions as I trust the package maintainers are more experienced than myself.

[jaydrogers]

You're the only two people to request something like this, but if it got more traction where people wanted something like this I could build it out.

I think at this time it might be best if you built your own tooling. There are a lot of "it depends" scenarios that could be very complicated to develop an "all-in-one" solution.

[akulmehta]

Thanks @jaydrogers - I think that is fair. If you ever plan to incorporate this into Spin send a message here and we can probably share our solutions.