DEV Community: Caleb Duff

Managed Inference on Google Cloud: Pairing the Gemini Enterprise Agent Platform with Cloud Run

Caleb Duff — Wed, 12 Aug 2026 15:45:27 +0000

If you have ever wanted to ship an AI-powered application without managing GPUs, model servers, or scaling infrastructure yourself, this guide is for you.

Managed inference simply means letting a cloud provider run the AI model for you: you send a request, the platform handles the compute, and you get a response back. On Google Cloud, the cleanest way to do this today is to pair the Gemini Enterprise Agent Platform (formerly Vertex AI) with Google Cloud Run, dividing responsibilities between the two services. The Agent Platform serves as the orchestration and intelligence engine, while Cloud Run hosts your custom application logic, front-end UIs, or Model Context Protocol (MCP) servers.

By the end of this article, you will be able to:

Explain the hybrid architecture and why each layer exists
Define an AI agent in code using the Agent Development Kit (ADK)
Deploy your app layer to Cloud Run with a single command
Choose between online and batch inference for your workload
Secure and monitor the whole setup in production

New to the underlying concept? Start with Google Cloud's primer: What is AI inference?

Prerequisites

To follow along hands-on, you will need:

A Google Cloud project with billing enabled
The gcloud CLI installed and authenticated
Python 3.10+ and the ADK installed (pip install google-adk)

You can also read this purely as an architecture walkthrough; every step is explained, not just shown.

1. The Architectural Blueprint

This pattern splits your system into independent, auto-scaling tiers:

[ Client / Web UI ] ──> [ Cloud Run Service ] (App Logic / Tool Front End)
                                │
                                ▼
        [ Gemini Enterprise Agent Platform — Agent Runtime ]
            (Orchestration, Intent Analysis, Memory)
                                │
                                ▼
              [ Managed Inference / Model Garden ]
                 (Gemini 3.x Pro / Flash models)

Why split it this way? Each tier scales independently and fails independently. Your web front end can handle a traffic spike without touching the model layer, and you can swap models without redeploying your application code. It also creates a clean security boundary, clients only ever talk to Cloud Run, never directly to the model.

Here is what each layer actually does:

Cloud Run runs your specialized business logic, secures client-facing endpoints with Identity-Aware Proxy (IAP), and hosts external tools, MCP servers, and APIs. Think of it as everything you build.
The Agent Platform (Agent Runtime) manages active agent state, long-term memory, and the model's reasoning steps in a centralized, fully managed runtime. Think of it as everything Google runs for you.

2. Build Your Agent Code with the ADK

Use the open-source Agent Development Kit (ADK) to define your agent's behavior in code and bind it to a model. The key idea to understand: tools are plain Python functions. The ADK reads each function's docstring to decide when and how to call it; so a clear docstring is not documentation nicety, it is part of your agent's logic.

# agent.py
from google.adk.agents import Agent

def call_internal_business_system(query: str) -> str:
    """Invokes secure business workflows deployed on Cloud Run."""
    # Logic to securely call your Cloud Run service URL
    return "Data retrieved from secure internal backend."

# Define an agent that targets a current Gemini model
root_agent = Agent(
    name="enterprise_inference_agent",
    model="gemini-3.5-flash",  # Or another current model from Model Garden
    instruction="You are a data processing assistant using managed inference.",
    tools=[call_internal_business_system],
)

Breaking down the four fields:

name — an identifier for your agent, used in logs and traces.
model — which Gemini model handles the reasoning. Flash models are faster and cheaper; Pro models handle more complex reasoning.
instruction — the agent's system prompt, shaping its behavior on every request.
tools — the Python functions the model is allowed to call. When a user request matches a tool's docstring, the model invokes it.

Note: Gemini 1.0 and 1.5 models (including gemini-1.5-pro) have been retired and now return errors. Always target a currently supported model, such as gemini-3.5-flash, gemini-3.6-flash, or a Gemini 3.x Pro release from Model Garden.

3. Containerize and Deploy the App Layer to Cloud Run

When deploying your orchestration backend or front-end dashboard, the tooling can package and push the container for you. Two small steps get you there.

Step A: Configure Service Account Permissions

In Google Cloud, services do not trust each other by default, your Cloud Run instance needs explicit permission to invoke Agent Platform endpoints. This command grants its service account that permission:

gcloud projects add-iam-policy-binding YOUR_PROJECT_ID \
    --member="serviceAccount:YOUR_RUN_SA@YOUR_PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/aiplatform.user"

In plain terms: "let this Cloud Run service call the AI platform." This is the step people most often forget; if your deployed service returns permission errors, come back here first.

Step B: Build and Deploy

The ADK ships with a one-command deployment path. Under the hood, it does three things: builds your container image, pushes it to Artifact Registry, and creates (or updates) the Cloud Run service.

# Deploys your custom agent or tool layer directly to Cloud Run
adk deploy cloud_run \
    --project="YOUR_PROJECT_ID" \
    --region="us-central1" \
    --service_name="agent-inference-backend" \
    path/to/your/agent

Alternatively, the Agents CLI (agents-cli) can scaffold the deployment configuration for a Cloud Run target. For example, agents-cli scaffold enhance --deployment-target cloud_run and works from inside your preferred AI coding tool. Either route wires up your environment variables, including model targets and the public service URL.

4. Online and Batch Inference Routines

Once the plumbing is in place, there are two primary ways to trigger managed inference. Choosing correctly comes down to one question: does a human need the answer right now?

Online inference (low-latency UI): Make synchronous API calls from your Cloud Run front end directly to the deployed agent endpoint for real-time chat, tool calls, or step-by-step reasoning. Example: a customer support chatbot where every second of latency matters.
Batch inference (high-volume data): For large data processing jobs, submit an asynchronous batch prediction job through the Agent Platform SDK. The platform provisions dedicated compute, runs the inference tasks, writes results and logs to Cloud Storage, and tears down the compute automatically when the job completes. Example: classifying 100,000 support tickets overnight; nobody is waiting on a single response, so throughput and cost matter more than latency.

Batch jobs are typically much cheaper per request, so a good rule of thumb is: default to batch, and reserve online inference for genuinely interactive experiences.

5. Secure and Monitor the Architecture

A demo can skip this section. Production cannot.

Secure the ingress: Wrap your Cloud Run endpoints in Identity-Aware Proxy (IAP) to protect human-in-the-loop dashboards, IAP checks the user's Google identity before traffic ever reaches your code. For agent-to-tool traffic, Agent Gateway can give each agent a unique identity with end-to-end mTLS (mutual TLS, where both sides verify each other) when calling MCP servers on Cloud Run.
Centralize trace logging: Enable the platform's built-in OpenTelemetry tracing (Cloud Trace is on by default for CLI-based deployments). You can visually inspect directed acyclic graphs (DAGs) of execution, a step-by-step map of every reasoning step, model call, and tool invocation — to see exactly how your Gemini models and Cloud Run tools collaborated on an inference task. When an agent gives a strange answer, this trace is how you find out why.

Key Takeaways

Split the responsibilities: Cloud Run for your code, the Agent Platform for orchestration and models. Each tier scales and fails independently.
Tools are just functions: the ADK turns well-documented Python functions into capabilities your agent can call.
Permissions before deployment: grant roles/aiplatform.user to your Cloud Run service account, or nothing else will work.
Match inference mode to workload: online for interactive experiences, batch for high-volume processing.
Secure and trace from day one: IAP at the edge, mTLS between services, OpenTelemetry for visibility.

Where to Go Next

Try the smallest possible version: define a one-tool agent with the ADK, run adk deploy cloud_run, and send it a request. Once that works, everything else in this article is an incremental addition.

Have you tried pairing the Agent Platform with Cloud Run, or are you still on a self-managed inference setup? I would love to hear what your architecture looks like in the comments.

Cloud Run Sandboxes: The Safest Way to Run AI-Generated Code in Production

Caleb Duff — Mon, 27 Jul 2026 13:45:29 +0000

Generative AI applications and autonomous agents (AI agents) are revolutionizing how software interacts with code, thereby creating a new challenge. Modern AI agents no longer just generate static text, these agents have evolved, dynamically generating codes, write and execute Python scripts, parse datasets, run web scrapers, and invoke external webhooks in real time. If an untrusted code executes inside your main application container, an attacker or a hallucinating LLM could access environment variables, steal service account tokens from the cloud metadata server, or compromise internal networks; this posses massive security risk.
The question becomes, how do you let a language model execute code without putting your infrastructure at risk?

Google recently answered the question above by addressing one of the hardest challenge in AI engineering, which is a fundamental change in how you can safely build AI agents that execute code and it is deeply integrated into the serverless model you already know. Google Cloud introduced Cloud Run Sandboxes in public preview. Woohoo!

What is Google Cloud Run Service Sandbox?

Cloud Run Sandboxes are lightweight, isolated execution boundaries that you spawn near-instantly within your existing Cloud Run service instances. Cloud Run Sandboxes give you a secure, isolated sandbox to run these tasks without leaving your serverless environment.

The key phrase is within your existing Cloud Run service instances. You do not spin up a separate Cloud Run service to act as a sandbox host. You do not provision a new VM. The sandbox runs inside the same instance that is already executing your agent code, isolated from it by two layers of security boundaries, but co-located with it for speed.

When you enable the feature on a Cloud Run service, a sandbox command-line tool is mounted into your execution environment (container), allowing applications to safely start sandboxes through standard subprocess calls without risking the host system.
Think of it as giving your agent a locked room inside your locked building. The agent can go into that room, execute whatever code it needs to, and come back out, but nothing that happens in the room can touch the building's keys, wiring, or front door.

Key Capabilities:

Millisecond Startup: Spawns fresh execution environments in roughly ~500ms directly inside the active host container.
Shared Resource Pricing: Runs on your instance’s already-allocated CPU and memory, meaning there are no additional cloud VM charges or specialized third-party vendor markups.
Strict Ephemerality: Once execution completes, the sandbox process and its filesystem changes are discarded.

Why Use It? (The Security & Operational Benefits)

Historically, sandboxing dynamic code required complex infrastructure setups. Cloud Run Sandboxes are engineered to protect your host application and cloud resources from malicious or erroneous code execution, by establishing three strict Zero-trust security boundaries out of the box:

1. Credential, identity protection and environment isolation: By default, sandboxes do not have access to the parent workload, cannot read host environment variables, secrets, or the Google Cloud metadata server, thereby preventing unauthorized access to project service account tokens. All sandboxes are completely isolated from each other.
This is the boundary that matters most for AI agent workloads. A prompt injection attack that convinces your agent to run malicious code gains nothing, the sandbox has no access to your service account, your Secret Manager values, or the metadata server that would give it a token to act on your behalf.

2. Network Egress Blocked by Default: By default, sandboxes have zero outbound network access from inside the sandbox. If your agent is tricked into running a script that attempts to exfiltrate data to a malicious server, the network request is blocked at the system layer.
Egress is only possible when you explicitly enable it per execution:

# Egress disabled (default) — any outbound network call is blocked
sandbox do -- python3 /tmp/generated_script.py

# Egress enabled — for sandboxes that need to call external APIs
sandbox do --allow-egress -- curl https://api.github.com

This is a meaningful security default. Most code interpretation tasks, data analysis, calculation, text processing, chart generation; require no outbound connectivity. Locking it down by default means a compromised prompt cannot phone home, even if it tries.

3. Safe filesystem overlay (Zero-Trust Process Isolation): Code inside the sandbox operates with limited system permissions and is strictly isolated from neighboring sandboxes and the host process. The sandbox runs with a read-only view of your container's filesystem (allowing it to use your installed packages, Python runtimes, and binaries) but writes all changes to an isolated, temporary memory overlay. Once the sandbox execution ends, all generated files are discarded.

This means your agent's dependencies, runtimes, and tools are available inside the sandbox, it can run python3, use numpy, call playwright; but any files written during execution disappear when the sandbox closes. If you need to persist output across sandboxes, you do so explicitly:

# Write sandbox output to a tar archive that persists outside the sandbox
sandbox do --write --export-tar=/tmp/work.tar \
  -- /bin/bash -c "mkdir -p /tmp/work && echo 'task-complete' > /tmp/work/status.txt"

# Import the archive into a new sandbox
sandbox do --write --import-tar=/tmp/work.tar \
  -- /bin/bash -c "cat /tmp/work/status.txt"

How to Use Cloud Run Sandboxes: Step by step

Step 1: Enabling the feature (sandbox launcher) at deploy time

To use Cloud Run Sandboxes, you need to deploy a Cloud Run service with the feature enabled. Enabling sandboxes on your Cloud Run service is as simple as adding a single flag to your deployment.

gcloud beta run deploy my-app-agentic-service \
  --image=gcr.io/my-project/agent-image \
  --region=africa-south1 \
  --sandbox-launcher \
  --min-instances=1 \
  --concurrency=10

Or via a YAML configuration:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: my-app-agentic-service
spec:
  template:
    metadata:
      annotations:
        run.googleapis.com/sandbox-launcher: "true"
    spec:
      containers:
      - image: gcr.io/my-project/agent-image
        resources:
          limits:
            cpu: "2"
            memory: 2Gi

Step 2: Spawn sandboxes from your agent code

Once the sandbox launcher is enabled, the sandbox binary automatically becomes available inside your container. Your agents code calls it via standard subprocess execution.
Key subcommands include:

Command	Description
sandbox do	Creates a temporary sandbox, executes a command, and destroys it
sandbox run	Starts a sandbox
sandbox exec	Executes a command in a running sandbox
sandbox tar	Takes a snapshot of the sandbox's filesystem
sandbox delete	Deletes a sandbox

Sample: Executing a Python code or Nodejs code or Go code

Here's a practical example showing how an AI agent uses the sandbox to execute generated code

import subprocess

def run_llm_generated_code(llm_code: str) -> str:
    """
    Safely execute code generated by an LLM inside an isolated sandbox.
    The sandbox has no access to env vars, secrets, or network by default.
    """
    # Write the generated code to a temp file in the host container
    with open("/tmp/generated_script.py", "w") as f:
        f.write(llm_code)

    result = subprocess.run(
        ["sandbox", "do", "--", "python3", "/tmp/generated_script.py"],
        capture_output=True,
        text=True,
        timeout=30   # hard timeout, the sandbox is killed after this
    )

    if result.returncode == 0:
        return result.stdout
    else:
        return f"Execution failed:\n{result.stderr}"

// Node.js agent example
const { execSync } = require('child_process');
const fs = require('fs');

function runUntrustedCode(llmCode) {
  fs.writeFileSync('/tmp/generated_script.py', llmCode);

  try {
    const output = execSync(
      'sandbox do -- python3 /tmp/generated_script.py',
      { timeout: 30000, encoding: 'utf8' }
    );
    return { success: true, output };
  } catch (err) {
    return { success: false, error: err.stderr };
  }
}

// Go agent example
package main

import (
    "bytes"
    "os"
    "os/exec"
)

func runInSandbox(code string) (string, error) {
    // Write code to temp file
    if err := os.WriteFile("/tmp/script.py", []byte(code), 0644); err != nil {
        return "", err
    }

    cmd := exec.Command("sandbox", "do", "--", "/usr/bin/python3", "/tmp/script.py")
    var out, errBuf bytes.Buffer
    cmd.Stdout = &out
    cmd.Stderr = &errBuf

    if err := cmd.Run(); err != nil {
        return "", fmt.Errorf("sandbox error: %s", errBuf.String())
    }
    return out.String(), nil
}

The sandbox do command creates a temporary sandbox, runs the Python code, and returns the output. Because sandboxes don't inherit host environment variables, you must use absolute paths for commands

Step 3: Use the ADK integration (for Gemini-based agents)

Cloud Run Sandboxes are supported in the Agent Development Kit (ADK) with a new CloudRunSandboxCodeExecutor. This integration gives ADK agents running on Cloud Run the ability to execute code in a single line.

from google.adk.agents import Agent
from google.adk.integrations.cloud_run import CloudRunSandboxCodeExecutor

analyst_agent = Agent(
    name="data_analyst",
    model="gemini-3.1-pro-preview",
    system_instruction=(
        "You are an expert data analyst. Write and execute Python code "
        "to answer user questions and process data safely."
    ),
    code_executor=CloudRunSandboxCodeExecutor(),
)

This is the cleanest integration path if you are already building on ADK. The executor handles the sandbox do invocation, output capture, error handling, and result formatting automatically, your agent just writes code and gets results.

Step 4: Use ComputeSDK for vendor-agnostic integration

Cloud Run Sandboxes are also available via ComputeSDK, a vendor-agnostic SDK for running sandboxes. This SDK allows you to either invoke sandboxes remotely from outside the Cloud Run service or use them directly as a local tool on the service.

# Using ComputeSDK with Cloud Run Sandboxes
npm install @computesdk/cloud-run

CLOUD_RUN_SANDBOX_URL=https://your-gateway-xyz.run.app
CLOUD_RUN_SANDBOX_SECRET=your_shared_secret
# Optional: Google-signed identity token for IAM-authenticated services
CLOUD_RUN_AUTH_TOKEN=your_identity_token

# Use the Cloud Run provider
import { cloudRun } from '@computesdk/cloud-run';

const compute = cloudRun({
  sandboxUrl: process.env.CLOUD_RUN_SANDBOX_URL,
  sandboxSecret: process.env.CLOUD_RUN_SANDBOX_SECRET,
});

// Create sandbox
const sandbox = await compute.sandbox.create();

// Run a command
const result = await sandbox.runCommand('echo "Hello from Cloud Run!"');
console.log(result.stdout); // "Hello from Cloud Run!"

// Clean up
await sandbox.destroy();

ComputeSDK is the right choice when you want your agent code to be portable across sandbox providers — you can swap between Cloud Run Sandboxes, E2B, Modal, and others by changing the provider parameter. Read more about ComputeSDK and CloudRun integration.

Core use cases

- LLM code interpreters and data analysis

This is the flagship use case. You can build advanced data analysis features into your AI products, let your models write and execute Python, R, or SQL code to analyse datasets, generate charts, and perform complex maths securely.

A financial reporting agent that writes and executes pandas code to process a user's uploaded CSV. A scientific assistant that writes numpy code to run statistical analysis. A business intelligence tool where users ask natural language questions and the agent writes the SQL or Python to answer them. All of these involve LLM-generated code that could theoretically be malicious, and Cloud Run Sandboxes isolate every execution.

- Headless browser automation

You can give your agents a secure environment to run browsers, safely scraping web pages, taking screenshots, and automating web workflows without risking your host machine.

# Launch a headless Playwright browser inside a sandbox
def web_research(url: str) -> str:
    script = f"""
from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch()
    page = browser.new_page()
    page.goto('{url}')
    content = page.content()
    browser.close()
    print(content[:5000])  # Return first 5000 chars
"""
    with open("/tmp/browse.py", "w") as f:
        f.write(script)

    result = subprocess.run(
        ["sandbox", "do", "--allow-egress", "--", "python3", "/tmp/browse.py"],
        capture_output=True, text=True, timeout=30
    )
    return result.stdout

Note that browser automation requires --allow-egress since it needs to reach the target URL. This is a deliberate choice, you are explicitly granting network access for this specific execution only.

- User-submitted code and plugins

Beyond AI, platforms hosted on Cloud Run can use sandboxes to safely run custom scripts, plugins, or webhooks uploaded by their own end-users.

SaaS platforms that allow user-defined automation scripts, webhook processors, custom plugin systems, or configurable data transformations, any of these involve running code you did not write, from users you may not fully trust. Cloud Run Sandboxes provide the isolation layer without requiring you to build and operate your own sandbox infrastructure.

- Sub-agent execution

AI systems that spawn sub-agents to complete tasks in parallel, each sub-agent running a different piece of generated code, benefit directly from Cloud Run Sandboxes' per-sandbox isolation. Each sub-agent's code runs in a completely separate sandbox with no access to sibling sandboxes' state, data, or credentials.

Why use Cloud Run Sandboxes specifically?

Speed that matters for agent responsiveness

Sandboxes are interactive and ready to execute commands almost instantly. By creating sandboxes within an existing Cloud Run resource where your agent runs, you reduce creation times when compared to creating a new Cloud Run resource for every task. This efficiency helps ensure that your agent remains responsive.

In testing, 1,000 sandboxes were started, executed, and stopped with an average of 500ms latency. At this speed, sandbox creation is not a bottleneck in your agent's response time, it is a negligible overhead compared to the LLM inference calls your agent is already making.

- No additional cost

Unlike dedicated sandbox hosting platforms that charge high premiums for on-demand virtual machines, Cloud Run Sandboxes run directly on your existing allocated CPU and memory. Because the sandboxes share the resources of your running instances, there is no additional cost or premium to use this feature.

This is the economics argument that is easy to underestimate. Specialised sandbox services charge per execution, per second of CPU time, or per GB of memory, and those costs compound quickly for agent workloads that execute code frequently. Cloud Run Sandboxes add no line item to your bill.

- Native GCP integration

Cloud Run Sandboxes work directly with the rest of your GCP stack. Your agent service already has its IAM service account, its Secret Manager access, its VPC configuration. The sandbox runs within that same resource, benefiting from all your existing security controls while being isolated from your agent's own context.

Where to use Cloud Run Sandboxes

Cloud Run Sandboxes are the right choice in the following scenarios:

AI agents that execute code. Any agent built with ADK, LangChain, LlamaIndex, or custom orchestration that uses code execution as a tool. The security boundaries are purpose-built for this use case.

Multi-tenant SaaS platforms. If your platform runs code on behalf of multiple customers, sandboxes ensure one tenant's execution cannot interfere with, read from, or affect another tenant's data.

Data analysis and scientific computing tools. Products that let users write or generate code to analyse their data, whether that code is human-authored or LLM-generated; benefit from sandbox isolation to protect the underlying platform.

Webhook and plugin processors. Systems that receive and execute code from external sources (third-party webhooks, user-uploaded plugins, custom integrations) need execution isolation that does not require a separate microservice per plugin.

Development and testing environments. CI/CD pipelines that need to execute user-submitted code samples as part of automated testing can use sandboxes to isolate each test execution.

Alternative options

Cloud Run Sandboxes are not the only way to run untrusted code. Understanding the alternatives clarifies where sandboxes sit in the market.

E2B (e2b.dev)

E2B provides an API-based sandbox service specifically designed for AI agents and code execution. It supports multiple runtimes, long-lived sandboxes, and a rich SDK with filesystem and terminal APIs. It is vendor-agnostic and integrates with any cloud. The trade-off: it is a third-party service with per-execution pricing, external API calls from your agent, and a dependency outside your GCP environment. For teams deeply invested in GCP, Cloud Run Sandboxes eliminate the external dependency entirely.

Modal

Modal provides on-demand serverless functions for Python workloads with strong isolation and fast cold starts. It is excellent for Python-heavy workloads and data science tasks. Like E2B, it is vendor-specific and adds an external billing relationship. Modal's container-level isolation is strong but does not provide the same per-execution zero-trust credential isolation that Cloud Run Sandboxes enforce by default.

Firecracker microVMs (self-managed)

Firecracker is the open-source microVM technology used by AWS Lambda and Fly.io. You can run your own Firecracker-based sandbox fleet on GCE. It provides genuine VM-level isolation and full control over the runtime environment. The cost is a significant operational overhead, because building, operating, scaling, and patching a Firecracker cluster is a meaningful engineering investment. Cloud Run Sandboxes give you comparable isolation without the operational surface.

Cloud Run Jobs (async execution)

For asynchronous execution, you can avoid disrupting the main application flow by executing tasks asynchronously using a Cloud Run Job for longer-running or background tasks. For example, execute a Cloud Run job that uploads code to Cloud Storage, installs the required dependencies, and then processes and stores the results back in Cloud Storage.

This pattern predates Cloud Run Sandboxes and still has its place for long-running tasks (batch analysis, video processing, model fine-tuning) where you need full job-level isolation and are not latency-sensitive. For interactive, sub-second code execution inside an agent request, sandboxes are faster and simpler.

Nsjail / gVisor (DIY)

Security-focused teams sometimes build custom sandboxes using gVisor (Google's container sandbox kernel, also used by Cloud Run itself) or nsjail (a Linux namespacing tool). These are powerful but require deep Linux security expertise to configure correctly; seccomp profiles, namespace configuration, capability dropping and are effectively engineering projects in their own right. Cloud Run Sandboxes encapsulate this complexity behind a single CLI command.

Current limitations to know

Cloud Run Sandboxes are in public preview as of July 2026. This means they are subject to the pre-GA terms, available as-is, with potentially limited support, and subject to change before GA (General Availability).

Practical limitations to factor into your architecture:

Preview status. Do not build a production-critical system that cannot function without this feature until GA is announced. The API may change.
Resource sharing. Sandboxes share the CPU and memory of your Cloud Run instance. A sandbox running computationally intensive code will consume resources from your service's allocated capacity. Size your instances accordingly when sandbox workloads are CPU or memory intensive.
No persistent state. Everything written inside a sandbox is discarded unless explicitly exported via --export-tar. Design your agent to treat sandbox execution as stateless.
Timeout enforcement. Your subprocess call's timeout parameter is what kills a runaway sandbox, there is no automatic execution time limit enforced by the platform independent of your code. Always set a timeout.
Language support. The sandbox can run any language installed in your container image. Python, Node.js, Go, Ruby, and bash are all available if they are present in your Dockerfile. There is no built-in multi-language runtime, you provision what you need.

Get started today

# Enable the API if not already enabled
gcloud services enable run.googleapis.com

# Deploy your first sandbox-enabled service
gcloud beta run deploy my-sandbox-agent \
  --image=gcr.io/my-project/agent:latest \
  --region=africa-south1 \
  --sandbox-launcher \
  --allow-unauthenticated \
  --min-instances=1

# Test it with a simple curl
curl -X POST https://YOUR_SERVICE_URL/execute \
  -H "Content-Type: application/json" \
  -d '{"code": "print(1 + 1)"}'

The full documentation, quickstart samples, and the ADK integration guide are at docs.cloud.google.com/run/docs/code-execution.

The broader picture

Cloud Run Sandboxes land at a specific moment in AI engineering history. The question of how to safely let AI systems execute code, whether that means a Gemini model writing a Python script to analyse a spreadsheet, or an autonomous agent spinning up a browser to complete a research task; is one of the hardest practical problems in building production AI applications.

Until recently, the industry's answer was, build your own sandboxing infrastructure, pay for a specialised third-party service, or accept the risk. None of these are satisfying answers for teams that want to ship fast and operate responsibly.

Cloud Run Sandboxes offer a fourth answer, use the cloud infrastructure you already trust, with security boundaries designed for exactly this use case, at no additional cost. The 500ms sandbox startup time means this is practical for interactive agent workloads. The zero-trust-by-default credential isolation means the security model does not depend on your generated code being well-behaved.

For teams building AI agents on GCP and the number of such teams is growing rapidly, this removes one of the last credible reasons to use an external sandbox service.

Zero to Multi-Region: High Availability Serverless with Cloud Run and Cross-Region Failover & Failback

Caleb Duff — Fri, 24 Jul 2026 00:52:30 +0000

Google just made multi-region Cloud Run significantly easier. Here is the full picture; what changed, what it means in practice, and how to build it right.

Most teams discover they need multi-region architecture the hard way and sadly, during an outage. Whether you're running a global e-commerce platform, a real-time gaming API, or a financial services application, users expect your service to be available whenever they need it. There is a conversation that happens in almost every engineering team at some point. It usually starts with a post-mortem. A regional Google Cloud outage or a Cloud Run service that hit a cold start spike, or a single-region deployment that could not handle the latency demands of users spread across Lagos, Nairobi, and London simultaneously, caused enough pain that someone finally asked: why are we only deployed in one region?

The answer is usually one of three things: it felt complex, it felt expensive, or no one had prioritised it yet.

In July 2026, Google moved Cloud Run Service Health to General Availability and the timing was hard to miss. Six days earlier, a power cut at Google's Netherlands data centre had knocked three services offline. The GA release brings automatic cross-region failover to Cloud Run with what Google describes as a two-step setup: add a readiness probe, set minimum instances to at least 1. The load balancer does the rest.

This article covers the full architecture, what Service Health is, how readiness probes underpin it, how to set up the Global Load Balancer correctly, and how to test that failover actually works. It also covers the production details.

What changed: Service Health and readiness probes

Before Service Health, multi-region Cloud Run required you to implement a /health endpoint in your application and configure a separate HTTPS health check at the load balancer level. This worked, but it had a significant gap. The load balancer's health check only knew whether the Cloud Run service endpoint was responding, not whether the individual container instances behind it were actually ready to serve traffic.

Service Health introduces two new capabilities that close this gap:

Readiness probes operate at the container instance level. Cloud Run periodically sends an HTTP request to a path you specify on each running container instance. If the probe fails, Cloud Run stops routing requests to that instance until the probe succeeds again. Critically, a failing readiness probe does not kill the instance (that is what a liveness probe does), it simply marks the instance as not ready for traffic.

Service Health aggregates the readiness state of all container instances in a region into a single regional health signal. This aggregated health status is exposed through the Serverless NEGs (Network Endpoint Groups) for that region. When the Global Load Balancer reads the NEG's health status and sees a region is unhealthy, because enough instances are failing their readiness probes; it automatically reroutes traffic to a healthy region. When the failing region recovers, traffic is gradually restored without any operator action.

The result: failover and failback capabilities are now fully automated, triggered by real instance-level health rather than a synthetic endpoint check.

Container instance (readiness probe fails)
        │
        ▼
Cloud Run aggregates probe results across all instances in the region to determine the overall health status of each regional service
        │
        ▼
Service Health: region marked UNHEALTHY
        │
        ▼
Serverless NEG reports unhealthy status to Global Load Balancer
        │
        ▼
Load Balancer stops routing to this region → shifts traffic to healthy region
        │
        ▼
Region recovers → Load Balancer gradually restores traffic

This is available in all Cloud Run regions at no extra charge beyond the CPU and memory consumed while readiness probes run.

Architecture overview

                    ┌──────────────────────────────────┐
                    │   Global Anycast IP (single IP)  │
                    │   + SSL Certificate (managed)    │
                    └───────────────┬──────────────────┘
                                    │
                    ┌───────────────▼──────────────────┐
                    │  Global External HTTP(S) LB      │
                    │  (URL map + forwarding rules)    │
                    └──────┬──────────────────┬────────┘
                           │                  │
        ┌──────────────────▼──┐         ┌─────▼──────────────────┐
        │  Serverless NEG     │         │  Serverless NEG        │
        │  africa-south1      │         │  us-central1           │
        │  (Service Health    │         │  (Service Health       │
        │   status: healthy)  │         │   status: healthy)     │
        └──────────┬──────────┘         └───────────┬────────────┘
                   │                                │
   ┌───────────────▼───────────┐     ┌──────────────▼──────────────┐
   │  Cloud Run Service        │     │  Cloud Run Service          │
   │  africa-south1            │     │  us-central1                │
   │  Readiness probe: /health │     │  Readiness probe: /health   │
   │  min-instances: 1+        │     │  min-instances: 1+          │
   │  (auto-scales 0–N)        │     │  (auto-scales 0–N)          │
   └───────────────────────────┘     └─────────────────────────────┘

Prerequisites and setup

export PROJECT_ID="your-project-id"
export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID \
  --format="value(projectNumber)")
export SERVICE="my-api"
export REGION_A="africa-south1"
export REGION_B="us-central1"
export DOMAIN="api.yourdomain.com"
export IMAGE="gcr.io/${PROJECT_ID}/${SERVICE}:latest"

gcloud config set project $PROJECT_ID

# Enable required APIs
gcloud services enable \
  run.googleapis.com \
  compute.googleapis.com \
  artifactregistry.googleapis.com \
  cloudbuild.googleapis.com \
  networkservices.googleapis.com

# Grant Cloud Build service account the Cloud Run builder role
gcloud projects add-iam-policy-binding $PROJECT_ID \
  --member="serviceAccount:${PROJECT_NUMBER}-   compute@developer.gserviceaccount.com" \
  --role="roles/run.builder"

Step 1: Implement the readiness probe endpoint

The first step and the most important one for Service Health to work, is adding a readiness probe endpoint to your application. Unlike the previous/alternative approach where the /health endpoint was for the load balancer's benefit, this endpoint is called directly by Cloud Run on each container instance to determine per-instance readiness.

Two rules from the official docs that matter here:

Use an HTTP/1 endpoint (the Cloud Run default, not HTTP/2)
The endpoint path must match the path in your probe configuration exactly

// Node.js / Express
// Lightweight — no DB calls, no downstream dependencies
// This runs frequently on every instance
app.get('/health', (req, res) => {
  res.status(200).json({
    status: 'healthy',
    region: process.env.REGION,
    timestamp: new Date().toISOString()
  });
});

// If you want the probe to reflect actual readiness
// (e.g. connection pool initialised), you can check internal state:
let isReady = false;
app.get('/health', (req, res) => {
  if (!isReady) {
    return res.status(503).json({ status: 'not_ready' });
  }
  res.status(200).json({ status: 'healthy', region: process.env.REGION });
});

// Set isReady = true after your startup tasks complete
pool.connect().then(() => { isReady = true; });

# Python / FastAPI
import os
from datetime import datetime
from fastapi import FastAPI, Response

app = FastAPI()
is_ready = False

@app.get("/health")
async def readiness_probe(response: Response):
    if not is_ready:
        response.status_code = 503
        return {"status": "not_ready"}
    return {
        "status": "healthy",
        "region": os.environ.get("REGION"),
        "timestamp": datetime.utcnow().isoformat()
    }

@app.on_event("startup")
async def startup_event():
    global is_ready
    # Initialise connections, warm caches, etc.
    await init_database_pool()
    is_ready = True

The is_ready pattern is the key upgrade over a basic /health endpoint. The readiness probe on each instance will return 503 until your startup tasks complete, preventing the load balancer from routing traffic to an instance that is running but not yet ready.

Step 2: Deploy to multiple regions with readiness probes

The gcloud run deploy supports deploying to multiple regions in a single command, and the --readiness-probe flag attaches the probe configuration at deploy time. Failovers require at least two (2) services from different regions.

# Deploy to both regions simultaneously with readiness probe
gcloud run deploy $SERVICE \
  --image=$IMAGE \
  --regions=$REGION_A,$REGION_B \
  --min=1 \
  --max-instances=100 \
  --concurrency=80 \
  --cpu=1 \
  --memory=512Mi \
  --timeout=30s \
  --readiness-probe="httpGet.path=/health" \
  --set-env-vars="ENV=production" \
  --allow-unauthenticated

The --readiness-probe="httpGet.path=/health" flag is the new way to configure probes at deploy time. You can also configure additional probe parameters:

# Full readiness probe configuration
gcloud run deploy $SERVICE \
  --image=$IMAGE \
  --regions=$REGION_A,$REGION_B \
  --min=2 \
  --readiness-probe="httpGet.path=/health,periodSeconds=10,failureThreshold=3,successThreshold=1,timeoutSeconds=5"

Or via YAML service definition (the Terraform-friendly approach):

# service.yaml
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: my-api
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/minScale: "1"
        autoscaling.knative.dev/maxScale: "100"
    spec:
      containers:
      - image: gcr.io/PROJECT_ID/my-api:latest
        resources:
          limits:
            cpu: "1"
            memory: 512Mi
        env:
        - name: ENV
          value: production
        readinessProbe:
          httpGet:
            path: /health
          periodSeconds: 10
          failureThreshold: 3
          successThreshold: 1
          timeoutSeconds: 5
        livenessProbe:
          httpGet:
            path: /health
          periodSeconds: 30
          failureThreshold: 3

The difference between readiness and liveness probes

Both probe types are supported on Cloud Run. Understanding the distinction is critical:

Readiness probe failure: Cloud Run stops routing requests to that instance. The instance continues running. Once the probe succeeds again, routing resumes. Service Health aggregates these to determine regional health.

Liveness probe failure: Cloud Run restarts the container instance. Use liveness probes for detecting deadlocks or unrecoverable stuck states.

For Service Health's automatic failover, readiness probes are what matter. Liveness probes are a complement, they handle instance-level recovery, while readiness probes handle traffic routing decisions.

Step 3: Set up the global external Application Load Balancer

With the new Service Health model, the load balancer configuration is simpler than before, you no longer need to configure a separate HTTPS health check at the load balancer level. Service Health exposes regional health through the Serverless NEG itself.

Create the backend service

# Single backend service, both regions are added as NEG backends
gcloud compute backend-services create $SERVICE-bs \
  --load-balancing-scheme=EXTERNAL_MANAGED \
  --global

Note: unlike the earlier approach with separate backend services per region, Service Health works with a single backend service that has multiple regional NEG backends. The load balancer reads health from each NEG and routes accordingly.

Reserve a global static IP (Set up a global static external IP address to reach your load balancer:)

gcloud compute addresses create $SERVICE-ip \
  --network-tier=PREMIUM \
  --ip-version=IPV4 \
  --global

export GLOBAL_IP=$(gcloud compute addresses describe $SERVICE-ip \
  --global --format="get(address)")

echo "Global IP: ${GLOBAL_IP}"
# → Update your DNS A record to this IP before proceeding

Create URL map, proxy, and forwarding rules

# Create a URL map to route incoming requests to the backend service:
gcloud compute url-maps create $SERVICE-lb \
  --default-service=$SERVICE-bs

# For HTTPS (recommended for production):
# Create Google-managed SSL certificate
gcloud compute ssl-certificates create $SERVICE-ssl \
  --domains=$DOMAIN \
  --global

# Create the target HTTPS proxy to route requests to your URL map:
gcloud compute target-https-proxies create $SERVICE-https-proxy \
  --url-map=$SERVICE-lb \
  --ssl-certificates=$SERVICE-ssl

# Create the HTTPS forwarding rule  to route incoming requests to the proxy:
gcloud compute forwarding-rules create $SERVICE-https-fr \
  --load-balancing-scheme=EXTERNAL_MANAGED \
  --network-tier=PREMIUM \
  --address=$SERVICE-ip \
  --target-https-proxy=$SERVICE-https-proxy \
  --global \
  --ports=443

# HTTP forwarding rule (redirect to HTTPS)
gcloud compute target-http-proxies create $SERVICE-http-proxy \
  --url-map=$SERVICE-lb

gcloud compute forwarding-rules create $SERVICE-http-fr \
  --load-balancing-scheme=EXTERNAL_MANAGED \
  --network-tier=PREMIUM \
  --address=$SERVICE-ip \
  --target-http-proxy=$SERVICE-http-proxy \
  --global \
  --ports=80

Step 4: Create Serverless NEGs and attach them

# Serverless NEG for africa-south1
gcloud compute network-endpoint-groups create $SERVICE-neg-$REGION_A \
  --region=$REGION_A \
  --network-endpoint-type=serverless \
  --cloud-run-service=$SERVICE

# Serverless NEG for us-central1
gcloud compute network-endpoint-groups create $SERVICE-neg-$REGION_B \
  --region=$REGION_B \
  --network-endpoint-type=serverless \
  --cloud-run-service=$SERVICE

# Add both NEGs to the single backend service
gcloud compute backend-services add-backend $SERVICE-bs \
  --global \
  --network-endpoint-group=$SERVICE-neg-$REGION_A \
  --network-endpoint-group-region=$REGION_A

gcloud compute backend-services add-backend $SERVICE-bs \
  --global \
  --network-endpoint-group=$SERVICE-neg-$REGION_B \
  --network-endpoint-group-region=$REGION_B

At this point, Service Health is active. Cloud Run is running readiness probes on every instance in both regions, aggregating the results into a regional health signal, and the load balancer reads that signal via the Serverless NEGs.

Step 5: Monitor Service Health with Cloud Monitoring

Service Health exposes two metrics through Cloud Monitoring that you should track from day one:

run.googleapis.com/container/instance_count_with_readiness, the number of instances passing their readiness probe per region. Watch this metric to see the health state of your instance pool in each region in real time.

run.googleapis.com/service_health_count, the regional Cloud Run service health as reported to the load balancer. Possible values: HEALTHY, UNHEALTHY, UNKNOWN. The load balancer uses this to make failover decisions. UNKNOWN is reported until the service has enough data from probes to determine health, typically within the first few minutes of deployment.

# View current service health status via gcloud
gcloud run services describe $SERVICE \
  --region=$REGION_A \
  --format="value(status.conditions)"

# Or check via the Console:
# Cloud Run → your service → Metrics tab → "Instance count with readiness"

Set up an alerting policy that fires when service_health_count for any region transitions to UNHEALTHY:

# alert-policy.yaml
displayName: "Cloud Run region unhealthy — failover active"
conditions:
- displayName: "Service health UNHEALTHY"
  conditionThreshold:
    filter: |
      resource.type="cloud_run_revision"
      metric.type="run.googleapis.com/service_health_count"
      metric.labels.health_status="UNHEALTHY"
    comparison: COMPARISON_GT
    thresholdValue: 0
    duration: 60s
    aggregations:
    - alignmentPeriod: 60s
      perSeriesAligner: ALIGN_MAX
notificationChannels:
- projects/${PROJECT_ID}/notificationChannels/YOUR_CHANNEL_ID
documentation:
  content: |
    A Cloud Run region has become unhealthy and traffic is being
    rerouted to the remaining healthy region(s). Investigate the
    failing region's logs and instance readiness metrics immediately.

Step 6: Testing failover

Testing is not optional, it is the only way to know your failover actually works before your users discover it during a real incident.

Method 1: Use the sample application's toggle (for the official sample)

The Google Cloud sample application (golang-samples/run/service-health) includes a built-in toggle button in its UI that marks a region as unhealthy. For production applications, use Method 2.

Method 2: Force readiness probe failure via environment variable

# Redeploy africa-south1 with a flag that makes /health return 503
gcloud run deploy $SERVICE \
  --image=$IMAGE \
  --region=$REGION_A \
  --set-env-vars="FORCE_UNHEALTHY=true,ENV=production"

In your application, check this variable:

app.get('/health', (req, res) => {
  if (process.env.FORCE_UNHEALTHY === 'true') {
    return res.status(503).json({ status: 'forced_unhealthy' });
  }
  res.status(200).json({ status: 'healthy', region: process.env.REGION });
});

Observe the failover sequence

# Get load balancer IP
export LBIP=$(gcloud compute addresses describe $SERVICE-ip \
  --global --format='value(address)')

# Continuous requests — watch region shift in responses
while true; do
  RESPONSE=$(curl -s https://${DOMAIN}/health)
  echo "$(date '+%H:%M:%S') — $RESPONSE"
  sleep 2
done

You should observe:

Requests showing "region": "africa-south1" — normal operation
A mix of responses as the probe failure propagates across instances
All requests showing "region": "us-central1" — failover complete
The service_health_count metric for africa-south1 showing UNHEALTHY

Restore the region:

gcloud run deploy $SERVICE \
  --image=$IMAGE \
  --region=$REGION_A \
  --set-env-vars="ENV=production"

Traffic gradually returns to africa-south1 as instances pass their readiness probes and Service Health transitions back to HEALTHY.

Safe rollout strategy using readiness probes

One of the most powerful features of the new readiness probe model is the ability to do canary deployments across regions with automatic rollback via Service Health.

The official recommended rollout process:

# Step 1: Deploy new revision to ONE region with 1% traffic
gcloud run deploy $SERVICE \
  --image=$IMAGE_NEW \
  --region=$REGION_A \
  --readiness-probe="httpGet.path=/health" \
  --min=1 \
  --no-traffic  # Deploy but send no traffic yet

# Step 2: Send 1% of traffic to new revision in REGION_A only
gcloud run services update-traffic $SERVICE \
  --region=$REGION_A \
  --to-revisions=LATEST=1

# Step 3: Monitor readiness metric
# run.googleapis.com/container/instance_count_with_readiness
# If this stays healthy, continue increasing traffic

# Step 4: Ramp to 100% in REGION_A
gcloud run services update-traffic $SERVICE \
  --region=$REGION_A \
  --to-revisions=LATEST=100

# Step 5: Once REGION_A service_health_count is stable HEALTHY,
# deploy to REGION_B
gcloud run deploy $SERVICE \
  --image=$IMAGE_NEW \
  --region=$REGION_B \
  --readiness-probe="httpGet.path=/health" \
  --min=1

If the new revision's readiness probes fail in REGION_A, Service Health marks that region unhealthy, the load balancer routes traffic to REGION_B (still running the old revision), and you have automatic rollback without a single manual step.

Known limitations of Service Health (GA)

The official documentation lists several limitations worth knowing before you build:

Minimum instances required. You must configure at least one minimum instance per region for Service Health to calculate health. A region with zero running instances cannot report health, which means a cold-start region cannot participate in automatic failover.
Minimum two regions. Failover requires at least two services from different regions. If you only deploy to one region and it fails, the load balancer returns no healthy upstream.
Max 5 NEG backends for cross-region internal LB. The limitation applies to the internal load balancer variant, not the global external LB.
No URL masks or tags in Serverless NEGs. If your routing requires URL masks, you cannot use Service Health's NEG model.
No IAP from the backend service. If you need Identity-Aware Proxy, configure it directly on the Cloud Run service, not at the load balancer backend.
First probe on new instances. A newly started instance will not have its first readiness probe counted before it begins receiving traffic. This means a very brief window where traffic may route to an instance before it has confirmed readiness.
Revisions without probes are treated as unknown. The load balancer treats unknown health as healthy, so if you deploy a revision without a readiness probe configured, it will receive traffic regardless.

The last two points are important for zero-downtime deployments. The recommended safe rollout process (canary in one region before the other) directly addresses both.

What this architecture does not solve

Database availability. Compute-layer failover is irrelevant if your Cloud Run service connects to a single-region Cloud SQL instance. The database tier needs its own HA: Cloud SQL cross-region read replicas, Cloud Spanner for global consistency, or Firestore in Native mode (inherently multi-region).

Stateful sessions. Cloud Run is stateless. Cross-region routing will invalidate in-memory sessions. Use Cloud Memorystore (Redis) or stateless JWT-based sessions.

Data residency. Routing traffic across regions may conflict with NDPR, GDPR, or sector-specific regulations. Know your data residency obligations before deploying multi-region.

Pub/Sub push subscriptions. By default, Pub/Sub delivers messages to push endpoints in the same region where it stores the messages. A multi-region Cloud Run setup behind a global LB does not automatically receive Pub/Sub push traffic from all regions. The official docs provide a workaround, review the Pub/Sub multi-region push documentation before building event-driven architectures on this pattern.

Mastering the T: How to Balance Breadth and Depth in Tech. [T-Shaped Engineer]

Caleb Duff — Tue, 03 Feb 2026 17:13:01 +0000

For decades, the tech industry has argued over a classic dilemma: Is it better to be a Specialist (the master of one) or a Generalist (the jack of all trades)? I remember asking my tech tutor this question some years ago.

On one hand, we have the "I-shaped" developer (depth-full techie). They know everything there is to know about PostgreSQL or low-level C++, but they struggle to deploy their own code or understand the frontend UI. On the other hand, you have the "Dash-shaped" generalist. They can dabble in everything, but they lack the depth to solve complex, scaling problems.
In modern software engineering, neither is quite enough. The silos are breaking down. DevOps, Frontend, Backend, and Product are merging into cross-functional squads.

Let's talk about the ***T-Shaped Engineer*.
This concept isn’t new (at least for me), but in the age of AI and rapid product iteration, it has become the gold standard for employability and career growth. Here is what I know it means, and why you should strive to be one.

The Anatomy of the "T*"*
This concept is a metaphor for your skills profile, composed of two bars:

i. The Vertical Bar (Depth)
This represents your deep expertise. It is the core skill that gets you hired.
Check this out: You are a Senior React Developer. You know the virtual DOM inside out, you understand state management patterns, and you can optimize rendering performance in your sleep.
Why you need it: Without depth, you cannot solve hard problems. You need a foundation where you are the "go-to" person.

ii. The Horizontal Bar (Breadth)
This represents your ability to collaborate across disciplines. It’s not about being an expert in everything; it’s about knowing enough to be dangerous and equally helpful.
Check this out: Even though you are a React pro as I have sighted above, you understand how a REST API is structured. You know the basics of Docker. You understand UX design principles. You have "soft skills" like communication and empathy.
Why you need it: This allows you to speak the same language as the rest of your team. It prevents you from being blocked when a minor issue arises outside your core domain.

Why **T-Shaped Developers Win**
i. They Break Down Silos
An "I-shaped" backend developer writes an API and throws it over the wall to the frontend team. If it breaks, they say, "It works on my machine."

A T-shaped backend developer understands how the frontend consumes data. They might even tweak the JSON structure to make the frontend developer’s life easier. They bridge gaps rather than creating them.

ii. They Are Adaptive

Technology changes fast. If your entire career is built on a single framework that goes obsolete (RIP Flash), you’re in trouble.
Because T-shaped developers have a broad base of general knowledge, they can pivot easier. They have "learned how to learn."

iii. They Make Better Architects
You cannot design a scalable system if you don't understand how the database affects the UI, or how the deployment pipeline affects testing.

T-shaped engineers see the "Big Picture.
How to Build Your Own "T"
Note: Becoming T-shaped doesn't happen overnight. It is a deliberate career strategy. Here is a roadmap I will share with you:

Phase 1: Drill Deep (Build the Vertical)
Early in your career, focus on mastery. Pick a stack (e.g., Python/Django or Java/Spring or Swift) and get really, really good at it. You need to build your confidence and value first. With this you can provide business-value to yourself, your team or employer.

Phase 2: Scan the Periphery (Build the Horizontal)
Once you are comfortable in your core, look at the technologies immediately adjacent to you (very important).
Are you a backend dev? Learn basic CSS and how a browser renders a page.
Or a frontend dev? Learn how to set up a basic CI/CD pipeline or write a SQL query.

An Engineer? Learn the basics of Product Management and Business logic.

Phase 3: Cultivate Empathy
The horizontal bar isn't just code; it's people. Understanding what stresses out your Project Manager or what constraints your Designer is working under makes you a better engineer. Empathy is a technical skill.

The Evolution: From **T to Pi (π)**
Once you master the T-shape, the journey isn't over. Many senior engineers eventually become Pi-shaped (π). This means they have a broad base of knowledge and two deep spikes of expertise (e.g., Expert in Backend Go and Expert in Cloud Infrastructure).

The era of the solitary genius coding in a dark room is ending. Modern software is a team sport that somehow has AI as a need member.
You don't need to know everything. But you do need to be an expert in one thing, and curious about everything else. By becoming a T-shaped engineer, you not only future-proof your career, but you also become the kind of teammate everyone wants to work with.
So, look at your skillset today. You have the depth—now, where can you stretch your width?