A wildcard for your Cloud Run services

Cloud Run is the latest in a series of serverless products available on Google Cloud.

When you create a new service on Cloud Run, you get assigned a random URL under run.app. For example, I've set one up earlier called qr which by default is available at https://qr-bvlhj4hsjq-uc.a.run.app.

That URL is a little bit janky, but don't worry, we can fix it! Instead of using the default URL, you can map a custom domain to your service.

However, this can get tedious if you have a lot of different services in the same project that will live on subdomains of a shared domain name. But did you know that you don't have to configure your DNS each time, if you use a wildcard CNAME? And that you can set that up on a subdomain? It's true!

The master of your Domain

In order to start off, you need to configure the use of a domain name. This is cross-project, one-time process, so while it may be a bit long, you only need to do it once.

First, you need a domain name.

The domain you choose, and who you register with (the domain registrar) is up to you, but a few notes:

• Google does have its own domain registrar, domains.google. If you use Google, your domain is automatically verified.
• there are some domains, like .app, which will only allow HTTPS content. This is fine, as Cloud Run will handle creation and configuration of the certificates for you!

Once you have your domain, you need to verify it within Google Cloud.

To initiate this process, in your Google Cloud Platform console, navigate to Cloud Run, then click "Manage Custom Domains".

From here, we're going to "➕ Add mapping" for our qr service.

If you chose to register through Google Domains, your domain will appear already in the dropdown; otherwise, you'll need to follow the Verification steps for your chosen registrar. These are documented on a per-registrar basis, and often include screenshots of the steps.

The regular process

Without wildcards, any time we want to map a service to a custom domain, we'd have to create a new CNAME record each time.

For example, for this qr service, I'd have to add:

qr.gl CNAME 1800 ghs.googlehosted.com.

I'd have to do this every time, and wait for DNS propagation to occur, before I can even start using my site.

A wildcard domain appears!

Instead, after verifying the domain we're going to add a single DNS record to handle all our services, even ones that don't exist yet.

In my case, I registered asnt.app, and I want to host all my Cloud Run services under gl.asnt.app (Yes, I am terrible.)

So to do this, I'll need to create the following DNS record:

*.gl CNAME 1800 ghs.googlehosted.com.

This is what it looks like in the Google Domains DNS page:

This will take up to an hour to propagate.

But, we're done all the DNS configurations, and we should never have to touch it again!

One command to map them all

From here, it's just one one-time command to map your service to your custom domain.

$ gcloud beta run domain-mappings create --service $SERVICE --domain $SERVICE.gl.asnt.app

Wait 15~20 minutes for your SSL certificate to be automatically created for you, and tada 🎉 https://qr.gl.asnt.app is now live!

Each time you want to deploy a new service, just add a gcloud beta run domain-mappings create command after your gcloud builds submit and gcloud beta run deploy calls.

A small, but useful, efficiency boost.

Using CNAME wildcards reduces the complexity of setting up new services, while still ensuring security by having unique SSL certificates setup each time.

If 15 minutes is still too long, you could consider if using Firebase Hosting, another Google Cloud product, is right for you.

But wait, aren't wildcards bad?

Not necessarily.

Since we're taking the time to provision a certificate for the specific subdomain, we're securing content on that specific subdomain. All we're doing with the wildcard CNAME is reducing the amount of DNS configurations we need to do each time we deploy a new service. The time taken to provision unique certificates on each subdomain mitigates risk compared to the alternative - a wildcard SSL certificate.

And because we had to verify our domain before we could map it to our service, no other Cloud customer can map their service to our subdomain.

There could be interesting consequences depending if you have different services interacting and hitting CORS issues, especially if you are hosting a service from the root domain and subdomains; in that case, the aforementioned Firebase Hosting could be a better solution.