DEV Community

Katie McLaughlin for Google Cloud

Posted on • Updated on

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 For example, I've set one up earlier called qr which by default is available at

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, 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: CNAME 1800
Enter fullscreen mode Exit fullscreen mode

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, and I want to host all my Cloud Run services under (Yes, I am terrible.)

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

*.gl CNAME 1800
Enter fullscreen mode Exit fullscreen mode

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

Google Domains DNS screenshot

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 $
Enter fullscreen mode Exit fullscreen mode

Wait 15~20 minutes for your SSL certificate to be automatically created for you, and tada 🎉 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.

Top comments (5)

venu05868060 profile image
Venu • Edited

HI Katie @glasnt , Thank you for the article. we are trying to dynamically provision subdomains for users who signup with us, currently we are manually adding the custom domain to the app engine. As you may know, this is causing us additional work and is slow, is there a way we can dynamically provision custom domains on app engine ? will adding a wild card custom domain to app engine with a wild card ssl certificate help? we are stuck on this for quite some time and would appreciate your help. Thanks.

glasnt profile image
Katie McLaughlin

Cloud Run and App Engine are completely different in this regard. You're better off asking reaching out to the App Engine community directly:

naraphox profile image
Ryan Farnham

This sadly doesn't work now, it just drops the connection, so now you must setup Firebase hosting and redirect to the container that way as show here >

ayyappa99 profile image

Great post but unfortunately, misleading title :|

dbeniciorj profile image
dbeniciorj • Edited

Thanks for the article, those gcloud commands helped me a lot.
And the titles were really funny... map them all, wildcard domain appears! I've got those references! ^^