Multiple domains single app engine Application

[KWagdy]

Hello,

We are looking into enabling white labeling of our GAE Standard application to 100+ clients. We have already read through a few articles to see how we can implement this on GAE.

What we want to accomplish is that for every client to have their own domain, yet the back-end is the same, our GAE application.

1. www.client001.com 
2. www.client002.com 
3. www.client003.com
4. ...

We noticed several limitations might hinder us from doing so, for example:

1. The max number of custom domains (is there a limit?) due to the max number of SSL certificate support
2. We then thought of using several services and using dispatch.yaml to route each client's domain to a service, however, it seems that dispatch.yaml has "20" as a limit of the number of entries
3. We also thought of having multiple GAE applications, one for each client, but that is not quite an option since we will have to deploy any updates to each of separate GAE app. Which would be a nightmare. Not to mention, managing different Datastores, monitoring, logs, ...etc.
4. Reverse proxy was also suggested in one of the posts, but this introduces new & more costs, beside the fact that we lose having GAE with all its power as the landing point for our users, and rather having a single reverse proxy that will need to be somehow managed and scaled depending on the traffic.

Having subdomains client001.our-app-enginge.app.com (point 2) is also not favorable to our clients, as each client would like to have their own full domain.

We were hoping this has already been somehow solved from GAE side, since most of the above articles were posted more than a year ago. If anyone has any experience of implementing multiple domains or white labeling their GAE application it would be much appreciated to learn from their experience.

Thank you

[christianpaula]

Hi @KWagdy,

Welcome to Google Cloud Community!

You can use Google's App Engine service to host a single application that serves multiple domains. This is known as "multi-tenancy," where a single instance of the application serves multiple client domains.

Here are some options to consider:

1. Use a wildcard SSL certificate to support multiple custom domains: With a wildcard SSL certificate, you can secure all subdomains of a domain with a single certificate. For example, if you have a wildcard certificate for `*.example.com`, you can use it to secure `client001.example.com`, `client002.example.com`, and so on. You can purchase a wildcard SSL certificate from a certificate authority (CA), such as DigiCert or Let's Encrypt.
   
   
2. Use Google's Load Balancer to distribute traffic to multiple App Engine services: You can use Google's Load Balancer to distribute traffic to multiple App Engine services, each of which can serve a separate set of custom domains. This way, you can use the `dispatch.yaml` file to route traffic to the appropriate service based on the domain. This approach may be more expensive than using a single App Engine service, but it allows you to scale each service independently.
   
   
3. Use a reverse proxy server: You can use a reverse proxy server, such as NGINX or Apache, to proxy traffic from multiple domains to your App Engine application. This allows you to serve multiple domains with a single App Engine instance and gives you more control over the routing of traffic. However, this approach requires additional infrastructure and maintenance.
   
   
4. Use subdomains: If you don't need to support separate top-level domains for each client, you can use subdomains of your own domain to serve different clients. For example, you could use `client001.example.com`, `client002.example.com`, and so on. This approach is simpler to set up and maintain than using multiple top-level domains.

Thank you

[KWagdy]

Hello @christianpaula ,

Thank you for your answer. We read through multiple articles and forums before posting here. We have seen some of your suggestions on multiple forums and articles. Unfortunately, as mentioned in our post, these options seem to either have a limitation (like using dispatch.yaml which has a limit of 20 entries) or introduces new costs and single point of failure, which we want to avoid.