How to deploy a multi-repo per customer?

Apologies if this has been addressed previously.

I’m developing a SaaS application that consists of three main components: 1) a Rails application, 2) a Python backend, and 3) a small Node.js service.

For each customer I’d want to do a deployment of these three services. Something like:

  1. A customer signs up for the service.
  2. In response, I trigger a single API endpoint which initiates the deployment of these three distinct services.
  3. If a customer decides to discontinue the service (churns), I can then call another API endpoint with a specific ID, which will then shut down all three services associated with that particular customer.

What would the best practices on how to do this?

Hi @mbarbudas ,

Just to confirm, it sounds like for each customer you’d like to spin up 3 services (consisting of a Rails, a Python and a Node service). Is that right?

Do you know for certain that you want each customer to have their own set of services? Could you tell us a little more about your project?

If you’re building a white-label product that customers can customize themselves, I think there might be a better way, but I’d love to learn more about you’re envisioning before prescribing any solutions.

Regards,
Annie

Hey Annie,

Just to confirm, it sounds like for each customer you’d like to spin up 3 services (consisting of a Rails, a Python and a Node service). Is that right?

Yes, that’s right.

Do you know for certain that you want each customer to have their own set of services? Could you tell us a little more about your project?

I keep on trying to wrap my head around if I could avoid this, and somehow use db multitenancy. But it’s the type of project where traditional customers are barely used to deploying to the cloud at all. Let’s assume worst case scenario, all three.

If you’re building a white-label product that customers can customize themselves, I think there might be a better way, but I’d love to learn more about you’re envisioning before prescribing any solutions.

It’s not white-label, it would more traditional SaaS but with fewer enterprise customers and larger contracts.

Thanks for the extra information. Happy to defer to your judgment about whether to use data stores for multitenancy or not, you know your project best! :slight_smile:

As to your initial question, Fly.io offers a REST API (known as the Machines API) which allows you to do spin up applications, manage VMs and more. Checkout documentation for this here: Working with the Machines API · Fly Docs

If you prefer, we also have a GraphQL API available: GraphQL Playground

One thing to note is that the standard REST API covers most tasks, you may need to rely on the GraphQL endpoint or the flyctl CLI for allocating IP addresses for these new services. See the section here Allocate an IP address for global request routing

Let us know if you have any other questions!

Regards,
Annie

Thanks Annie! And apologies for not responding sooner, was away for New Years.

My question is: What’s the easiest way to manage the complexity of my setup?

Meaning, let’s say I have 10 customers. That means I want to manage 3 (services) x 10 (customers).

Do I create a new app for each customer, and then destroy the app when someone churns?

Or do I create 3 machines and associate them with each customer and destroy the specific machines on churn?

How do I manage updates in both these cases? Trying to find the easiest path.

Hi @mbarbudas , I too was out for the holidays, thank you for your patience!

So without knowing exactly what you’re building, it’s hard to prescribe anything specific. The reality is depending on what you’re making, there are different ways you could architect things, but here are my thoughts:

From what you’ve described, you’ll almost certainly want 3 apps per customer, and not 3 machines, since machines should really be treated as ephemeral objects used for scaling. This gives you the flexibility to scale the number of machines per customer as you see fit.

It also sounds like you’re going to have a “parent” app that manages the creation and destruction of these customer apps, which will probably have it’s own database that keeps track of which apps belong to which customers.

Hope this helps!

Process groups could be what you are looking for.

You can create a single docker image with all 3 services, and define a process for each with the respective launch command, then the app will have 3 (or more, you can scale individually) machines, each with it’s own service.

Then you can communicate between the correct services with <process_group>.process.<appname>.internal (https://fly.io/docs/reference/private-networking/#fly-io-internal-addresses)

After that you can create an app for each client that will have the separate machines, the only challenge could be keeping all the configs synced between apps, but there is probably some smart way to do that.

Agreed with @Tc001 , process groups is another great option. This typically works when you only have one process group (service) that accepts Internet traffic, but there are ways around that too, I believe. Definitely worth checking out, then you would have fewer apps per customer to manage.

Thank you @Tc001 and @anniesexton! It seems process groups would be the easiest way of tackling this.

What do you mean by configs, if I can ask? Updating the services, right?

Oh snap, actually I would need two services to respond to outside traffic. Perhaps adding a router or something to route between the two processes?

If you know you’ll need a way of routing traffic based on which customer app is being hit, I would check out Fly replay: Dynamic Request Routing · Fly Docs – it basically lets you forward a request to a specific app, machine, or other criteria.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.