Build Cloud Run domain mapping configurations with automatic SSL certificates and custom domain routing.
Build Cloud Run domain mapping configurations with automatic SSL certificates, DNS records, and custom domain routing.
Required Fields
metadata.namemetadata.namespacespec.routeNamespec.certificateModeOutput will appear here...The builder requires metadata.name, metadata.namespace, spec.routeName, and spec.certificateMode to resolve before treating the config as a valid DomainMapping manifest, matching the fields the Cloud Run Admin API needs to know which domain, which project namespace, which backing service, and whether to auto-provision TLS.
Build a Cloud Run DomainMapping resource that routes a custom domain to a service with an automatically-provisioned SSL certificate. Domain mappings only work in a subset of Cloud Run regions (the classic mapping API is region-scoped and Google has been steering traffic toward Cloud Load Balancing + Serverless NEGs for full regional coverage), and the DNS records differ by whether you're mapping an apex domain (A/AAAA records to Google's anycast IPs, since apex domains can't use CNAME per DNS spec) or a subdomain (a single CNAME to ghs.googlehosted.com). Certificate provisioning after DNS propagates can take anywhere from minutes to about 24 hours.
A team migrating checkout.example.com from a legacy load balancer to Cloud Run sets up the domain mapping with certificateMode AUTOMATIC and waits, but 30 hours later the mapping is still stuck pending, and a dig against Google's public DNS shows an orphaned CAA record from the old host that only authorizes a different CA to issue certificates for the zone. They use the builder to double-check the DNS records they need to publish, add a CAA record explicitly authorizing pki.goog alongside the existing entries, and the certificate provisions within about twenty minutes of the CAA change propagating.
forceOverride: false will refuse to attach the mapping if the domain is already mapped elsewhere in your project, which is usually what you want, it stops an accidental double-mapping between two services from someone's earlier console click.
A CAA record limiting certificate issuers to something other than Google/Let's Encrypt on the zone silently blocks AUTOMATIC certificate issuance, with no error visible until you go looking at the mapping status directly.
The domain must be verified in Search Console under the same account before Cloud Run will accept the mapping at all, this is a separate step from DNS and trips up teams migrating domains between Google Cloud organizations.
This almost always means DNS hasn't actually propagated to what Cloud Run expects, or there's a conflicting record (an old A record at the apex, or a CAA record that doesn't authorize Google to issue certs for the domain). Verify with dig against a few different public resolvers, and check for a CAA record that needs 0 issue "pki.goog" added.
No. Domain mappings are only supported in a specific set of regions; if your service runs in an unsupported region, either redeploy to a supported one or front it with a global external Application Load Balancer using a Serverless NEG, which supports Cloud Run in any region and gives you more routing flexibility besides.
DNS doesn't allow a CNAME record at a zone apex (the bare example.com) because the apex must also hold NS and SOA records, which can't coexist with a CNAME. So apex mappings get four A records and matching AAAA records pointing at Google's anycast frontend instead, while any subdomain (www, api, etc.) can use the simpler single CNAME to ghs.googlehosted.com.
Was this tool helpful?
Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.