Vistelio | Standing Up Looker (Google Cloud core): Console to First Model

Updated August 2026. The 2023 version of this article described signing up for Looker on looker.com and receiving a yourcompany.looker.com instance. That flow no longer exists; Looker is provisioned through Google Cloud.

This guide takes you from nothing to a working Looker instance with a database connection and a first LookML project. It is written for Looker (Google Cloud core), the edition Google provisions from the Cloud console and where new capability lands first. If you are on Looker (original), the older Looker-hosted edition that still uses yourcompany.looker.com hostnames, the connection and project steps are the same; only provisioning differs, and Google is steering those instances toward core (see our migration page).

1. Provision a Looker (Google Cloud core) instance

You need a Google Cloud project with billing enabled and the Looker Admin role (or Owner) on it.

In the Google Cloud console, open Looker (search for it in the products list) and enable the Looker API if prompted.
Click Create instance. You will choose:
- an instance name and region;
- an edition (Standard, Enterprise or Embed; Enterprise adds features such as private networking and higher API limits, Embed is for customer-facing analytics);
- networking: public IP, private IP via a VPC, or Private Service Connect. Start with public IP for a first instance; you can lock it down later;
- maintenance window and deletion protection.
Looker core authenticates users with Google sign-in, so the instance needs an OAuth client. In APIs & Services > Credentials, create an OAuth 2.0 client ID of type Web application. The authorized redirect URI is https://<your-instance-url>/oauth2callback, which you can fill in after the instance URL is issued. Paste the client ID and secret into the Looker instance settings.
Provisioning takes a while (plan for up to an hour). When it is done, the console shows the instance URL; open it and sign in with the Google account that created the instance. That account is the first admin.

There is no separate purchase step on a website: Looker core is billed to the Google Cloud project, with pricing depending on edition and user type (viewer, standard, developer). Trials are arranged through Google Cloud sales or the console rather than a self-serve form.

Access for colleagues. Because sign-in is Google-based, users need a Google identity (Workspace or Cloud Identity) and the IAM role Looker Instance User on the project. Inside Looker, roles and groups then control what they can do.

2. Connect a database

From the instance, go to Admin > Database > Connections > Add Connection. Which fields you see depends on the dialect; the essentials are:

Name: the identifier your LookML model will reference in connection:.
Dialect: BigQuery, Snowflake, PostgreSQL, Redshift, Databricks and many more.
Credentials: for BigQuery, upload a service account JSON key (or use the instance's service account where your organization allows it) and set the billing project and default dataset. For Snowflake, Postgres and similar, provide host, port, database and a dedicated looker user.
Persistent Derived Tables: enable PDTs and give Looker a scratch dataset or schema it owns. PDTs will not build without it.
Timezone: set the database timezone and the query timezone so dimension groups convert correctly.

Click Test and then Connect. The test checks network reachability, credentials and PDT permissions separately, so read each line if it fails.

Example for a BigQuery connection:

Name:                  ecommerce_bq
Dialect:               Google BigQuery Standard SQL
Project name:          my-analytics-project
Dataset:               ecommerce
Authentication:        Service Account (JSON key)
PDT dataset:           looker_scratch
Database time zone:    UTC
Query time zone:       America/Chicago

For a private-IP instance, the database must be reachable from the instance's VPC (peering, Private Service Connect, or a bastion); for public IP, allow-list the instance's egress IPs shown in the console.

3. Create a LookML project and connect it to Git

Turn on Development Mode (the toggle in the left navigation), then go to Develop > Projects > New LookML Project:

Project name: lowercase, underscores; this becomes the Git repository name by convention.
Starting point: Generate Model from Database Schema writes a view file per table and a starter model, which is the fastest way to see data; Blank Project is better once you know what you are doing.
Connection and schema: the connection from step 2.

Looker creates the project with a model file and view files. Before anyone else can work on it, connect it to Git: in the IDE, Configure Git, paste the SSH remote of an empty repository in GitHub, GitLab or Cloud Source Repositories, and add the deploy key Looker generates to the repository with write access. Commit, then Deploy to Production. From now on every developer works on their own branch in Development Mode and the production model is whatever is on the deployed branch.

A minimal model and view to confirm everything works:

# ecommerce.model.lkml
connection: "ecommerce_bq"
include: "/views/*.view.lkml"

datagroup: ecommerce_default {
  max_cache_age: "1 hour"
}
persist_with: ecommerce_default

explore: orders {
  label: "Orders"
}

# views/orders.view.lkml
view: orders {
  sql_table_name: `my-analytics-project.ecommerce.orders` ;;

  dimension: order_id {
    type: number
    primary_key: yes
    sql: ${TABLE}.order_id ;;
  }

  dimension_group: created {
    type: time
    timeframes: [raw, date, week, month, year]
    sql: ${TABLE}.created_at ;;
  }

  measure: count {
    type: count
  }

  measure: total_revenue {
    type: sum
    sql: ${TABLE}.amount ;;
    value_format_name: usd_0
  }
}

Open Explore > Orders, pick Created Month and Total Revenue, and run. If you get rows, the stack works end to end.

4. Before you invite the business

A few settings that are much easier to get right on day one:

Roles: create a Developer role with a model set limited to your project, and a Viewer role with access_data and see_looks only. Resist giving everyone Admin.
Groups: map Google groups to Looker groups so onboarding is an IAM change, not a Looker change.
API keys: create a dedicated service user for integrations rather than using a human admin's key. See Working with the Looker API 4.0.
Datagroups: define one per source-refresh cadence now; bolting caching on later is painful.
Content folders: a Shared folder structure by team, with edit rights granted to groups, keeps the instance navigable at a thousand dashboards.

Summary

Provisioning Looker in 2026 means creating a Looker (Google Cloud core) instance from the Cloud console, wiring up Google OAuth, connecting a warehouse with a service account and a PDT schema, and putting the first LookML project in Git on day one. The subsequent tutorials in this series go deeper on models, explores and access control.

Want an instance set up properly by people who have done it many times? Our Looker consultants can stand it up with you; contact us.