Setting up a Staging Server for a Multi-tenant Laravel App on Google App Engine

Alex Yap
Alex Yap
Sep 10 · 3 min read

This post assumes that you already have a Laravel project running on Google App Engine.

Like many others, I have found the GCP docs to be of barely any help and decided to just figure it out through countless trials and errors. Below is a quick guide I decided to write to help out anyone who has been in the same situation as I have.

To my knowledge, there is no mention on the GCP docs anywhere on how to set up a staging server for a multi-tenant web app. Although, the docs do have mention of overriding routing rules through the use of a dispatch.yaml file which we will take advantage of later. Read more about it here.

But enough talk. The way I figured I would do this is to create an app.staging.yaml file that contains mostly the same configurations as the original app.yaml file that is used to deploy code to the default service.

To check what services you have currently running on your GAE instance head to this link: https://console.cloud.google.com/appengine/services?project=project-name

Make sure you change project-name to your Google Cloud Platform project name.

If you haven’t deployed any other services yet, then most likely all you will see in there is the default service which you can access through https://project-name.appspot.com which is often used as the production server.

Now, cd into the root directory of your project and create an app.staging.yaml file which should contain following configurations:

Take note of the service configuration option. This is vital as this determines which service Google App Engine should create (if it isn’t created already) or update. Now, go ahead and run the following command:

gcloud app deploy app.staging.yaml --version v1

In the case above, the staging service should now be created and by accessing https://staging-dot-project-name.appspot.com, Google App Engine would now serve the staging service instead of the default service.

If you have your domain name already configured by this time, then https://staging.yourdomain.com should also work. Basically, accessing your app by using an active service’s name as a subdomain will tell Google App Engine to serve that service otherwise if the subdomain does not match any service then GAE, by default, will serve the default service instead.

Any configuration you set on the app.staging.yaml file will only reflect on the staging service and will not affect any configuration set on the default service and vice versa.

But this isn’t always the case for multi-tenant web apps running on GAE. For instance, what if you needed to create a tenant on https://staging.yourdomain.com? Then that would translate into https://some-client.staging.yourdomain.com and would only confuse GAE into serving the default service since the second level subdomain name does not match any running service.

Here is where the dispatch.yaml file comes in handy. Cd back into your project’s root directory and create a dispatch.yaml file. The file should contain the following:

The dispatch.yaml basically overrides how GAE’s routing mechanism works and in the case above https://some-client.staging.yourdomain.com will now make use of the staging service even if the subdomain doesn’t match any running service. Finally, run the following command:

gcloud app deploy dispatch.yaml

And you’re done!

Lastly, you might want to configure the DB_SOCKET and cloud_sql_instances to point to another instance or the same instance but a different database in order not to pollute any data you might have on your production database. That’s it!

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade