Admins can customize the name of the domain or hostname in the URL for a Looker instance.
Looker-hosted instance URLs take these forms:
https://<hostname>.<subdomain>.<domain>.com
or
http://<hostname>.<subdomain>.<domain>.com
Admins of Looker-hosted instances can modify each component of the instance URL (except for the subdomain, if present, which may be determined by the region where the instance is hosted), but some changes or additions may incur additional costs or require embedded analytics. Contact a Google Cloud sales specialist to discuss the options available for your Looker deployment.
In addition to these elective changes, the instance URL may also be affected if your deployment:
- Migrates from legacy hosting on Amazon EC2 to next-generation hosting on Google Cloud or Amazon Elastic Kubernetes Service (EKS)
- Migrates from customer-hosted to Looker-hosted
- Migrates from Looker (original) to Looker (Google Cloud core)
- Changes its AWS EC2 hosted region (which may change the subdomain, if present)
What should I be aware of before initiating a URL change?
In most cases, if the instance URL is changing, a Looker admin must update the Host URL field on the Settings page in the Admin panel with the new URL. If an instance URL is changing because of a migration from Looker (original) to Looker (Google Cloud core), the Host URL option is not available in Looker (Google Cloud core), and that step isn't necessary.
If your instance uses an authentication method like SAML or LDAP, you must point the identity provider configuration to the new URL, or your users may get locked out.
There could be a momentary service interruption associated with making a change to the instance URL. Depending on your deployment, updating the host URL may result in the following breaking changes.
Instance change | Example | Type of change | Breaking change |
---|---|---|---|
Migrating from legacy hosting on Amazon EC2 to next-generation hosting on Google Cloud or Amazon EKS |
company.looker.com to company.cloud.looker.com
|
Changes subdomain |
Users and embed users must update their bookmarks within seven days, or their bookmarks will break. Both URLs will work for seven days after the change. If using the Slack integration for data deliveries, any deliveries sent by users who are not already logged into Slack will not be delivered. Existing schedules and ad hoc deliveries sent by users who are already authenticated into the Slack workspace will not be affected. |
Migrating from customer-hosted to Looker-hosted |
company.instance.com to company.cloud.looker.com
|
Changes domain |
Users and embed users must update their bookmarks, or their bookmarks will break. How long the customer-hosted instance URL operates is up to the discretion of the company. If using the Slack integration for data deliveries, any deliveries sent by users who are not already logged into Slack will not be delivered. Existing schedules and ad hoc deliveries sent by users who are already authenticated into the Slack workspace will not be affected. |
Migrating from Looker (original) to Looker (Google Cloud core) |
company.looker.com to hostname.looker.app
|
Changes domain |
Bookmarks to Looker (original) instances that use the
If moving from a custom URL for Looker (original) (that doesn't use the There is a small set of feature differences between Looker (original) and Looker (Google Cloud core). Review these differences to ensure that the features in Looker (Google Cloud core) meet your ongoing needs. See the migration documentation for more information about migrating from Looker (original) to Looker (Google Cloud core). |
Changing AWS EC2 hosted regions |
company.au.looker to company.jp.looker.com
|
Changes subdomain |
Users and embed users must update their bookmarks within seven days, or their bookmarks will break. Both URLs will work for seven days after the change. If using the Slack integration for data deliveries, any deliveries sent by users who are not already logged into Slack will not be delivered. Existing schedules and ad hoc deliveries sent by users who are already authenticated into the Slack workspace will not be affected. |
Switching the order of the domain |
example.looker.com to looker.example.com
|
Changes domain |
Both instance URLs will work indefinitely. If using the Slack integration for data deliveries, any deliveries sent by users who are not already logged into Slack will not be delivered. Existing schedules and ad hoc deliveries sent by users who are already authenticated into the Slack workspace will not be affected. |
Switching to a custom domain |
example.looker.com to example.custom.com
|
Changes domain |
Both instance URLs will work indefinitely. If using the Slack integration for data deliveries, any deliveries sent by users who are not already logged into Slack will not be delivered. Existing schedules and ad hoc deliveries sent by users who are already authenticated into the Slack workspace will not be affected. |
Changing from one Looker host to another |
company1.cloud.looker.com to company2.cloud.looker.com
|
Changes domain |
Users and embed users must update their bookmarks within seven days, or their bookmarks will break. Both URLs will work for seven days after the change. If using the Slack integration for data deliveries, any deliveries sent by users who are not already logged into Slack will not be delivered. Existing schedules and ad hoc deliveries sent by users who are already authenticated into the Slack workspace will not be affected. Hostnames for Looker instances may contain only alphanumeric characters and must be 6 characters or longer. This means that they can't have dashes, such as: customer-dev.looker.com. |