Google Cloud Shell Explained: Browser Terminal with gcloud Pre-Installed

Simple explanation

Cloud Shell is a browser-based Linux terminal that Google provisions for you inside the Cloud Console. It is already connected to your Google account, already authenticated to GCP, and already loaded with the tools you need: gcloud, git, Docker, kubectl, Terraform, and several language runtimes.

Cloud Shell is not a development environment you live in full-time. It is a quick-access terminal for running commands, testing ideas, and managing GCP resources from any browser, on any machine, without installing a thing.

What is Google Cloud Shell?

Google Cloud Shell is a fully managed, browser-based shell environment provided by Google. It runs Debian Linux on a small Google-managed VM and is accessible from inside the Cloud Console at no extra charge.

Key facts:

• Opens directly in your browser from the Cloud Console, with nothing to download or install
• Runs on Google-managed infrastructure, not on your local machine
• Automatically authenticated as your Google account; no gcloud auth login required
• Pre-set to the active project you had open in the Console when you launched it
• Pre-installed with the full gcloud CLI and a curated set of developer tools
• Comes with 5 GB of persistent home directory storage that survives across sessions
• Free to use, subject to a 50-hour weekly quota per user

Cloud Shell is primarily useful for learning GCP, running quick one-off commands, and doing admin tasks from a machine where you cannot or do not want to install software. For full-time development, a local gcloud installation is the better choice.

What Cloud Shell includes

Cloud Shell runs Debian Linux and comes with a curated set of tools pre-installed and kept up to date by Google. You do not need to install or configure any of these:

• gcloud CLI: always the latest version, pre-authenticated as your Google account
• git: version control for cloning repositories and committing changes
• Docker: container builds and image management
• kubectl: Kubernetes cluster management
• Terraform: infrastructure as code for managing GCP resources declaratively
• Python 3, Node.js, Java, Go, Ruby: multiple language runtimes for running scripts and applications
• vim, nano, emacs: terminal text editors
• curl, wget, jq, tmux: common shell utilities

How Cloud Shell works

Understanding what happens under the hood makes Cloud Shell’s limits and quirks easier to reason about.

1. You open it from the Cloud Console. Click the >_ terminal icon in the top bar of the Cloud Console. A panel opens at the bottom of the page. On first use it takes about ten seconds to provision.

2. Google provisions the environment for you. Cloud Shell runs on a small Debian VM managed by Google. You do not choose a machine type, configure networking, or pay for compute. Google provisions and manages it automatically.

3. The environment is authenticated to your Google account. The shell starts already logged in. All gcloud commands run as your identity, with the IAM permissions your account holds. No separate authentication step is required.

4. It starts with an active project context. Whichever GCP project was selected in the Console when you opened Cloud Shell becomes the default project for all gcloud commands. You can change it at any time with gcloud config set project PROJECT_ID.

5. Your home directory is persistent, but the rest is ephemeral. Google backs up 5 GB of storage in /home/your-username. Everything else on the VM, including files in /tmp or anywhere outside your home directory, resets when the session ends. Treat the VM itself as disposable.

6. Sessions and quota limits apply. Cloud Shell times out after around 40 minutes of inactivity. Each session has a 12-hour maximum. There is a default 50-hour weekly usage quota per user. These limits matter when you are planning longer-running tasks.

How to open Cloud Shell

Click the >_ terminal icon in the top bar of the Cloud Console. A panel opens at the bottom of the page. You can expand it to a full browser tab using the expand icon if you want more working space.

Once it is open, a few commands are useful from the start:

# Confirm which project is active
gcloud config get-value project

# Switch to a different project from within Cloud Shell
gcloud config set project my-other-project

# Check the gcloud version (always current in Cloud Shell)
gcloud version

# Open a file in the built-in editor from the terminal
cloudshell edit myfile.txt

# Cloud Shell exposes the active project as an environment variable
echo $GOOGLE_CLOUD_PROJECT

You can customise your environment by adding commands to ~/.bashrc or ~/.zshrc. Because these files live in your persistent home directory, they load automatically in every Cloud Shell session:

# Example ~/.bashrc additions for Cloud Shell
alias ll='ls -lAh'
alias proj='gcloud config get-value project'

# Auto-set a default project on session start
gcloud config set project my-default-project 2>/dev/null

When to use this

Cloud Shell is the right tool in specific situations:

• Running gcloud commands without a local install. Useful when you are on a locked-down work laptop, a borrowed machine, or have not yet followed the local installation guide.

• Learning GCP from scratch. You can start running commands and exploring services within seconds of creating an account. Nothing to configure first.

• Quick fixes from any browser. Update an environment variable, check a log, or list service accounts from a coffee shop, your phone, or a machine that is not yours.

• Cloning a repo and testing small changes. Clone a repository into your persistent home directory, edit files, and run quick tests, all in the browser.

• Following tutorials without local setup. Most GCP getting-started guides assume Cloud Shell. It is the fastest path through a tutorial when you want the outcome, not the local environment setup.

• Quick admin tasks. Enabling an API, listing service accounts, or checking IAM bindings takes seconds from the shell without opening a new terminal on your machine.

When not to use this

Cloud Shell has real limits. Knowing them saves frustration:

• Full-time local development. Cloud Shell has a 50-hour weekly quota, a 40-minute inactivity timeout, and no integration with your local IDE or file system. For daily development work, install gcloud locally and use your preferred editor.

• Heavy compute tasks. The Cloud Shell VM is small. Running Docker builds, training scripts, or compute-intensive workloads is slow and may hit session limits before completion. Use a Cloud Run job or a Compute Engine VM for this kind of work.

• Long-running jobs. The 12-hour session cap and 40-minute inactivity timeout mean Cloud Shell is not reliable for processes that run for hours. Use a VM with a proper scheduler or a managed service instead.

• Persistent development environments. If you need a stable environment with persistent installed packages, custom system configuration, and tool integration, Cloud Shell is not that. Everything outside your home directory resets every session.

• Team collaboration or shared access. Cloud Shell is per-user and per-account. It is not a shared workspace. Use Compute Engine VMs or a proper development environment for multi-person work.

Cloud Shell vs gcloud CLI on your machine

Both Cloud Shell and a local gcloud installation let you run the same gcloud commands. The difference is where and how:

Cloud Shell vs Cloud Shell Editor

Cloud Shell and Cloud Shell Editor are two different things that live in the same environment:

• Cloud Shell is the browser-based Linux terminal. You type commands, run scripts, and interact with GCP through the shell prompt.

• Cloud Shell Editor is a browser-based code editor built on the VS Code open-source foundation. Click the pencil icon in Cloud Shell to open it. You get syntax highlighting, a file browser, and a terminal side by side, all in the browser.

The Editor runs on top of the same Cloud Shell environment. Your home directory is the same, authentication is the same, and session limits are the same. Cloud Shell Editor is simply a more comfortable way to browse and edit files than using vim or nano in the terminal.

Use the terminal for running commands. Use the Editor when you need to read and edit multiple files at once or prefer a visual file browser.

Persistent storage and limits

What persists

Cloud Shell gives you 5 GB of persistent storage in your home directory (/home/your-username). Files here survive when you close and reopen Cloud Shell, even across days or weeks. This is where you should store:

• Scripts and configuration files you reuse across sessions
• Cloned repositories you are actively working in
• Shell configuration files like ~/.bashrc and ~/.zshrc

Session and quota limits

• Default weekly usage quota: 50 hours per user
• Inactivity timeout: around 40 minutes
• Maximum session length: 12 hours
• Persistent storage: 5 GB in home directory only
• Compute: modest VM, not suitable for demanding workloads

If the 50-hour weekly quota or session limits start affecting your work, it is a sign you have outgrown Cloud Shell for that use case. Install gcloud locally for unlimited session time and no weekly quota.

Practical example workflows

Check your project config

# See which project and account are active
gcloud config list

# Confirm what IAM roles your account has in the project
gcloud projects get-iam-policy $(gcloud config get-value project)

Clone a repo and deploy to Cloud Run

# Clone a repository into your persistent home directory
git clone https://github.com/your-org/your-app.git
cd your-app

# Deploy directly to Cloud Run from source, no local Docker build step needed
gcloud run deploy my-service \
  --source=. \
  --region=us-central1 \
  --allow-unauthenticated

Cloud Shell is well-suited for this workflow because it is already authenticated, already in the right project context, and already has the gcloud CLI and Docker installed. See Cloud Run overview for more on how Cloud Run works.

Preview a local web app with Web Preview

# Start a web server on port 8080
python3 -m http.server 8080

Keep a process running with tmux

# Start a detached tmux session so the process survives inactivity
tmux new-session -d -s mysession 'python3 long_running_script.py'

# Reattach to the session later
tmux attach -t mysession

Frequently asked questions

What is Google Cloud Shell used for?

Cloud Shell is used for running gcloud commands, managing GCP resources, cloning repositories, deploying services, and learning GCP without needing to install anything locally. It is particularly useful when you are on a machine where you cannot install software, or when you want to get started with GCP immediately.

Is Google Cloud Shell free?

Yes. Cloud Shell itself has no per-hour charge. You get the terminal environment, all pre-installed tools, and 5 GB of home directory storage at no cost, subject to the 50-hour weekly usage quota. Any GCP resources you create through Cloud Shell incur normal charges. See the GCP free tier page to understand what is covered.

Does Cloud Shell save my files?

Partially. Files in your home directory (/home/your-username) persist across sessions. Files outside your home directory reset when the session ends. Your shell configuration files such as ~/.bashrc also persist because they live in your home directory.

What is the difference between Cloud Shell and gcloud CLI?

Cloud Shell is a browser-based terminal that runs on Google-managed infrastructure, already authenticated to your account. The gcloud CLI is a tool you install on your own machine. Both let you run the same gcloud commands. The key differences: Cloud Shell requires no setup but has session and quota limits, while a local gcloud install has no limits but requires an installation step.

Is Cloud Shell good for full-time development?

No. Cloud Shell is designed for quick tasks, tutorials, and one-off commands. The 50-hour weekly quota, 40-minute inactivity timeout, and lack of local IDE integration make it a poor fit for daily development work. Install gcloud locally and use your normal development environment for sustained work.