Using Multiple GCP Accounts on One Computer

Managing more than one Google Cloud Platform account from one computer is a common situation — a personal account for experiments, a work account for production, a client account for certain environments. Without proper understanding, the risk is real: accidentally running commands against the wrong project, using the wrong account when deploying, or even not realizing you’re using a production account when you intended to work on your personal account. The Google Cloud SDK (gcloud) provides an official mechanism for handling many accounts on one machine, but just knowing how to log in and switch isn’t enough — the part often missed is understanding that the active account and the active project are two completely separate things, and how to verify the context before risky commands run.

Prerequisites

Make sure the Google Cloud SDK is installed on your computer. Check with:

gcloud version

If not installed, follow Google Cloud’s official installation documentation for your operating system. Once installed, gcloud is ready to manage authentication and project configuration.

How gcloud Stores Credentials

Before getting into practical commands, it’s important to understand the mental model behind gcloud — because this differs from the explicit file-based profile mechanism used by AWS CLI. gcloud doesn’t require you to write config files manually; instead, every time you run gcloud auth login, the resulting authentication credentials are stored automatically in the local config directory (~/.config/gcloud/ on Linux/macOS).

flowchart TD
    A[gcloud auth login] --> B[Browser opens for OAuth]
    B --> C[Choose a Google account]
    C --> D[Token stored in ~/.config/gcloud/]
    D --> E[Account available to select anytime]

What differs from AWS profiles: you don’t need to name accounts manually like [staging] or [production]. Each account’s identity is automatically the Google email address used at login — [email protected], [email protected], and so on. This has an important consequence: account names are always explicit and unambiguous (the email is directly visible), but it also means you can’t give arbitrary short names the way you can with AWS profiles.

Logging In to the First Account and Adding Others

The first step is logging in to the GCP account to be used:

gcloud auth login

This command opens a browser and asks you to log in with a Google account, for example [email protected]. After success, the account credentials are stored locally and ready to use.

To add a second or third account, simply run the same command again, then log in with a different Google account — for example [email protected]:

gcloud auth login

gcloud doesn’t remove previously logged-in accounts. All accounts you’ve ever used to log in are stored together, ready to select anytime without needing to log in again from scratch.

Because gcloud auth login always opens a browser for interactive OAuth authentication, make sure you log in with the browser tab/profile matching the intended Google account — especially if you’re also logged into several different Google Workspace accounts in the same browser.

Viewing and Switching Between Accounts

To see all accounts stored on the computer:

gcloud auth list

Credentialed Accounts
ACTIVE  ACCOUNT
        [email protected]
*       [email protected]

The * mark shows the currently active account. To switch to another account:

gcloud config set account ACCOUNT_EMAIL

gcloud config set account [email protected]

After this command, all subsequent gcloud commands use the account just set — until you explicitly change it again. Unlike AWS which has a per-terminal-session env var option (AWS_PROFILE), gcloud config set account changes the global configuration that applies across terminal sessions until changed again.

Because gcloud config set account is global (not per terminal session), the active account you set in one terminal window will also appear active in other terminal windows you open afterward. This differs from the export AWS_PROFILE habit, which is local to one shell session.

Active Account vs Active Project — Two Separate Things

This is the most common source of confusion for those new to working with gcloud: assuming that switching accounts automatically switches projects too. In reality, accounts and projects are two completely independent configuration axes.

flowchart LR
    subgraph Accounts["Axis: Accounts (Identity)"]
        A1[[email protected]]
        A2[[email protected]]
    end
    subgraph Projects["Axis: Projects (Resources)"]
        P1[myapp-dev-123]
        P2[myapp-prod-456]
        P3[client-x-789]
    end
    A1 -.can access.-> P1
    A1 -.can access.-> P3
    A2 -.can access.-> P2
    A2 -.can access.-> P1

One account can have access to many projects at once — conversely, one project can be accessed by more than one account (for example you and a teammate both have access to myapp-prod-456). Therefore, switching accounts doesn’t automatically switch the active project; both must be set separately.

# Check the currently active account
gcloud config get-value account

# Check the currently active project
gcloud config get-value project

To set the project explicitly:

gcloud config set project PROJECT_ID

gcloud config set project myapp-prod-456

The most dangerous scenario: you’ve already switched to the correct account ([email protected]), but the active project is still left over from a previous session — for example still myapp-dev-123. The command you meant for production actually executes in the development project, or worse, the reverse. Always set both explicitly, don’t assume the project follows when the account changes.

To see the list of projects accessible by the currently active account:

gcloud projects list

Verifying Before Executing Risky Commands

Just like with AWS profiles, knowing how to switch accounts isn’t enough — you need the habit of verifying the truly active context before running destructive commands (delete, gcloud compute instances delete, gcloud sql instances delete, and similar).

The fastest way to see all active configuration at once:

gcloud config list

[core]
account = [email protected]
project = myapp-prod-456

Your active configuration is: [default]

This output shows both the account and the project in one command — make this a mandatory step before high-risk commands, exactly like aws sts get-caller-identity in the AWS ecosystem:

# Safe habit before destructive commands
gcloud config list
# Check that the account and project match expectations, then continue:
gcloud compute instances delete legacy-vm --zone=asia-southeast2-a

Consider creating a shell alias like whoami-gcp that runs gcloud config list whenever called. Just like on AWS, the small habit of checking context before destructive commands is far cheaper than the cost of recovering accidentally deleted production resources.

Named Configurations as an Alternative to Manual Switching

Switching accounts and projects manually one by one (config set account then config set project) is quite tedious if you frequently go back and forth between the same work contexts repeatedly. gcloud provides named configurations — a way to group account, project, and region combinations into one named unit that can be switched all at once.

# Creating a new configuration for the staging context
gcloud config configurations create staging
gcloud config set account [email protected]
gcloud config set project myapp-staging-789
gcloud config set compute/region asia-southeast2

# Creating a new configuration for the production context
gcloud config configurations create production
gcloud config set account [email protected]
gcloud config set project myapp-prod-456
gcloud config set compute/region asia-southeast2

After both configurations are created, switching work contexts is just one command — account, project, and region all change together:

gcloud config configurations activate staging
gcloud config configurations activate production

To see all available configurations along with the active one:

gcloud config configurations list

NAME        IS_ACTIVE  ACCOUNT             PROJECT
default     False      [email protected]       myapp-dev-123
staging     False      [email protected]       myapp-staging-789
production  True       [email protected]    myapp-prod-456

This approach is far safer than relying on memory to set account and project manually every time you switch contexts — one activate command ensures both are always consistent as a pair previously verified to be correct.

Safe Practices to Prevent Using the Wrong Account

The gcloud mechanism itself doesn’t automatically prevent mistakes — the work habits around it determine how safe this setup is in daily practice.

Use clear, unambiguous project names. Naming like myapp-prod, myapp-staging is far safer than generic project IDs that are hard to distinguish at a glance.

Run gcloud config list before deploying. Just like verification before destructive commands, this habit should be a mandatory step, not optional — especially before gcloud app deploy, gcloud run deploy, or Terraform commands targeting GCP resources.

Show the active account and project in the shell prompt. Many shell configurations (zsh with the gcloud plugin, or custom scripts) can display the active named configuration directly in the terminal prompt, so you’re always aware of the context without checking manually every time.

Discipline yourself to separate personal and work accounts. Avoid mixing personal account use for work tasks or vice versa, even though technically gcloud allows both to be stored on the same machine.

Consider separate browser profiles. Because gcloud auth login opens a browser for OAuth, the GCP Console (web version) is also prone to account mix-ups if you use the same browser for many Google accounts at once. Separate browser profiles per account significantly reduce this risk.

flowchart TD
    A[Start a work session] --> B[Activate the named configuration per context]
    B --> C[Check the shell prompt shows the active configuration]
    C --> D{Destructive command?}
    D -- Yes --> E[Run gcloud config list]
    E --> F{Account and project match expectations?}
    F -- Yes --> G[Continue the command]
    F -- No --> H[STOP - activate the correct configuration]
    D -- No --> G

Summary Table

Summary

• gcloud auth login stores credentials automatically in the local config directory, unlike AWS which requires manually written profile files.
• gcloud auth login can be run repeatedly to add new accounts — old accounts aren’t removed, all are stored together.
• gcloud auth list shows all stored accounts; gcloud config set account switches the active account globally, not per terminal session.
• The active account and active project are two completely separate axes — switching accounts doesn’t automatically change the project, and this is the most common source of errors.
• gcloud config list is the most reliable way to verify the truly active account and project at once — make it a mandatory habit before destructive commands.
• Named configurations (gcloud config configurations) group account, project, and region into one unit switchable with a single command, reducing the risk of forgetting to change one of them.
• Clear project naming, a shell prompt showing the active configuration, and separate browser profiles per account are the habits that truly prevent mistakes — not just the technical mechanism alone.