Host multiple Vue web apps using single Git repo

Hi all,

I’m brand new to Netlify and am currently using Vercel, but am looking to switch.

I own a Fintech business that has a product being used by 48 clients. It is effectively a Vue web app running from a single Git repository but each client has their own sub-domain and the app is completely customised for their business from branding, styling, fields, etc. All this configuration data is stored in a DB and in the middle of that sits our API, hosted on GCP.

I don’t believe this a monorepo as there are no sub-folders for separate projects.

I have the single repository connected in Vercel and when launching the web app for a new client, I simply create a new project, set the specific environment variables (there are shared environment variables too), set the sub-domain and deploy.

When pushing code changes, anything that is pushed to the main branch automatically deploys to every single project, albeit, this is not working very well now on Vercel.

My questions are:

  • Can Netlify do the same?
  • Does Netlify have a limit on the number of projects/sites that can be created using a single Git repo?

The problem I’m facing is that Vercel only supports 60 projects per single Git repository and we’re teetering quite close to that limit now.

Deployment has also become quite unstable where code changes are not being deployed to every site and there appears to be no clear reason as to why.

As the business grows, we may have 100’s of clients using our platform and we require a platform that is stable and meets our requirements.

1 Like

Hi all,

Would really appreciate a reply on this as Vercel have said they can’t increase the limit on the number of projects/sites that can be created using a single Git repo without upgraded to their Enterprise plan.

Just to add, I’ve signed up to to the Pro account. I’ve created 2 different sites using the same Git repository so it does work but there is not indication whether there is a limit to how many times a single Git repo can be used.

@Dally I didn’t respond originally because while I could have advised that Netlify does support multiple sites connected to the same repository, I’m not sure what kind of limits exist. I personally never connected more than 5 or so sites to the same repository.

A Netlify support staff member will respond here eventually, however if you have a paid account you can also reach out to their team here:

Hi @nathanmartin, thank you for your input.

I have contacted Netlify support now as I have a paid account and am hoping for a reply soon.

Strange that Netlify don’t list any limits regarding this but Vercel do.

Just an update:

Still no answers to my questions. Had a call booked in with a Netlify representative yesterday who stood me up without any communication. I’ve tried chasing but haven’t heard anything back.

Not a great start so far.

@Dally As I understand it there’s no guaranteed response times for non-enterprise customers.

I’m not sure what kind of time frame tickets are being responded to currently, in the past it was 2-4 days or so, and I’d often find I got a faster response on the forums.

@SamO or @hrishikesh can you answer (or source an answer for):

Hi @nathanmartin,

I understand the timeframe regarding tickets but I had an actual Zoom call booked in yesterday for 12pm where the Netlify representative was a no-show.

I waited 10mins before I left. Quite rude really.

@Dally Yeah, I understand and can’t really speak to that.

The one time that I had a booked in call with a Netlify rep, (head of ‘Partner Services’ I believe it was), they did show up. They were otherwise utterly useless, but they did show up.

I just wanted to make sure you were aware that support on self service plans. (all plans below Enterprise), can be a little slow, just in case you do require faster longer term.

1 Like

Thanks for the ping @nathanmartin!

To answer @Dally’s questions, theorotically there’s no limit to the number of projects you can build from a single repo. However, there would be practical limitations that would apply here. For each repo push, you’d basically be firing off 100s of builds. That’s still an okay number, but won’t scale well if you wish to do so with 1000s or even more. The builds will eventually finish, but this could potentially cause a delay for all the customers as the system will try to schedule everyone’s builds in the same limited resources. Not to mention, if this would trigger one of the monitors we have in place for system monitoring, you might receive an email (on the Pro and above tiers or an account suspension on the Starter tiers) asking about your use-case. If your builds are causing too much system load (like 1000s of builds taking 30 min or more), we might have to ask you to upgrade to Enterprise as well, because that would not sound like a use-case suitable or value-match for a Pro tier user.

For 48 clients and a Vue SPA (assuming it’s using Vite and builds within 5 mins), this is no problem. Even if this touches Vercel’s limit, that’s still fine. For a ballpark, I think 500 is also okay (but I’d recommend to limit the push to your repo, that is, don’t start a build for an update to your readme, make sure the build is actually needed).

With all this being said, there are also alternative ways to handle this;

  • Use the repo on a single site and use domain aliases: Sites with multiple domains | Netlify Docs. However, this is subject to a limit of 100 total domain for a site (Let’s Encrypt limit of not being able to add more than 100 domains on a single certificate + our limit of not being able to add more than 1 certificate on a single site). Worst case, you can setup 5 sites with 100 domains on each, so you can still serve 500 customers, but just have 5 sites to build.
  • Use wildcard domain. This would allow you to get * all on the same site. Just 1 site would serve all that traffic. If this is how you’re setting up your sites and customers, I’d highly recommend going down this path. The only limitation here would be to either use Netlify DNS (so we can provision a wildcard certificate for you) or get a custom wildcard certificate.

Hi @hrishikesh, thank you very much for that detailed explanation.

They key bit for us was to know whether there is a limit to the number of projects that can be built from a single repo. Hearing that there is theoretically no limit is great news. I think once we reach circa 250 projects, it makes sense moving over to the Netlify Enterprise plan.

It’s not imperative that all deployments are done at the same time. We’re happy to do do 5-10 deployments every 5 to 10mins for example. I suppose we could build a CI/CD piple for this or just use deployment hooks and stagger deployments.

We’re currently using subdomains for all of our projects. The main domain is on Cloudflare. I’ve looked into the alternative ways you’ve mentioned to handle this but I’m unsure whether they’re suitable for our product.

Here are two examples that I’m currently hosting on Netlify…

The basic structure of each web app is the same but each project has its own configuration that controls certain features, branding, styling, etc. Each project has a UUID that is encrypted to retrieve this config data (this data is non-sensitive).

There’s also a backend portal to these web apps that uses Auth0 for authentication and authorisation.

If you’re going to do that, I see no issues with your setup. There’s a soft-limit of 500 sites per account though and you can contact us to get that removed once you hit it or get close to it.

If all of your domains are going to be in the same format, I do believe wildcard domains would work. You can combine that with Edge Functions to dynamically add some metadata to your HTML/CSS/JS and use that in the client-side for the dynamic bits. Maybe you can just embed the UUID or fetch the data from your backend from within the Edge Function and modify the HTML that’s being served. In other words, there are ways to get creative. But if this and the Auth0 part is too much work to setup, you can go ahead with a the staggered approach.

Thank you very much @hrishikesh for your thoughts. For the time being and for ease, I think I’m going to stick to the current approach but I will definitely be looking into the recommendations you’ve suggested :+1: