I’d like to setup a SaaS where I need to spin up an api server and associated Postgres DB for each client who signs up, triggered from our website backend.
I’m evaluating several options to do that on Fly. Is it better(and possible) to use flyctl to generate the images from templates, and then return the image details in the response? Or to use the GraphQL API and write my own queries to generate the data?
And then I have to handle updating the images from the web somehow.
I never thought that image deployment/management would be one of the most challenging parts of this effort. Maybe there’s a better way?
Are you intending to run the same Docker image for every customer, in addition to Postgres?
In theory, the “simplest” thing to do is create actual software releases with fixed image tags, then deploy those when you need to make updates. The API will return the exact image URL that’s running, so you could query apps to see what tags exist and then use that to manage updates.
I think I see where you’re going with this. The api server would be identical, except for potential configuration options. I can probably set those with env. I usually have it pull a specific github release, so I think that’ll be visible. And I could create a Postgres DB and link it to the image.
I think you’re suggesting I write a small server that can create, get, update, and destroy fly io instances via the API, and store data about them in a DB.
The reason I asked this centered around whether there was something prebuilt that does this or if I was missing some obvious software. It appears people do this with Ansible, Terraform, k8s, and maybe others outside of fly.
To be honest, I’m not sure if I should write my own solution or try to use one of the tools as a noob to this kind of multi container deployment. Simple web services are so much easier…
I think you do need your own app/server to manage whatever backend you hook it up to. This is true for k8s and most anything you’d use for terraform.
As much as I like the single-app-and-database-cluster per customer thing, it may be more work than makes sense. Do you expect to have customers that would be especially demanding of that?
If it were me, I’d probably start with a multitenant app + database to keep management easy and then work on letting people run isolated installs later. Everything is easier if you only have to run one version of your app code and database schema.
I definitely thought about that. It’d be really easy to setup one DB and one API server, but it doesn’t seem right. Each client has their own set of user hashes and usernames(amongst other things), potentially thousands, and it didn’t seem right to store passwords for each client in the same DB.
I wouldn’t want a single point of failure leaking everybody’s info. I couldn’t find a ton of info or examples of people doing that, but maybe I didn’t look hard enough.
EDIT: It appears Auth0 is multi tenant, so perhaps it’s not as bad as I think
