DEV Community: hasanmn

Using Gemini CLI with Vertex AI (Without Worrying About Your Data)

hasanmn — Fri, 17 Apr 2026 22:24:28 +0000

If you've been playing around with Gemini CLI, you might have glossed over a small but important detail: when you use it through the standard Gemini API, there's a real chance your input data gets fed back into Google's model training pipeline. For personal tinkering, that's probably fine. For anything work-related -- internal tools, client data, proprietary code -- that's a different story.

The fix is straightforward: route everything through Vertex AI instead. Google's enterprise data handling guarantees apply there, which means your prompts stay your prompts. This post walks through the full setup from scratch.

Prerequisites

You'll need Node.js installed on your machine. That's it on the local side. On the cloud side, you'll need a GCP project with billing enabled and the gcloud CLI installed.

Step 1 -- Install Gemini CLI

npm install -g @google/gemini-cli

A global install so you can call gemini from anywhere in your terminal.

Step 2 -- Configure GCP

Two things to do in the GCP console:

Enable the Vertex AI API for your project. Navigate to APIs & Services → Library, search for "Vertex AI API", and hit Enable.

Create a service account for the CLI to impersonate:

# Create the service account
gcloud iam service-accounts create svc-vertex-cli \
  --display-name="Gemini CLI Service Account"

# Grant the minimum required role
gcloud projects add-iam-policy-binding <PROJECT_ID> \
  --member="serviceAccount:svc-vertex-cli@<PROJECT_ID>.iam.gserviceaccount.com" \
  --role="roles/aiplatform.user"

The roles/aiplatform.user role is the minimum needed to execute prompts. If your organization enforces keyless authentication (a smart policy worth enabling), you can ban service account key creation under Organization Policies -- the ADC approach in Step 4 doesn't need a key file anyway.

Step 3 -- Set Up Environment Variables

Gemini CLI loads environment variables from ~/.gemini/.env. Create it if it doesn't exist:

mkdir -p ~/.gemini
vim ~/.gemini/.env

Then add the following:

GOOGLE_GENAI_USE_VERTEXAI=true
GOOGLE_CLOUD_PROJECT=<PROJECT_ID>
GOOGLE_CLOUD_LOCATION=us-central1

A note on location: us-central1 is the safest default since it has the broadest model availability. Other regions may not support all models yet.

Note: If you have GOOGLE_API_KEY or GEMINI_API_KEY set anywhere in your environment, you must unset them. They take precedence and will prevent ADC from working.
unset GOOGLE_API_KEY
unset GEMINI_API_KEY

Step 4 -- Log In with ADC

Application Default Credentials (ADC) is how the CLI authenticates without needing a service account key file sitting on disk. The trick is to log in as yourself first, then impersonate the service account:

# Log in with your own Google account
gcloud auth login

# Create ADC credentials that impersonate the service account
gcloud auth application-default login \
  --impersonate-service-account=svc-vertex-cli@<PROJECT_ID>.iam.gserviceaccount.com

The second command creates a credentials file that the CLI (and any other GCP SDK) picks up automatically. Your personal account needs the roles/iam.serviceAccountTokenCreator role on the service account to impersonate it -- if you get a permission error, that's the likely cause.

Step 5 -- Run It

Interactive mode -- starts a REPL-style session:

gemini

Single prompt -- great for scripting or quick one-offs:

gemini -p "Summarize this in 3 bullet points: ..."

Specify a model -- pass the model ID directly:

gemini -m gemini-2.5-pro

Why Bother with All This?

Fair question -- the standard Gemini API is easier to set up. The trade-off comes down to data control. Vertex AI gives you:

No training data opt-in -- your inputs aren't used to improve Google's models
Enterprise compliance -- easier to satisfy security reviews and internal policies
Audit logging -- Cloud Logging captures every API call, useful for debugging and compliance
Keyless auth -- no credentials file to accidentally commit or rotate

For a CLI tool you're going to use daily on real work, that's a worthwhile few extra minutes of setup.

Quick Reference

Command	What it does
`gemini`	Start interactive mode
`gemini -p "..."`	Run a single prompt
`gemini -m <model-id>`	Specify a model

Once it's running, the experience is identical to the regular Gemini CLI -- the Vertex AI routing is completely transparent. You get all the same features, just without the data handling concerns.

Automatically Update `created_by` and `updated_by` in Laravel Using Bootable Traits

hasanmn — Sun, 17 Oct 2021 01:43:41 +0000

If you use timestamps feature in Laravel, then you got the free feature of auto-update on created_at and update_at columns when the model is created or updated. Now, what if you want the same thing for you own customs created_by and updated_by columns? You want them to be automatically updated with the logged in user's id. Well, you can use observer or hook into model's lifecycle in boot or booted methods of the model. Let's use example of Post model as follows:

<?php

namespace App\Models;

use Illuminate\Database\Eloquent\Model;

class Post extends Model
{

    protected static function boot()
    {

        parent::boot();

        // updating created_by and updated_by when model is created
        static::creating(function ($model) {
            if (!$model->isDirty('created_by')) {
                $model->created_by = auth()->user()->id;
            }
            if (!$model->isDirty('updated_by')) {
                $model->updated_by = auth()->user()->id;
            }
        });

        // updating updated_by when model is updated
        static::updating(function ($model) {
            if (!$model->isDirty('updated_by')) {
                $model->updated_by = auth()->user()->id;
            }
        });
    }

}

In the above code, we hook into creating and updating lifecycle of the Post model. This works perfectly and is certainly convenient if you have only few models to apply this feature to. But what if you have many models? You have to apply the above code to all the models. Yes, it will work, but you know, it is not DRY.

The bootable trait, which is also used by Laravel's SoftDeletes trait, can save you a ton in this situation. Laravel' Eloquent model will boot a trait's method with the name of pattern boot[TraitName]. If you take a look into Laravel's source code, you can find the snippet below.

    /**
     * Bootstrap the model and its traits.
     *
     * @return void
     */
    protected static function boot()
    {
        static::bootTraits();
    }

    /**
     * Boot all of the bootable traits on the model.
     *
     * @return void
     */
    protected static function bootTraits()
    {
        $class = static::class;

        $booted = [];

        foreach (class_uses_recursive($class) as $trait) {
            $method = 'boot'.class_basename($trait);

            if (method_exists($class, $method) && ! in_array($method, $booted)) {
                forward_static_call([$class, $method]);

                $booted[] = $method;
            }

        }
    }

The above code tells us the trait with the name of boot[traitName] will also be invoked when the model is booted.

Knowing this, we now can create a new trait called CreatedUpdatedBy with a method of bootCreatedUpdatedBy as follows.

<?php

namespace App\Traits;

trait CreatedUpdatedBy
{
    public static function bootCreatedUpdatedBy()
    {
        // updating created_by and updated_by when model is created
        static::creating(function ($model) {
            if (!$model->isDirty('created_by')) {
                $model->created_by = auth()->user()->id;
            }
            if (!$model->isDirty('updated_by')) {
                $model->updated_by = auth()->user()->id;
            }
        });

        // updating updated_by when model is updated
        static::updating(function ($model) {
            if (!$model->isDirty('updated_by')) {
                $model->updated_by = auth()->user()->id;
            }
        });
    }
}

Next, we can easily use it in any model that we want to apply it to just like when we use SoftDeletes trait. For example in our Post method, it should be looked like this.

<?php

namespace App\Models;

use App\Traits\CreatedUpdatedBy;
use Illuminate\Database\Eloquent\Model;

class Post extends Model
{
    use CreatedUpdatedBy;

}

Whenever the Post model is created or updated, the created_by and/or updated_by will be automatically updated. Cool! Isn't it? 😎

Note that the above is just one example of using bootable traits in the Eloquent model to automatically update created_by and updated_by. However, there are many applications of it. For example, you can use it to automatically delete related models, update slugs, and many others you can think of.

How to Create Your Own Snippets in VS Code

hasanmn — Sun, 30 May 2021 01:50:06 +0000

I am always looking for a new way to improve my workflow, to be more efficient. I found that using snippets is one of many things that surely can enhance my productivity. With snippets, using only several characters you get a chunk of codes that you often use. Certainly, there are a lot of snippet extensions in the VS Code marketplace. These snippets are super awesome, offering you a huge number of snippets; any snippet that you can imagine probably exists there. But, to be honest, I only use a few of them, and I have a hard time remembering their prefixes. I feel that it is better to create my own snippet that suits my own workflow, and hence I can remember easily.

Here is how I create my own snippets:

Install Snippet Creator Extension
In the editor, type a block of codes that you want to use as the snippet. Highlight them, open the command palette ( use ctrl + shift + p), select Create Snippet, and if you follow the suggested options, you will be fine.
Modify the created snippet to further accommodate your needs. Open command palette and select Preference: Configure User Snippets.

Now you can enjoy it.