The Google Cloud CLI (gcloud, formerly called the Google Cloud SDK) is the command-line tool for Google Cloud Platform: it manages projects, Compute Engine VMs, Cloud Storage buckets, IAM and almost every other GCP service. In this tutorial you will install it on an Ubuntu 24.04 server from Google's official APT repository, authenticate from a machine without a browser, configure a default project, and use it to move files to Cloud Storage and manage a VM.

Prerequisites

To follow this guide you need:

  • A server running Ubuntu 24.04 LTS, for example a CubePath VPS.
  • A non-root user with sudo privileges.
  • A Google Cloud account with at least one project and billing enabled (required for Compute Engine and Cloud Storage).
  • A computer with a web browser, used once to approve the login.

Step 1 - Adding the Google Cloud APT repository

Google publishes signed packages for Debian and Ubuntu. Installing from the repository means apt upgrade keeps gcloud up to date together with the rest of the system.

Install the tools needed to fetch the signing key:

sudo apt update
sudo apt install -y ca-certificates curl gnupg

Download Google's signing key and store it in /etc/apt/keyrings:

sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo gpg --dearmor -o /etc/apt/keyrings/cloud.google.gpg

Add the repository, pointing it at that key with signed-by:

echo "deb [signed-by=/etc/apt/keyrings/cloud.google.gpg] https://packages.cloud.google.com/apt cloud-sdk main" | sudo tee /etc/apt/sources.list.d/google-cloud-sdk.list

Step 2 - Installing the gcloud CLI

Refresh the package index and install the google-cloud-cli package:

sudo apt update
sudo apt install -y google-cloud-cli

Verify the installation:

gcloud version
Google Cloud SDK 5xx.0.0
bq 2.1.x
bundled-python3-unix 3.12.x
core 2026.xx.xx
gcloud-crc32c 1.0.0
gsutil 5.xx

Because the CLI is managed by APT, the gcloud components install and gcloud components update commands are disabled. Extra components are separate packages instead. For example, if you work with GKE clusters:

sudo apt install -y kubectl google-cloud-cli-gke-gcloud-auth-plugin

Step 3 - Authenticating from a headless server

A server usually has no browser, so ask gcloud to print the login URL instead of opening one:

gcloud auth login --no-launch-browser

The command prints a long URL. Open it on your own computer, sign in with your Google account, approve the access request and copy the verification code that Google shows. Paste it back into the terminal:

Enter authorization code: 4/0Axxxxxxxxxxxxxxxxxxxxxx
You are now logged in as [[email protected]].

List the credentialed accounts to confirm:

gcloud auth list
    Credentialed Accounts
ACTIVE  ACCOUNT
*       [email protected]

Step 4 - Setting the default project and region

Most commands need a project. List the projects your account can access:

gcloud projects list
PROJECT_ID          NAME            PROJECT_NUMBER
your-project-id     My Project      123456789012

Set the default project, and a default Compute Engine region and zone so you do not have to pass --zone on every command:

gcloud config set project your-project-id
gcloud config set compute/region europe-west1
gcloud config set compute/zone europe-west1-b

Check the active configuration:

gcloud config list
[compute]
region = europe-west1
zone = europe-west1-b
[core]
account = [email protected]
project = your-project-id

APIs are disabled by default in new projects. Enable the ones used in this tutorial:

gcloud services enable compute.googleapis.com storage.googleapis.com

Step 5 - Working with Cloud Storage

Use the gcloud storage command group for buckets and objects. It replaces the older gsutil tool, which is still installed but no longer recommended for new scripts.

Bucket names are global across all of Google Cloud, so pick a unique name. Create a bucket in the same region as your default:

gcloud storage buckets create gs://your_bucket_name --location=europe-west1 --uniform-bucket-level-access

Upload a file and a whole directory:

gcloud storage cp /etc/hostname gs://your_bucket_name/
gcloud storage cp --recursive /var/log/nginx gs://your_bucket_name/logs/

Keep a directory in sync with a bucket prefix. rsync only transfers new or changed files; --delete-unmatched-destination-objects also removes objects that no longer exist locally, so leave it out if the bucket should keep deleted files:

gcloud storage rsync --recursive /var/www gs://your_bucket_name/www

List the bucket contents with sizes:

gcloud storage ls --long --readable-sizes gs://your_bucket_name/
      9.00B  2026-09-25T10:02:11Z  gs://your_bucket_name/hostname
                                 gs://your_bucket_name/logs/
                                 gs://your_bucket_name/www/
TOTAL: 1 objects, 9 bytes (9.00B)

Download an object back to the server:

gcloud storage cp gs://your_bucket_name/hostname /tmp/hostname

Step 6 - Managing Compute Engine VMs

Create a small Ubuntu 24.04 VM. Canonical publishes its images in the ubuntu-os-cloud project, with separate image families per architecture:

gcloud compute instances create my-vm \
  --machine-type=e2-small \
  --image-family=ubuntu-2404-lts-amd64 \
  --image-project=ubuntu-os-cloud \
  --boot-disk-size=20GB

List your instances and their IP addresses:

gcloud compute instances list
NAME   ZONE            MACHINE_TYPE  PREEMPTIBLE  INTERNAL_IP  EXTERNAL_IP    STATUS
my-vm  europe-west1-b  e2-small                   10.132.0.2   34.xx.xx.xx    RUNNING

Connect over SSH. gcloud generates a key pair on first use and publishes the public key to the project metadata:

gcloud compute ssh my-vm

Stop the VM when you do not need it, and delete it when you are done so it stops generating costs:

gcloud compute instances stop my-vm
gcloud compute instances delete my-vm

Step 7 - Using a service account for automation

Your personal login is fine for interactive work, but unattended jobs such as a nightly backup should use a service account with only the permissions they need. Create one:

gcloud iam service-accounts create backup-agent --display-name="Backup agent"

Grant it write access to objects in your bucket only, instead of a project-wide role:

gcloud storage buckets add-iam-policy-binding gs://your_bucket_name \
  --member="serviceAccount:[email protected]" \
  --role="roles/storage.objectUser"

A server outside Google Cloud needs a key file to act as the service account. Create it in a directory only your user can read:

mkdir -p ~/.config/gcloud/keys && chmod 700 ~/.config/gcloud/keys
gcloud iam service-accounts keys create ~/.config/gcloud/keys/backup-agent.json \
  --iam-account=backup-agent@your-project-id.iam.gserviceaccount.com
chmod 600 ~/.config/gcloud/keys/backup-agent.json

Rather than replacing your personal login, keep the service account in its own named configuration (see Step 8), then activate the key there:

gcloud config configurations create backup
gcloud auth activate-service-account --key-file="$HOME/.config/gcloud/keys/backup-agent.json"
gcloud config set project your-project-id

Step 8 - Switching between configurations

Named configurations store a set of properties (account, project, region) that you can switch between, which is useful when you manage several projects. List them:

gcloud config configurations list
NAME     IS_ACTIVE  ACCOUNT                                                 PROJECT          COMPUTE_DEFAULT_ZONE  COMPUTE_DEFAULT_REGION
backup   True       [email protected]    your-project-id
default  False      [email protected]                                         your-project-id  europe-west1-b        europe-west1

Switch back to your personal configuration:

gcloud config configurations activate default

For a single command, use --configuration without changing the active one, which is what you would put in a cron job or systemd unit:

gcloud storage ls gs://your_bucket_name/ --configuration=backup

Troubleshooting

The required property [project] is not currently set: no default project in the active configuration. Run gcloud config set project your-project-id or pass --project.

API [compute.googleapis.com] not enabled on project: enable it with gcloud services enable compute.googleapis.com and wait a minute before retrying.

403 ... does not have storage.objects.create access: the active account lacks the IAM role for that bucket. Check which account is active with gcloud auth list and review bindings with gcloud storage buckets get-iam-policy gs://your_bucket_name.

gcloud components update says the component manager is disabled: this is expected on an APT installation. Update with sudo apt update && sudo apt install --only-upgrade google-cloud-cli instead.

Conclusion

You installed the gcloud CLI from Google's APT repository, logged in from a headless server, configured a default project and region, and used it to manage Cloud Storage objects and a Compute Engine VM, with a separate service account for automation. Next, you could schedule gcloud storage rsync with a systemd timer to back up this server, explore gcloud compute firewall-rules to control VM traffic, or learn the --format and --filter flags to script against gcloud output.