After you create a service or function, Cloud Run provides you with an HTTPS endpoint for the service. You can enable the service to run in response to HTTPS requests.
All Cloud Run services have a stable HTTPS URL, which represents the default HTTPS endpoint for the service, though you can configure custom domains as well.
Some of the use cases include the following:
- Custom RESTful web API
- Private microservice
- HTTP middleware or reverse proxy for your web applications
- Pre-packaged web application
Create public services
Creating a public service on Cloud Run requires the following:
- Access to the service from the public internet
- A URL intended for public use
To make a service public, set your service to allow unauthenticated (public) access when you deploy, or at any time after you deploy.
Service URL
Cloud Run assigns a hash-based non-deterministic URL to all services. If the service name length allows it, Cloud Run also assigns a deterministic URL to the service.
You can disable these default run.app URLs.
You can retrieve your service's URL by clicking the service name in the Google Cloud console or by running the following command in the gcloud CLI:
gcloud run services describe SERVICE --format 'value(status.url)'
The deterministic URL is given priority when displayed.
Deterministic URL
The deterministic URL lets you predict the service URL before the service is created, which can be useful for service-to-service communication.
The deterministic URL is only available for DNS segments of 63 or less. The DNS segment contains the service name, the project number, and any traffic tag or tags.
The deterministic URL for a Cloud Run service has the following format:
https://[TAG---]SERVICE_NAME-PROJECT_NUMBER.REGION.run.app
where:
- TAG is the optional traffic tag for the revision that you are requesting.
- PROJECT_NUMBER is the Google Cloud project number.
- SERVICE_NAME is the name of the Cloud Run service.
- REGION is the name of the region, such as
us-central1.
Non-deterministic URL
Non-deterministic URLs do not have a deterministic format, meaning that because the URL's second field is a random hash, you cannot predict what the full URL will be before you deploy the services. After you deploy the service, however, the URL remains stable.
The non-deterministic URL for a Cloud Run service has the format
https://[TAG---]SERVICE_IDENTIFIER.run.app,
where TAG refers to the optional traffic tag for the revision that you
are requesting, and SERVICE_IDENTIFIER is a stable and unique
identifier for a Cloud Run service. Don't parse the
SERVICE_IDENTIFIER as it does not have a fixed format, and the
logic for SERVICE_IDENTIFIER generation is subject to change.
HTTP to HTTPS redirect
Cloud Run redirects all HTTP requests to HTTPS but terminates
TLS before they reach your web service. If your service generates a web resources
that refers to other web resources with unsecured URLs (http://), your page
might be subject to mixed content warnings or errors.
Use the https protocol for all reference web URIs or account
for proxy directives in the HTTP Request such as the X-Forwarded-Proto HTTP
header.
HTTP and HTTP/2
By default, Cloud Run downgrades HTTP/2 requests to HTTP/1 when those requests are sent to the container. If you want to explicitly set your service to use HTTP/2 end-to-end, refer to Using HTTP/2.
Create private services
Creating a private service on Cloud Run requires you to limit access to the service by leveraging the IAM invoker permission.
You can also limit access to a service using application-level authorization and authentication mechanism, for example, using Identity Platform.
Test private services
The easiest way for you to test private services is to use the
Cloud Run proxy in Google Cloud CLI.
This proxies the private service to http://localhost:8080
(or to the port specified with --port),
providing the token of the active account or another token you specify.
This lets you use a web browser or a tool like curl.
This is the recommended way to test privately a website or API in your browser.
You can proxy a service locally using the following command line in a Linux, macOS, WSL (preferred), or cygwin environment:
gcloud run services proxy SERVICE --project PROJECT-ID
You can also test private services without the proxy by using a tool
like curl, passing an auth token in the Authorization header:
curl -H "Authorization: Bearer $(gcloud auth print-identity-token)" SERVICE_URL
Private service to service
A Cloud Run service can call another Cloud Run service with service-to-service authentication.
Sample code that invokes a private service
For code samples that shows how to obtain an ID token and make an HTTP request to a private service, refer to the topic Authenticating service-to-service.
Using a middleware to enhance your service
HTTPS proxies can offload common functionality from an HTTP service, such as caching, request validation, or authorization. For microservices, many HTTP proxies are part of an API Gateway solution or a service mesh such as Istio.
Google Cloud products that you can use to enhance your Cloud Run service include:
API Gateway, which you can use to create, secure, and monitor APIs to use as proxies to other Cloud Run services.
Firebase Hosting, which you can use to build a web application frontend to use with Cloud Run as a dynamic backend.
Invoke a function with an HTTPS request
By default, all functions created in Cloud Run have a run.app
HTTPS URL, which can be used to trigger a function. Functions created with an
Eventarc trigger will also have an HTTPS URL unless you opt out by
using the disable run.app URL feature.