Local Emulators and Cloud Developer Tools

Emulating Google Cloud services means running local copies of cloud services on a developer machine for development and testing. The Google Cloud software development kit (SDK) distributes these copies as emulator components, and gcloud emulators commands start local instances that simulate production behavior. Traffic flows from the application to the local emulator instead of Google Cloud, so test data stays isolated and teams avoid changing production services or spending quota.

1.1Available Emulators and Isolation Boundary

Available local emulators are high-fidelity simulations of production database and messaging services that run on localhost instead of Google Cloud. The emulator creates an isolated test boundary where resources exist only for the session, and stopping the emulator ends that isolated environment. Cloud Client Libraries (opens in a new tab) connect to a local host and port rather than a Google Cloud endpoint when an emulator variable is set.

• Bigtable emulator: tests a local NoSQL wide-column database held only in memory.
• Cloud Spanner emulator: tests a locally simulated globally distributed relational database.
• Pub/Sub emulator: validates asynchronous messaging workflows including topics, subscriptions, publishing, and subscribing.
• Firestore emulator: builds and tests mobile, web, and server apps with a local document database.
• Datastore emulator: develops against a local NoSQL document database, also described as Firestore in Datastore mode.

1.2Installing and Starting Emulators

Installing emulator components adds the emulator binaries to the Google Cloud command-line interface (CLI) before any local endpoint can start. Installation must complete first with gcloud components commands, then a start command creates a local server process that listens on a host and port. When multiple emulators run at the same time, each start command must specify its host and port explicitly so the local endpoints do not conflict.

The Bigtable install path uses gcloud components update beta before starting, and a missing binary triggers a prompt to download it on first use. The Pub/Sub project ID string does not need to represent a real Google Cloud project because execution stays local. Pub/Sub can listen on all addresses with --host-port=0.0.0.0:8085 or on IPv4 with --host-port=127.0.0.1:8085 when IPv6 is disabled. Docker provides an alternative path by mapping container ports to the same host ports, such as -p 9010:9010 -p 9020:9020 for Spanner.

1.3Connecting Applications With Environment Variables

Connecting applications to running emulators means pointing client libraries from production endpoints to the local endpoint with an environment variable. The client library checks for the variable when the application starts and sends creates, reads, writes, publishes, and subscribes to the emulator if the variable is present. When the variable is absent, the same code flows to the production Google Cloud endpoint with no code change.

The Bigtable path sets BIGTABLE_EMULATOR_HOST=localhost:8086, and any project and instance name can then create tables and read or write data. The Cloud Spanner path sets SPANNER_EMULATOR_HOST=localhost:9010, which can also be set with $(gcloud emulators spanner env-init). The Pub/Sub path sets PUBSUB_EMULATOR_HOST, set automatically with $(gcloud beta emulators pubsub env-init) on the same machine or manually on a different machine. The Bigtable emulator does not provide administrative APIs for instances and clusters, does not support a secure connection, and cannot be used in the HBase shell.

1.4Stopping Emulators and Managing Test Data

Stopping emulators ends the local server process and its session-scoped test state. The foreground process stops with Control-C, which ends Bigtable in-memory storage and Pub/Sub topics, subscriptions, and messages held for that session. The stop order matters: first stop the emulator process, then remove the local connection settings so later commands do not continue targeting a closed port.

The ordered local test workflow is:

1. Start the emulator: run the start command and note the printed host and port.
2. Set the host variable: set the matching emulator variable on the machine that runs the application.
3. Run and validate: execute reads, writes, publishes, and subscribes locally, then stop the emulator and unset the variable.

After Bigtable testing, unset BIGTABLE_EMULATOR_HOST so the library returns to production behavior. After Pub/Sub testing, unset PUBSUB_EMULATOR_HOST for the same reason. The Pub/Sub emulator accepts unencrypted http push endpoints for local testing, while production Pub/Sub allows only secure https push endpoints.

Command-line and console resource orchestration is the practice of deploying, scaling, monitoring, and cleaning up Google Cloud resources through visual and programmatic interfaces. The Google Cloud console (opens in a new tab) is the web-based graphical hub for creation and governance, while the Google Cloud CLI is the primary command-line tool for scripting. Cloud Shell (opens in a new tab) bridges the two by running the CLI inside the browser with the current project already selected.

2.1Google Cloud Console, Cloud Shell, and Google Cloud CLI

The Google Cloud console calls the same underlying Google Cloud APIs that command-line tools use, so work started visually can be continued in code. The console organizes work into resource creation and orchestration, administration and governance with Identity and Access Management (IAM) and billing, data management and visualization, and integrated AI assistance. Cloud Code (opens in a new tab) in the console context provides related help for architecture questions and error troubleshooting.

Cloud Shell is a web-based terminal that includes the Google Cloud CLI without local installation. Cloud Shell runs on a virtual machine (VM) that Google Cloud provisions each time the session starts, and the first session also creates a persistent $HOME directory that is restored later. The provisioned VM includes the latest CLI with values already set for the current project, so commands run immediately. Cloud Shell Editor is the built-in editor based on Code OSS that lets developers browse, edit, and keep terminal access in the same browser session.

A standard setup workflow moves from identity to project to defaults to access:

1. Initialize and sign in: run gcloud init to authenticate and select initial defaults.
2. Create or select the project: run gcloud projects create PROJECT_ID, then gcloud config set project PROJECT_ID to target it.
3. Set location defaults: run gcloud config set compute/region REGION and gcloud config set compute/zone ZONE.
4. Verify and isolate work: run gcloud config list, and use gcloud config configurations create NAME for a separate named configuration.
5. Create automation identity: run gcloud iam service-accounts create SERVICE_ACCOUNT_NAME for workloads.
6. Grant access: run gcloud projects add-iam-policy-binding with the member and --role once per required role.

2.2Cloud Code and Gemini Assistance for Full-Cycle Development

Cloud Code is an integrated development environment (IDE) extension that brings Google Kubernetes Engine (GKE) and Cloud Run directly into the editor. Cloud Code supports creating an app from a template, local emulation, deployment, and monitoring in one place with run-ready samples and configuration snippets. It runs in Visual Studio (VS) Code, IntelliJ and other supported JetBrains IDEs, and Cloud Shell Editor, and it supports Go, Java, Node.js, Python, and .NET Core.

Gemini Code Assist Standard and Enterprise is the AI-powered collaborator inside Cloud Code that generates code, fixes problems, and provides inline suggestions. Gemini Cloud Assist extends that help across the application lifecycle to design, deploy, troubleshoot, and optimize apps for efficiency, cost, reliability, and security. Gemini Code Assist is now a separate plugin from Cloud Code and requires selecting a Google Cloud project with IAM permissions. Container builds often use Google Cloud buildpacks to produce secure images from source without a Dockerfile, then Skaffold and kubectl deploy to GKE while Cloud Run Explorer and Log Viewer track Cloud Run services.

2.3Cloud Workstations Hierarchy, Lifecycle, and Secure Access

Cloud Workstations (opens in a new tab) is a managed development environment service that provides secure, preconfigured cloud IDEs on Compute Engine VMs. Platform teams define a reproducible environment once in a template, and developers launch their own instances that run inside the team's project and Virtual Private Cloud (VPC) network. Developers connect through a browser IDE, local VS Code or IntelliJ IDEA Ultimate and PyCharm Professional, or Secure Shell (SSH).

Workstation resources form a three-level hierarchy where each level has a different owner:

• Workstation cluster: a group of workstations in a single region attached to a specific VPC network, with a Google-managed controller and gateway.
• Workstation configuration: a template that defines machine type, persistent storage, container image, IDE, timeouts, and IAM access.
• Workstation: a preconfigured environment with cloud IDE and tooling that runs on a Compute Engine VM with an attached persistent disk.

A workstation session moves through an ordered lifecycle where compute is ephemeral and data persists:

1. Start: Cloud Workstations creates an ephemeral Compute Engine VM in the project VPC and attaches the persistent home disk.
2. Run: the developer codes in the container, and files saved to the home directory write to the attached disk.
3. Stop: the VM is deleted with all runtime data, and the persistent disk is detached.
4. Restart: the next start provisions a fresh VM from the current configuration and reattaches the same home disk.

Client traffic flows from the developer client to the cluster gateway to the VM gateway to the container. The cluster gateway forwards traffic to the correct VM, and the VM gateway authenticates and authorizes it before forwarding to the IDE container. The cluster gateway is public by default, but administrators can enable a fully private gateway so only private-network endpoints can reach workstations. Because VMs run inside the project VPC, teams can apply firewall rules, enable VPC Flow Logs, and use VPC Service Controls and Secure Web Proxy to limit exfiltration.

Integrating an IDE with Google Cloud means connecting the editor to the Cloud SDK, project authentication, and AI tooling so suggestions match the real project. Cloud Code provides the IDE integration for GKE and Cloud Run, while Gemini Code Assist Standard and Enterprise provides in-editor help and Antigravity provides agent-based orchestration. Cloud Code integrates with the Google Cloud SDK to provide unified authentication, so the IDE, cloud project, and AI assistant share the same identity and project selection.

3.1AI Coding Assistance and Agent Orchestration

AI-powered coding assistance in the IDE brings cloud development directly into VS Code, IntelliJ IDEA and other supported JetBrains IDEs, and Cloud Shell Editor. Cloud Code supports Go, Java, Node.js, Python, and .NET Core so developers can build, run, deploy, and monitor without leaving the editor. Gemini Code Assist (opens in a new tab) acts as the AI collaborator that generates code, fixes problems, and provides inline suggestions while coding.

Gemini Code Assist Standard and Enterprise depends on explicit cloud setup and is not enabled by default. First the developer connects Cloud Code to Google Cloud, then selects a Google Cloud project, then enables the required IAM permissions before AI assistance can run. Organizations that previously used the combined plugin must allow incoming traffic to the Cloud Code API through VPC Service Controls because Gemini Code Assist now runs as a separate plugin.

Antigravity 2.0 is a graphical environment that manages parallel autonomous subagents, runs scheduled tasks, and coordinates workflows across editor, terminal, and browser. Antigravity CLI is the AI-powered command-line companion for managing Google Cloud resources with natural language. Starting June 18, 2026, Gemini Code Assist IDE extensions and Gemini CLI stopped serving requests for the individuals, Google AI Pro, and Google AI Ultra tiers, and affected users migrate to Antigravity and Antigravity CLI.

3.2Contextual Protocols With MCP Servers and Developer Knowledge

Contextual protocols with Model Context Protocol (MCP) servers give coding agents access to official Google documentation during development. The Developer Knowledge remote MCP server lets an agent search official developer documentation and retrieve information for products such as Google Cloud, Firebase, Android, and Maps. Requests flow from the agent to the MCP server to the documentation source, and answers flow back into the editor or terminal with project-aware context.

The google-cloud-developer plugin is the package that connects agents such as Claude Code, Antigravity CLI, and Codex CLI to Google Cloud tasks and to that MCP server. The plugin provides skills for account creation, billing setup, project management, and authentication, plus the finding-google-skills skill that locates and runs the right product skill on demand. The agent depends on the Developer Knowledge API being enabled in the selected project.

Setup for Claude Code follows an ordered workflow:

1. Add marketplace and install plugin: add the Google plugins marketplace, then install google-cloud-developer.
2. Enable API: run gcloud services enable developerknowledge.googleapis.com for the project.
3. Create API key: create and secure an API key for the Developer Knowledge API.
4. Export key: export DEVELOPERKNOWLEDGE_API_KEY before starting Claude Code so the agent can authenticate to the MCP server.

3.3Cloud SDK Authentication and Cloud Client Libraries

The Google Cloud SDK is a suite of libraries and tools for interacting with Google Cloud services from a local workstation. The suite includes the Google Cloud CLI for managing resources, Cloud Client Libraries (opens in a new tab) for calling APIs from code, IDE extensions, and local emulators. Prerequisites for secure access are a Cloud Identity or Google Workspace user identity, required IAM roles on the target project, and verified Cloud Billing.

Setup follows an ordered workflow where each step depends on the previous one:

1. Install the gcloud CLI: install the CLI so gcloud commands are available locally.
2. Run gcloud init: sign in with a user identity and select the default project.
3. Run gcloud auth application-default login: create a local Application Default Credentials (ADC) file so application code can authenticate automatically.

Application Default Credentials (ADC) is the framework that lets local application code authenticate without embedded keys. Credentials flow from developer sign-in to a local ADC file, then from that file through Cloud Client Libraries to Google Cloud APIs. This separation matters because gcloud init authenticates the CLI for administrative commands, while ADC authenticates application code and local debugging sessions. Cloud Code shows the active project in the status bar and depends on ADC for local run and debug sessions that call Google APIs.

3.4Inner-Loop Development With Cloud Code

Inner-loop development with Cloud Code means editing, running, debugging, and monitoring containerized apps without constant context switching. Cloud Code supports the full cycle from creating an app from a template to monitoring deployed resources, with run-ready samples and configuration snippets. Supported JetBrains IDEs (opens in a new tab) include IntelliJ and related editors with limited support for Android Studio, alongside VS Code and Cloud Shell Editor where Cloud Code is available by default.

Local GKE development means creating or opening a Kubernetes application, customizing YAML with intelligent authoring, and running against local minikube before using a cloud GKE cluster. Skaffold modules let parts of a large GKE application be developed independently, with dependencies defined between skaffold.yaml files so one service can depend on another module. Local Cloud Run development means building and testing a service with the built-in Cloud Run emulator before deploying to hosted Cloud Run. The secret value flows from Secret Manager to the running application at runtime, while the codebase contains only a reference, so passwords and keys stay out of source control.

The inner-loop sequence runs in a fixed order:

1. Edit: change application code or Kubernetes YAML in the IDE.
2. Build: rebuild the container, using Google Cloud buildpacks when no Dockerfile is present.
3. Run: redeploy to the watch-mode target, either the local emulator or cluster.
4. Observe: view output in Cloud Run Explorer and Log Viewer or GKE resource views, then repeat.

Key Facts

• The Bigtable emulator listens on localhost:8086, the Cloud Spanner emulator uses localhost:9010 for gRPC and localhost:9020 for REST, and the Pub/Sub emulator listens on port 8085.
• Cloud Client Libraries send traffic to the local emulator when BIGTABLE_EMULATOR_HOST, SPANNER_EMULATOR_HOST, or PUBSUB_EMULATOR_HOST is set, and send traffic to production Google Cloud when the variable is absent.
• Cloud Shell runs in the browser with the Google Cloud CLI preinstalled and the current project preset, while a local CLI requires gcloud init and gcloud config set project PROJECT_ID.
• Cloud Workstations runs each workstation on an ephemeral Compute Engine VM in the customer's VPC with a persistent home disk, and configuration updates take effect only after restart.
• gcloud init signs in the gcloud CLI and selects the default project, while gcloud auth application-default login creates the local Application Default Credentials file used by application code.