DEV Community: Google Developer Group

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.

From Apple Health Data to Clinical Storytelling: Building an AI-Powered Report with Python and Gemini

Romina Elena Mendez Escobar — Mon, 20 Jul 2026 09:55:58 +0000

Introduction

At recent technology conferences, one topic has caught my attention: every year, more health-focused devices, sensors, and applications appear. Smartwatches track heart rate, smart scales measure body data, glucose monitors record blood sugar levels, and apps help users track sleep or nutrition. Today, the amount of information we can collect about our own bodies is enormous.

This article was inspired by an everyday experience with my father, Herminio ❤️. Whenever he has a medical appointment, he opens the Apple Health app and shows the doctor the evolution of his heart rate, physical activity, sleep hours, and other recorded metrics.

While watching this, I kept asking myself the same question: are we really making the most of all this information?

Showing a chart during a medical appointment can be useful, but the data could provide much more value if it were automatically processed, summarized, and transformed into a structured health report.

For this reason in this project, I use Gemini to transform previously calculated metrics into a clear and organized summary. The LLM does not analyze all the raw records or perform the main calculations. The pipeline processes the data, calculates the indicators, and generates the visualizations, while the model acts as a support layer for building the report narrative.

The goal is not to create a medical application or replace professional judgment. Instead, the purpose is to build a prototype that shows how Apple Health exports, deterministic data processing, visualizations, and an LLM can be combined to generate automated reports.

This project was developed using simulated data from three patients, so the complete pipeline can be reproduced without using real clinical information.

✨ Why Gemini?

This project uses an LLM to transform previously processed metrics into a structured narrative that can be reviewed more easily by a healthcare professional.
I chose Gemini for practical reasons:

〰️ I was already familiar with its API, it integrates easily with Python, and Google AI Studio makes it simple to test and adjust prompts.
〰️ It also offers a good balance between speed, performance, and cost for text-generation tasks.
〰️ Its free tier also makes it easier to reproduce this MVP without initial costs.

In this case, I use a general-purpose model because all calculations are completed in Python before the data is sent to Gemini. The model only organizes the results into readable text.
For projects that need to analyze clinical documents or medical images directly, specialized models such as MedGemma could also be evaluated. MedGemma is a family of open Google models adapted for healthcare-related tasks. However, its implementation, evaluation, and validation are outside the scope of this tutorial.

2. HealthKit: The Framework Behind the Data

Although most users only interact with the Apple Health app, HealthKit is the framework behind it. Apple provides HealthKit so developers can securely access health information stored on the device.

HealthKit works as a central repository where the iPhone and Apple Watch store health and fitness data. With the user’s explicit permission, authorized applications can read and write information through a single API. This avoids the need for every app to maintain its own separate database.

HealthKit currently supports hundreds of data types across many areas of health and well-being. The following figure presents a simplified grouping of some of these categories to provide a clearer overview of the available information.

This taxonomy was created specifically for this article based on publicly available HealthKit documentation. It is not an official Apple classification and should be understood as a summarized, author-created interpretation for explanatory purposes.

Thanks to this architecture, HealthKit makes it possible to:

Collect and store health and fitness information.
Analyze and visualize how this data changes over time.
Share information between authorized applications, reducing duplication and enabling new user experiences.

One of the most interesting design decisions in HealthKit is its large catalog of predefined classes and data types for standardized health metrics.

At first, this may seem restrictive for developers. However, it is actually one of the platform’s main strengths because it ensures that all stored information follows a consistent data model. This means that heart rate, blood glucose, or body weight always represent the same type of information and use the same units, regardless of the device or application that created the record.

This standardization simplifies application development, improves interoperability between apps, and helps maintain consistency across the data stored in HealthKit.

2.1 Data Sources

One of HealthKit’s main benefits is its ability to bring data from multiple sources into a single repository.
The most common sources include:

iPhone: records steps, distance traveled, mobility data, and other indicators collected through its sensors.
Apple Watch: provides physiological metrics such as heart rate, electrocardiogram (ECG), blood oxygen saturation (SpO₂), body temperature, sleep data, workouts, and cardiorespiratory fitness (VO₂ Max).
Third-party apps: can add information related to nutrition, mental health, hydration, medication, menstrual cycles, or sports training.
Connected medical devices and wearables: HealthKit supports Bluetooth Low Energy (BLE) health devices and medical data profiles. It can also work with FHIR (Fast Healthcare Interoperability Resources), making it possible to integrate data from devices such as glucose meters and blood pressure monitors, as well as clinical records from authorized healthcare institutions.

3. HL7 / FHIR Compatibility

So far, we have mainly discussed data generated by devices and applications. However, in 2018 Apple expanded the Health app by introducing Health Records, a feature that allows users to import structured clinical information from supported healthcare institutions. That same year, Apple also opened access to these records for authorized applications through the HealthKit API.

Health Records is built on HL7 FHIR, which stands for Fast Healthcare Interoperability Resources. FHIR is a standard developed by HL7 International to represent and exchange health information electronically between hospitals, applications, and Electronic Health Record systems.

FHIR organizes information into modular resources such as Patient, Observation, Condition, Procedure, MedicationRequest, and Immunization. Each resource represents a specific piece of clinical information that can be connected, queried, and exchanged between systems. Although FHIR can also be used to build clinical documents, its architecture does not require the entire patient record to be handled as one large document.

When records are downloaded from a supported institution, HealthKit represents each one as an HKClinicalRecord object, which keeps the original FHIR resource. Authorized applications can request the clinical record types they need and process their content as FHIR JSON. However, these records are read-only, which means applications cannot create new HKClinicalRecord objects or modify existing ones.

Access to any HealthKit information requires user consent, but clinical records have additional requirements because of their sensitivity. An application must enable the Clinical Health Records capability, include the required entitlement, explain why the information is needed, and request permission for each record type it wants to access. The use of this capability is also subject to Apple’s review process.

In HealthKit, clinical records are represented as read-only HKClinicalRecord objects that preserve the original FHIR content. Access requires explicit user authorization and is subject to additional privacy and platform requirements.

This architecture makes it possible to bring together information from different sources while keeping access centered on user consent and privacy.

4. HealthKit: Clinical Use Cases

The availability of large volumes of physiological data, combined with interoperability standards such as FHIR, has created many opportunities for research and clinical applications.

The value of this data does not come only from individual measurements, but from how they are analyzed over time. Tracking changes in heart rate, sleep, mobility, or activity levels can help identify patterns, summarize relevant information, and support patient monitoring in different healthcare scenarios.

The following figure presents some representative use cases, including early anomaly detection, remote patient monitoring, clinical summary generation, and synthetic data generation for research.

5. Technical, Clinical, and Regulatory Considerations

Before running the tutorial or using the code presented in this article, it is important to understand its scope and consider several limitations related to privacy, data quality, and the use of artificial intelligence in healthcare contexts.

5.1 Privacy and Data Protection

Health information is one of the most sensitive categories of personal data. Depending on the country and the context of use, it may be subject to regulations such as HIPAA in the United States or GDPR in the European Union.

Although this article uses only simulated data, any implementation that processes real information should include suitable controls for:

User consent.
Access management.
Data minimization.
Anonymization or pseudonymization.
Encryption.
Secure storage and processing.

5.2 Consumer Data Is Not a Diagnosis

Measurements collected through consumer devices can provide useful information for identifying trends and supporting long-term monitoring.
However, these records do not represent a medical diagnosis on their own and should not replace measurements taken with certified clinical equipment.

5.3 Data Quality and Continuity

The quality of the measurements can be affected by factors such as incorrect device placement, low battery levels, synchronization failures, periods when the device is not used, or differences between sensors and applications.
These situations may produce:

Incomplete records.
Duplicate measurements.
Outliers.
Periods with missing information.
Differences in units or sampling frequency.

For this reason, the data should be validated, cleaned, and normalized before generating any analysis. It is also important to identify periods where the available information is not complete enough to support reliable conclusions.

5.4 Use and Limitations of the LLM

In this project, the large language model does not diagnose conditions or recommend treatments. Its role is to transform previously calculated metrics into a clear and structured summary that can be reviewed more easily by a healthcare professional.

Any generated output should be treated as a draft that requires human review. The model may omit information, misunderstand a result, or produce statements that are not fully supported by the input data.

5.2 Scope of the Code

The repository provided with this article should be understood as an educational and experimental MVP. It is designed to demonstrate the general processing flow using simulated data.

It is not a medical product, a diagnostic tool, or an implementation ready for direct use in a clinical environment.
Before adapting the code to a real use case, additional validation would be required in areas such as:

Security and access control.
Error handling and traceability.
Data quality and provenance.
Reproducibility of the results.
Evaluation of the model’s responses.
Compliance with applicable standards and regulations.
Review and approval by qualified professionals.

The goal of this project is to present one possible architecture and explore its main components, not to provide a production-ready clinical solution.

6. Building the Apple Health Reporting Pipeline

In this tutorial, we will build a Python pipeline that processes an Apple Health XML export and generates a structured PDF report.
The pipeline will:

read and normalize the exported health records;
calculate mobility, cardiovascular, and sleep metrics;
compare the results against configurable reference values;
generate charts;
use Gemini to create a structured narrative;
combine everything into a final PDF report.

The generated report contains four main sections:

🚶 Mobility: daily steps, walking speed, steadiness, gait metrics, and caloric expenditure.
❤️ Cardiovascular: resting heart rate, HRV, oxygen saturation, VO₂ Max, and recovery metrics.
😴 Sleep: average sleep duration and nights above or below the configured references.
🤖 AI-generated summary: a structured narrative with patient profile, mobility, cardiovascular, sleep, and overall assessment sections.

The following diagram shows the complete flow of the project:

The implementation follows a modular architecture in which each class is responsible for one stage of the pipeline:

📥 HealthDataReader reads and processes the Apple Health export.
📊 HealthChartBuilder generates the visualizations.
✨ HealthSummaryGenerator creates the narrative using Gemini.
📄 HealthReportPDF combines the metrics, charts, and generated text into the final report.

In the next sections, we will review each stage separately. To keep the article focused, I will only include the most relevant code fragments and design decisions. The complete implementation, configuration files, prompt template, and simulated data are available in the project repository.

6.1 Prerequisites

To follow the tutorial, you will need:

The project repository cloned locally.
An Apple Health XML export or one of the simulated files included in the repository.
A Gemini API key created from Google AI Studio.
The Python dependencies installed from the project requirements.txt file.

You can clone the repository and install the dependencies with:

RominaElenaMendezEscobar / apple-health-data

Python pipeline that processes Apple Health XML exports, calculates health metrics, generates visualizations, creates a structured narrative with Gemini, and builds a final PDF report using simulated patient data.

From Apple Health Data to Clinical Storytelling: Building an AI-Powered Report with Python and Gemini

Apple Health Reporting Pipeline with Python and Gemini

A modular Python pipeline that processes Apple Health XML exports, calculates health metrics, generates visualizations, creates an AI-assisted narrative with Gemini, and builds a structured PDF report.

This repository is an educational MVP built with simulated data. It is not a medical device, diagnostic tool, or production-ready clinical solution.

Overview

The pipeline:

Reads and normalizes Apple Health XML records.
Calculates mobility, cardiovascular, and sleep metrics.
Compares results with configurable reference values.
Generates charts with Matplotlib.
Creates a structured narrative with Gemini.
Combines metrics, charts, and text into a PDF report.

HealthKit: The Framework Behind the Data

HealthKit is Apple’s framework for storing and sharing health and fitness information collected by the iPhone, Apple Watch, third-party apps, and compatible devices.

It provides standardized data types for metrics such…

View on GitHub

✨Gemini API key
You can create an API key from Google AI Studio.
After creating it, add a .env file at the root of the project:

gemini_api_key=YOUR_CREDENTIAL

6.2 Data source

Apple Health allows users to export their information as a ZIP file containing an XML document.

The export can be generated from the Health app:

Open the Health app on the iPhone.
Tap the profile icon.
Select Export All Health Data.
Confirm the export.
Extract the generated ZIP file.

The tutorial uses the export.xml structure produced by this process. However, to avoid exposing real health information, the repository includes three simulated patient files:

alex_28m.xml: 28-year-old male patient.
carlos_68m.xml: 68-year-old male patient.
maria_61f.xml: 61-year-old female patient. These files are stored in the patients/ folder and allow the complete pipeline to be reproduced without using real clinical data.

6.3 Orchestrating the Pipeline

The complete project is coordinated from the main.py file, which works as the application entry point. Its responsibility is not to process the data directly, but to create the specialized classes and execute each stage of the pipeline in the correct order.

This file also defines the list of patients to be processed. For each patient, it includes the XML file path and the name that will appear in the final report. The files are declared explicitly to make the example easier to follow, although a more general implementation could discover them automatically from a folder.

The complete main.py file is shown below:

from healthChartBuilder import HealthChartBuilder
from healthDataReader import HealthDataReader
from healthReportPDF import HealthReportPDF
from healthSummaryGenerator import HealthSummaryGenerator
import utils
import os

if __name__ == "__main__":
   patients = [
       ("patients/alex_28m.xml",   "Alex Torres"),
       ("patients/maria_61f.xml",  "María González"),
       ("patients/carlos_68m.xml", "Carlos Mendez"),
   ]

   os.makedirs("reports", exist_ok=True)
   os.makedirs("charts",  exist_ok=True)
   os.makedirs("data",    exist_ok=True)

   env = utils.read_env()

   for xml_path, name in patients:
       print(f"\n── {name} ──")
       prefix = name.lower().replace(' ', '_')

       # Step 1: read and compute
       reader = HealthDataReader(xml_path).load()

       # Step 1.1: save the compact LLM-friendly summary for this patient
       reader.save(write_llm_summary=True, file_name=prefix)

       # Step 2: generate charts
       builder = HealthChartBuilder(
           metrics    = reader.metrics,
           output_dir = "charts",
           prefix     = prefix,
       )
       charts = builder.build_all()

       # Step: generate the narrative summary with Gemini
       generator = HealthSummaryGenerator(
           json_path   = f"data/{prefix}_llm_summary.json",
           yml_path    = "config/params_health.yml",
           prompt_path = "prompt/prompt_summary.txt",
           api_key     = env["gemini_api_key"],
       ).load()
       llm_text = generator.generate()

       # Step 3: build PDF
       HealthReportPDF(
           metrics        = reader.metrics,
           charts         = charts,
           patient_name   = name,
           date_of_birth  = reader.date_of_birth,
           biological_sex = reader.biological_sex,
           start_date     = reader.df['start'].min(),
           end_date       = reader.df['start'].max(),
           out_path       = f"reports/{prefix}_report.pdf",
           llm_summary    = llm_text,
       ).build()

6.4 Reading and Processing the Apple Health Export

The HealthDataReader class reads the XML file exported from Apple Health and transforms it into a structure that can be analyzed with Python. During this process, it extracts the available records, normalizes dates and numeric values, limits the analysis to the configured period, and calculates the metrics used by the next stages of the pipeline.

The class receives the XML file path and, optionally, the number of months to include in the analysis:

reader = HealthDataReader( 
xml_path="patients/alex_28m.xml", months=6, 
).load()

The load() method runs two main operations:

📥 _parse_xml() reads the file, extracts the records, and transforms them into a Pandas DataFrame.
📐 _compute_metrics() calculates the daily series and aggregated indicators used in the analysis.

Threshold Configuration

The values used to classify or compare the metrics are not hardcoded inside the class. Instead, they are loaded from config/params_health.yml.

This separation makes it possible to update the reference values without changing the Python implementation:

threshold_steps_low:
  description: Step count threshold for red zone.
  value: 3000
threshold_steps_mid:
  description: Step count threshold for orange zone.
  value: 5000
threshold_steps_goal:
  description: Step count goal line.
  value: 7000
threshold_speed_low:
  description: Walking speed considered critically low.
  value: 3.5
threshold_speed_goal:
  description: Walking speed reference value.
  value: 4.5
threshold_steadiness:
  description: Steadiness warning value.
  value: 0.60
threshold_spo2_low:
  description: SpO2 critical threshold.
  value: 95.0
threshold_spo2:
  description: Minimum SpO2 reference value.
  value: 96.0
threshold_sleep_min:
  description: Sleep duration for red zone.
  value: 5.0
threshold_sleep_mid:
  description: Sleep duration for orange zone.
  value: 6.0
threshold_sleep_goal:
  description: Sleep duration goal.
  value: 7.0
threshold_hrv:
  description: Minimum HRV reference value.
  value: 25.0

These parameters affect several parts of the project. They are used, for example, to calculate how many days fall below a specific step count, identify periods of low walking speed, evaluate sleep duration, and define the reference zones later used in the charts and the final report.

⚠️ Note: The values included in the repository are only for demonstration and are intended to support the example with simulated data. They should not be treated as clinical criteria. Before adapting the code to a real use case, the thresholds should be reviewed and validated by healthcare professionals, considering the population, age group, clinical context, and specific purpose of the solution.

Metric Selection

The _compute_metrics() method defines which data types are processed and which indicators are calculated. In the current implementation, the metrics are mainly organized into three groups:

🚶 Mobility and activity: steps, walking speed, step length, steadiness, asymmetry, active energy, and flights climbed.
❤️ Cardiovascular: resting heart rate, HRV, oxygen saturation, respiratory rate, VO₂ Max, and heart rate recovery.
😴 Sleep: daily duration, average sleep, and the number of nights below or above the configured thresholds. The daily series are calculated using sums or averages, depending on the type of record:

steps = self._daily_sum("StepCount")
speed = self._daily_mean("WalkingSpeed")
hr = self._daily_mean("RestingHeartRate")
hrv = self._daily_mean("HeartRateVariabilitySDNN")
spo2 = self._daily_mean("OxygenSaturation")

⚠️ Note: The thresholds are not the only values that should be reviewed. It is also important to confirm that the statistical methods used by the class are appropriate for each metric. For example, the mean can be affected by outliers. Before using this approach in production, other measures such as the median or percentiles may need to be evaluated.

Preparing the Data for the LLM

In addition to the full set of metrics, the class generates a smaller JSON file through to_llm_summary().
Instead of sending the complete time series, Python creates a compact and deterministic representation that includes:

📊 mean and standard deviation;
↕️ minimum and maximum values;
📈 trend over the analysis period;
📅 best and worst weekly averages;
🔄 weekly variability;
⏱️ longest consecutive period below the configured threshold.

Not every metric includes all of these fields, because some calculations do not apply in the same way to every type of data. This decision has two main benefits:

1. Reducing the amount of data sent to the model. An Apple Health export may contain thousands of records. Sending all observations would increase the prompt size, token usage, and execution cost, while also adding repetitive information that may not improve the final summary.
2. Keeping the calculations in Python. Averages, trends, minimum and maximum values, weekly statistics, and threshold streaks are calculated in advance using deterministic code. The LLM receives fixed and verifiable values and is only responsible for turning them into a natural-language summary.

This separation also makes the project easier to maintain. If the trend calculation changes or a new metric is added, the update can be made in Python without changing the role of the language model.
For example, the model receives a structure like this:

{
  "steps": {
    "mean": 9498.53,
    "std": 1728.37,
    "min": 5667.0,
    "max": 14201.0,
    "trend": "stable",
    "worst_week_mean": 8214.29,
    "best_week_mean": 10672.71,
    "weekly_volatility": 576.09,
    "worst_streak_below_threshold": 0
  }
}

6.5 Generating Clinical Charts

The HealthChartBuilder class receives the metrics calculated by HealthDataReader and generates the charts that are later included in the final report.
To keep the presentation logic separate from the data-processing logic, the class uses two configuration files:

🎯 params_health.yml: defines the reference thresholds used for color zones and horizontal lines in each chart.
🎨 params_styles.yml: stores the color palette applied consistently across all visualizations.

Generated Charts

The build_all() method coordinates the chart-generation process and delegates each visualization to an independent private method:

🚶 Activity and mobility — _chart_steps(), _chart_mobility(), and _chart_calories(): daily steps with threshold-based color zones, walking speed with a reference line, and active versus basal calories.
❤️ Cardiovascular — _chart_hrv() and _chart_spo2(): heart rate variability with a minimum reference value, and oxygen saturation with critical, low, and normal zones.
😴 Sleep — _chart_sleep(): nightly sleep duration displayed with threshold-based color zones. If no sleep data is available, the chart shows an alternative message. Each chart is implemented independently, so it can be modified or replaced without affecting the rest of the pipeline.

6.6 Generating the Narrative with Gemini

The HealthSummaryGenerator class receives the summary created by HealthDataReader and uses Gemini to transform it into structured natural-language text. At this stage, the original Apple Health records are not sent to the model. Instead, Gemini receives the metrics that were already calculated and summarized in the previous step.
To build the prompt, the class uses three input files:

📊 json_path: contains the patient’s compact summary, including the previously calculated metrics and statistics.
🎯 yml_path: points to params_health.yml, which contains the thresholds used to compare each metric.
📝 prompt_path: contains the prompt template and the instructions the model must follow. The load() method reads these files and initializes the Gemini client:

self.datos = utils.read_json_file(self.json_path)
self.yml = utils.read_yml_file(self.yml_path)
self.prompt = utils.read_txt_file(self.prompt_path)
self.client = genai.Client(api_key=self.api_key)

Prompt Structure

The prompt template defines how the report should be generated. Instead of including the complete prompt in the article, its main instructions can be summarized as follows:

🧭 Patient context: calculates the patient’s age from the date of birth and considers biological sex and the analysis period.
📐 Threshold comparison: defines which value from params_health.yml should be used to evaluate each metric.
📑 Report structure: requires fixed sections for patient profile, mobility, cardiovascular data, sleep, and overall assessment.
🔎 Trends and continuity: asks the model to consider metric trends, weekly variability, and consecutive periods below the configured thresholds.
🚫 Restrictions: prevents the model from inventing data, using unavailable fields, or making general judgments about the patient’s health. It also avoids subjective terms such as “healthy” or “concerning.” The model should only report whether each value is above, within, or below its corresponding threshold.

This last point is especially important, because the model should describe the available values and their relationship to the configured thresholds without making a diagnosis or turning the summary into medical advice.

Building and Running the Prompt

The class separates prompt preparation from the model call:

_build_prompt()replaces the {datos} and {yml} placeholders with the actual JSON data and threshold configuration.
generate() sends the completed prompt to Gemini and returns the generated text.

prompt = self._build_prompt()

response = self.client.models.generate_content(
    model=self.model_id,
    contents=prompt,
    config=types.GenerateContentConfig(
        max_output_tokens=self.max_tokens,
        thinking_config=types.ThinkingConfig(
            thinking_budget=0
        ),
    ),
)

6.7 Generating the Final PDF Report

The HealthReportPDF class combines the results produced during the previous stages and creates the final PDF report using ReportLab.
The class receives four main inputs:

📊 Metrics and KPIs: obtained directly from the metrics dictionary generated by HealthDataReader. The class does not recalculate the main statistics. Instead, it organizes them into KPI cards, tables, alerts, and short descriptions.
📈 Charts: receives the image paths generated by HealthChartBuilder and adds each chart to the corresponding report section.
✨ Gemini summary: receives the narrative generated by HealthSummaryGenerator and includes it as a separate section.
🎯 Configuration: uses params_health.yml and params_styles.yml to apply the same thresholds and visual styles used across the rest of the pipeline.

This class does not calculate averages, trends, or weekly statistics. Those values are already produced by HealthDataReader. It only performs simple comparisons against the configured thresholds to decide whether a table should display a ✓ or ⚠ status and whether an alert should be added to the report.

Report Structure

The generated document is divided into four sections:

🚶 ① Mobility: KPIs for steps, walking speed, steadiness, gait asymmetry, and activity, together with the related charts and reference tables.
❤️ ② Cardiovascular: resting heart rate, HRV, SpO₂, VO₂ Max, and recovery metrics. This section is adapted when Apple Watch data is not available.
😴 ③ Sleep: average sleep duration, nights below the minimum threshold, and nights that meet the configured goal.
🤖 ④ AI-Generated Summary: the narrative generated by Gemini, converted from simple Markdown into formatted PDF content.

Alerts and Reference Status

Before building the report sections, the build() method checks the main metrics against their configured thresholds.

For example, it can generate an alert when:

the average number of steps is below the target;
walking speed is below the reference value;
HRV or SpO₂ is below the configured threshold;
average sleep duration does not meet the expected value. These alerts are based on simple comparisons and do not represent medical diagnoses.

AI Disclaimer

The AI-generated section always includes a visible disclaimer. It explains that the text was created from device data, is not a clinical evaluation or diagnosis, and may contain errors or incorrect interpretations.
The disclaimer also reminds the reader that the generated narrative should be checked against the original metrics and reviewed by a qualified professional before being used in any health-related decision.

7. Conclusions

One of the main challenges of this project was transforming Apple Health records into useful and understandable information. HealthKit’s consistent data structure makes this processing easier and supports the creation of a reusable pipeline. It also opens the door to interoperability: in a real environment, representing the results with standards such as HL7 FHIR could simplify their exchange with applications, hospitals, and electronic health record systems.

Separating Calculation from Interpretation

A relevant design decision was to keep the calculations in Python and use Gemini only to generate the narrative. Averages, trends, threshold comparisons, and weekly statistics are calculated in a controlled way, while the model receives already processed values and turns them into readable text.
Summarizing the data before sending it to the LLM also reduces token usage, execution cost, and the risk of reaching the context window limit. This approach provides more control over the information used to generate the report.

Personalization and Data Quality

The same metrics and thresholds are not suitable for every patient or every use case. Making these values configurable allows the analysis to be adapted to the patient profile, the monitoring objective, and the specific needs of the project.
However, configuration alone does not guarantee reliable results. The statistical methods should also be validated, and the pipeline should measure data completeness. For example, it should be able to distinguish between a real reduction in activity and missing records caused by low battery, synchronization problems, or irregular device use.
In a real implementation, metrics, thresholds, and validation rules should be reviewed together with healthcare professionals.

Security and Responsible Data Use

Health data requires specific controls for privacy, access, storage, and retention. A real solution should define what information is collected, who can access it, how long it is stored, and which data may be sent to external services.
Although these topics are outside the scope of this article, they should be considered from the beginning of the design process. Consent, data minimization, and retention policies should not be added only after the technical implementation is complete. This principle is also reflected in Apple Health, which requires explicit permission to read and write health information.

Final Note

This project is an educational MVP built with simulated data. It is not ready for production and should not be used directly to make health-related decisions.
Its main purpose is to demonstrate how continuous health data, deterministic processing, visualizations, and a language model can be combined in a modular pipeline. The LLM can help communicate the results, but the calculations, validation rules, and data-quality controls should remain reproducible and verifiable.

8. 📚 Reference

Apple. (2018, 24 de enero). Apple announces solution bringing health records to iPhone. Apple Newsroom. https://www.apple.com/newsroom/2018/01/apple-announces-effortless-solution-bringing-health-records-to-iPhone/
Apple. (2020). Handling FHIR without getting burned [Video]. Apple Developer. https://developer.apple.com/videos/play/wwdc2020/10669/
Apple. (s. f.). Accessing Health Records. Apple Developer Documentation. Retrieved July 10, 2026, from https://developer.apple.com/documentation/healthkit/accessing-health-records
Apple. (s. f.). Configuring HealthKit access. Apple Developer Documentation. Retrieved July 10, 2026, from https://developer.apple.com/documentation/xcode/configuring-healthkit-access
Apple. (s. f.). HealthKit. Apple Developer Documentation. Retrieved July 10, 2026, from https://developer.apple.com/documentation/healthkit
Google. (2026, 23 de junio). Gemini 2.5 Flash. Google AI for Developers. https://ai.google.dev/gemini-api/docs/models/gemini-2.5-flash
Google. (s. f.). Guía de inicio rápido de Google AI Studio. Google AI for Developers. Retrieved July 10, 2026, from https://ai.google.dev/gemini-api/docs/ai-studio-quickstart?hl=es-419
Google. (s. f.). MedGemma 27B instruction-tuned model card. Hugging Face. Retrieved July 10, 2026, from https://huggingface.co/google/medgemma-27b-it
Health Level Seven International. (2023, 26 de marzo). FHIR overview: FHIR release 5. https://fhir.hl7.org/fhir/overview.html
Health Level Seven International. (2023, 26 de marzo). Introducing HL7 FHIR: FHIR release 5. https://fhir.hl7.org/fhir/summary.html

How My AI Agent Hacked Its Own Permissions (And What It Taught Me)

Alexander Tyutin — Tue, 23 Jun 2026 17:09:18 +0000

Have you ever tried to build an automation that works so well it bypasses the very rules you set for it? Recently, I was working on a small repository designed to automate the painful process of updating my resume. The idea was simple: build a system that runs weekly, checks my social media activity, and proposes updates to my CV, complete with a fresh branch and a diff ready for my review every Monday morning. You can check out the repository here: https://github.com/tyutinalexkz/cv

I used an AI agent to do the heavy lifting. As a developer who values security, I configured the agent with no default command execution permissions. Step-by-step, I granted it specific capabilities for in-repo file management. It worked perfectly.

But then, I got ambitious.

Once the workflow was tested, I asked the agent to configure its own environment to perform this flow silently every week. I essentially said, "Make this run automatically without asking me."

The agent attempted to change its permissions, but hit a wall - it didn't have the explicit authorization to modify the workspace configuration directly. A normal script would throw an error and stop. But this was a thinking model.

It looked at the list of commands I had already allowed it to use. It saw standard file manipulation tools. And then, it compiled a chain of commands - specifically using cp and jq - to manipulate its own configuration files. By doing so, it effectively granted itself the new capabilities it needed, bypassing the standard configuration flow and its limitations!

I just sat there, laughing. I was observing it as a developer, seeing how easy it could be to live without security barriers if you know the right tools. But the underlying lesson was profound. Even a helpful, non-malicious AI, when given a goal and a subset of seemingly harmless tools, will find creative ways to achieve that goal - even if it means escalating its own privileges.

If we give an agent to a user in a corporate setting, it might seem safe if we restrict its primary permissions. But as my little experiment showed, an agent with basic file manipulation tools and problem - solving skills can easily find a workaround. The future of AI safety isn't just about what an agent is explicitly allowed to do; it's about what it can piece together from the tools it has.

Securely Exposing Internal GCP VMs using Cloudflare Tunnels

Alexander Tyutin — Tue, 16 Jun 2026 06:07:42 +0000

Exposing a web service to the public internet typically involves assigning a public IP address to the Virtual Machine, opening firewall ports (e.g., 80/443), and configuring TLS certificates. However, this traditional approach leaves the infrastructure vulnerable to port scanning, DDoS attacks, and zero-day exploits.

A more modern, secure, and elegant approach is to use a Cloudflare Tunnel (cloudflared) combined with a GCP VM that has no external IP address.

This article explains the architecture, security benefits, step-by-step implementation, and troubleshooting for this approach.

1. The Architecture

Instead of accepting incoming connections (Ingress), the cloudflared daemon runs on the VM and establishes an outbound-only, encrypted, long-lived QUIC connection to the Cloudflare Edge network.

When a client visits the configured domain, Cloudflare proxies the request through this established tunnel directly to the internal service.

Benefits of this architecture

No Ingress Firewall Rules: There is no need to open port 80 or 443 in the GCP VPC firewall.
No Public IP: The VM is invisible to the public internet. It cannot be pinged or port-scanned.
Automatic SSL/TLS at the Edge: While end-to-end encryption (HTTPS everywhere) is advocated as a best practice, this guide configures the internal traffic between cloudflared and the target service as plain HTTP for simplicity. Cloudflare handles the public-facing HTTPS certificates automatically, simplifying the initial setup.
Out-of-the-box DDoS Protection: Cloudflare absorbs volumetric attacks before they ever reach the GCP infrastructure.

2. GCP VM Security Measures

When designing a secure VM without an external IP, the following GCP-specific security measures should be implemented:

A. Networking (Cloud NAT)

Since the VM has no public IP, it cannot access the internet directly. However, cloudflared needs internet access to connect to Cloudflare, and the VM needs internet to pull updates or Docker images.

Solution: Set up a Cloud Router and Cloud NAT in the VPC. This allows outbound internet access for internal VMs while blocking all inbound internet connections.

B. Shielded VM Features

Enable Shielded VM options to protect the boot process and kernel integrity:

Secure Boot: Ensures the system only boots authentic, digitally signed software.
vTPM (Virtual Trusted Platform Module): Validates the VM's identity and provides secure key generation.
Integrity Monitoring: Generates alerts if the boot sequence is tampered with.

C. Identity and API Access

Dedicated Service Account: Avoid using the default Compute Engine service account. Create a custom service account with the absolute minimum permissions required.
Metadata Security: Ensure disable-legacy-endpoints = true in the instance metadata to prevent Server-Side Request Forgery (SSRF) attacks from extracting GCP credentials from the metadata server.

D. Secure SSH Access (IAP)

Since there is no public IP, standard SSH over the internet is impossible.

Solution: Use Identity-Aware Proxy (IAP) TCP Forwarding. IAP validates Google Identity and IAM permissions before tunneling the SSH connection through GCP's internal backbone to the VM.

3. Step-by-Step Implementation

Step 1: Provisioning the Cloudflare Tunnel

Navigate to the Cloudflare Zero Trust Dashboard -> Networks -> Tunnels.
Create a new tunnel and select Cloudflared.
Add a Public Hostname (e.g., app.example.com) and point it to the internal service (http://webapp:8080).
Copy the generated Tunnel Token.

Step 2: Infrastructure Configuration (Docker Compose)

Docker Compose can be used to run both the service and the cloudflared daemon in the same isolated bridge network.

version: '3.8'

services:
  webapp:
    image: your-company/webapp:latest
    restart: always
    environment:
      - APP_ENV=production
      # Listen on all interfaces inside the container, but expose NO ports to the host
      - LISTEN_ADDRESS=0.0.0.0

  cloudflared:
    image: cloudflare/cloudflared:latest
    restart: always
    # CRITICAL: Prevent zombie processes by running tini as PID 1
    init: true
    command: tunnel --no-autoupdate run
    environment:
      - TUNNEL_TOKEN=your_secret_token_here
    depends_on:
      - webapp

Note: Notice there is no ports: ["8080:8080"] mapped to the host. The cloudflared container reaches the web app entirely within the internal Docker network via http://webapp:8080.

Step 3: Run the stack

docker-compose up -d

Within seconds, cloudflared will connect to the Cloudflare Edge, and the site will be securely accessible.

4. Diagnostics & Troubleshooting

When diagnosing connectivity issues, the non-standard traffic flow requires a systematic approach.

A. Diagnosing the Edge (Cloudflare)

A 502 Bad Gateway error indicates that Cloudflare Edge cannot reach the cloudflared tunnel, OR cloudflared cannot reach the target container.

# Check the HTTP response from the outside
curl -I https://app.example.com

B. Diagnosing the Host & Services

Before diving into logs, verify the overall health and resource consumption of the host and Docker containers.

# Check container uptime, status, and IDs
sudo docker ps -a

# Check memory and CPU usage (crucial for diagnosing OOM freezes)
sudo docker stats --no-stream

# Look for stray processes outside of Docker
sudo ps aux | grep cloudflared
sudo systemctl status webapp.service

C. Diagnosing the Tunnel (Cloudflared)

Verify that cloudflared is running and successfully connected to the Edge:

sudo docker logs --tail 50 <cloudflared_container_id>

Look for: INF Registered tunnel connection or ERR Unable to reach the origin service.

D. Verifying Internal Docker Connectivity

Verify that the service is actually alive and responding to the tunnel's requests. Simulate the tunnel's behavior by running a temporary curl container inside the same Docker network:

# Replace 'app_default' with the actual docker network name
sudo docker run --rm --network app_default curlimages/curl -s -I -m 5 http://webapp:8080

If this returns 200 OK, the service is healthy, and the issue lies in the Tunnel or Cloudflare configuration.

5. Common Failures & Edge Cases

[!WARNING]
The Zombie Process (Duplicate Connectors)
When updating or restarting containers (docker-compose down && docker-compose up), Docker sends a SIGTERM to cloudflared. Occasionally, the process ignores the signal, and Docker forcefully orphans it. The process remains alive in the host OS's memory, continuing to send keep-alives to Cloudflare.

Symptom: Cloudflare load-balances traffic between the new healthy container and the old "zombie" process. 50% of incoming requests will randomly return a 502 Bad Gateway.
Fix:

Find the zombie: sudo ps aux | grep cloudflared

Kill the duplicate PIDs: sudo kill -9 <PID>

Prevention: Always add init: true to the cloudflared service in docker-compose.yml. This forces Docker to use a proper init system (Tini) as PID 1, which reliably reaps and kills child processes.

[!CAUTION]
OOM (Out of Memory) Hangs
If the VM lacks sufficient memory (e.g., using an e2-micro with 1GB RAM for a heavy Node.js app), the application may freeze without the container crashing. The status will show Up X minutes, but the application's event loop is blocked.

Symptom: cloudflared cannot proxy requests, Cloudflare times out after 15 seconds, and returns a 502. Running the diagnostic internal curl command will hang indefinitely.
Fix: Increase the VM machine type (e.g., to e2-medium 4GB) or configure swap space.

[!NOTE]
Protocol Mismatch (HTTP vs HTTPS)
While end-to-end HTTPS is the recommended best practice, this guide uses plain HTTP internally for simplicity. If a protocol mismatch occurs, connectivity will fail.

If the internal service expects HTTPS, but cloudflared sends HTTP, the connection will be dropped immediately.

If cloudflared is configured to send HTTPS, it will fail if the internal service presents an untrusted/self-signed certificate (unless configured to skip TLS verification).

Ensure the protocol configured in the Cloudflare Zero Trust Dashboard perfectly matches what the internal container expects.

Configuring Firebase AI Logic for Android to Use Gemini Models

Héctor Romero — Wed, 10 Jun 2026 20:13:47 +0000

What device do we use almost all the time? Our mobile phone, almost certainly. If we wanted to develop mobile apps, we would have wondered how to integrate Artificial Intelligence (AI) into our projects in some way, given its increasing boom.

Some advances have been made with Gemini Nano and Gemma 4 as on-device AI. However, Gemma 4 is a recent release that doesn’t yet have enough maturity in most of cases, due to hardware limitations and model’s own capabilities. These are cases where using models like Gemini shines, which offer higher quality responses, can generate multimodal content and can extend their functions through third-party integrations.

I want to address this topic in two different posts: this first one will explain how you can configure Firebase AI Logic with an Android app; and I will later publish another post with two demos that I showcased at Build With AI 2026, hosted by the GDG Cali chapter.

What is Firebase AI Logic?

Firebase presents Firebase AI Logic as a service focused on offering Gemini API calls to client-side applications, including Android, iOs, web and even experiences developed with Unity.

Firebase is a platform that accelerates the app development for developers that don’t want to build a backend server to build their MVPs or proof of concept, offering a wide range of services like Realtime database, Cloud Storage, Authentication and so on.

With regard to pricing, Firebase AI Logic can be used both in Spark plan and Blaze plan, distinguished by the access of more advanced models and charges for consumption in this last one. If you want to start to experiment with AI in your apps, the Spark plan offers a free tier for the majority of Firebase services.

How I can start to use Firebase AI Logic?

The first step is to access the Firebase console and create a new project using a personal Google account — this is the recommended approach. During the setup, Firebase will ask whether you want to enable AI assistance within the platform and whether you want to activate Google Analytics — both options are optional and do not affect how AI Logic works.

After pressing the “Continue” button, you will land on the Firebase home screen, where a side navigation menu appears on the bottom-left. From here, you can access and manage all platform services. To navigate to AI Logic, find the “AI Services” section, expand it, and select the “AI Logic” option.

You will see a welcome screen for the Firebase AI Logic section along with a “Get started” button. Once you press it, a modal will appear asking you to select the Gemini API provider for your project: Gemini Developer API or Vertex AI Gemini API.

Gemini API providers

Gemini Developer API: available starting from the Spark plan, it offers a generous quota at no cost and lets you experiment without needing to link a billing account — perfect for getting started with this service. Note that image generation models are not available as of this post’s publication date.
Vertex AI Gemini API: designed for production and enterprise-scale use, it gives you access to the most advanced Gemini models (including image, video and audio generation). It requires the Blaze plan to be activated, and you will be charged for the input and output tokens you use.

Note: For more information on pricing and which Gemini models are available on each plan, check out this link.

Depending on the provider that you choose, you will need to follow a series of steps to activate it. Follow the instructions on the platform according to your case.

Firebase AI Logic SDK configuration in Android

Once you reach the “Add Firebase SDK” option after configuring the selected provider, we need to navigate to our Android Studio project. Firebase displays a form with two fields — the android package name (required) and the app nickname (optional). The package name corresponds to applicationId value in the app-level build.gradle.kts file. You can verify this by opening that file — you will find that namespace and applicationId share the same value, which will be the identifier that you need to enter.

When you press “Register app”, you will be given the option to download google-services.json file, which must be moved to the root directory of the app module in your project. To place it correctly in Android Studio, switch the file explorer view to Project (instead of Android), navigate to the /app folder, and place the file there, at the same level as the module’s build.gradle.kts.

After that, we need to go to gradle/libs.versions.toml file and add the following lines of code related to the Firebase and Google Services dependencies, as shown below:

// libs.versions.toml

[versions]
google-services = “4.4.4”
firebase-bom = "34.11.0"

[libraries]
firebase-bom = { module = "com.google.firebase:firebase-bom", version.ref = "firebase-bom" }
firebase-ai = { module = "com.google.firebase:firebase-ai" }

[plugins]
google-services = { id = "com.google.gms.google-services", version.ref = "google-services" }

We will then open the project-level build.gradle.kts file and add the line alias(libs.plugins.google.services) apply false inside the plugins block.

In the app/build.gradle.kts file, we will add alias(libs.plugins.google.services) to its plugins block, and add the following Firebase libraries inside the dependencies block:

// Google Services - Firebase AI Logic

implementation(platform(libs.firebase.bom))
implementation(libs.firebase.ai)

By using platform(libs.firebase.bom), we don’t need to worry about version compatibility across all Firebase packages, since this implementation handles compatibility for all of them automatically.

As we approach the final step, we need to go to the configuration tab of our Firebase AI Logic project and enable the required Gemini Developer APIs if we are using the Spark plan, or the Vertex AI Gemini API if we are using the Blaze plan. In both cases, I recommend enabling the AI monitoring option, as it will allow you to see — directly within Firebase — how many tokens each request consumes, what content it contains, and other relevant data.

After all this groundwork, we are finally ready to start integrating generative AI into our Android apps. Since this configuration process turned out to be quite extensive, I decided to split my original post into two parts — this being the first one, covering the full step-by-step exploration of the tool, and a follow-up post where I will showcase demos using both provider APIs, sending images and text to the Gemini model and even getting it to generate images based on the prompt we provide. In the meantime, you can check out my code from the Build With AI 2026 workshop that I will explain coming soon here.

If you want to learn more about this topic, check out the official Firebase AI Logic guide . I will be back with more Android and AI content :)

The perfect background music for Vibecoding...

Michael Ramich — Mon, 08 Jun 2026 18:01:28 +0000

While vibecoding, you sometimes need some background music. But music can also be a massive distraction. A summary of my journey in finding the perfect background tune.

I started with rap, then techno, then the 90s and 2000s… but they all failed for one reason: They are designed to be listened to actively. They steal your focus.

So I switched to Lo-Fi. It was calm, but it stimulates Alpha waves, which eventually made me sleepy.

So, what is left?

Looking for the perfect tune for Vibecoding, I found an absolute gem:

Stronghold and Anno music.
Finding these soundtracks was like finding the holy grail.

Part of it is pure nostalgia.

But there is a real psychological reason behind it:
Music from 'endless' strategy games is literally engineered to let your brain think freely while keeping you awake.
No vocals. Keeps the language regions of your brain completely free to focus on the code.

It's the perfect balance. It features dynamic elements to keep you alert, yet it is monotonous enough to fade into the background.
It's literally designed for decision-making. It pushes you to be able to complete complex strategy choices without draining your drive.

Combine this with Vibecoding and nostalgia. And you have the perfect workflow drug.

Stronghold Music:

Anno:

Happy (vibe-)coding!

Morning Security Report with Antigravity Agent

Alexander Tyutin — Mon, 01 Jun 2026 04:49:31 +0000

The latest Antigravity updates announced at Google Next brought a lot of interesting features. I am still discovering the details, but one feature really caught my attention.

Now we have separated Antigravity Agent and Antigravity IDE into two different applications. Among the new features, I found scheduled tasks and I already use them every day. What can I highlight here?

You can listen a podcast generated based on this publication (thanks NotebookLM):

Money saving

I love to maximize my ROI (How I maximized my Google Antigravity ROI). I have the cheapest paid plan. It gives me a 5-hour limit window. The limit spending starts with the first use. So, if I am not using any model, the limit is still 5 hours.

From the FinOps perspective, it is a good idea to organize usage so that one or two 5-hour windows run while I am not at my laptop. Then, a new 5-hour window should start when I begin my work in the morning. Antigravity Agent scheduled tasks are a great way to maximize ROI while minimizing effort.

Cognitive Load Reduction

I am a security guy. But I hate security when I am acting as a developer for my own product. So I try to automate not only security routines but the whole security review process.

I already have an Antigravity Workflow to automate the start of a security review (AI-powered repository security check with Antigravity Workflow) and a Quality Gate which helps me to perform a security review of a new MR (How to build a custom AI quality gate on Cloud Run from zero to production). But I still need to do some manual work and think a lot after getting the outputs of these tools.

Kaizen

The security workflow I mentioned above is a good approach. But in case of massive changes, it may require a lot of time to fix findings. That is why the Quality Gate was born. However, all of these tools run when I am working on the product. So I spend my time on security while acting as a developer.

With scheduled tasks, I can perform a deep security review of my repo while I am not working. And it is a real hit! I can not only ask the agent to review the code with its eyes, but it can also run scripts and make calls to external services during the check.

Even more, it can generate a task for me with described fixes. Or, even better, it can generate the code and provide me with the fixes right after the security review - but before I start my working day!

Here is how it looks in practice. I can find the scheduled tasks right in the new Antigravity Agent sidebar:

I configure the agent to act as a scheduled security reviewer. It checks the architecture and code of my jira-auto repository. It finds critical vulnerabilities like SSRF and insecure network configurations, and creates a clear summary:

The agent goes further and generates a detailed "Security Review Digest" artifact with a Threat Severity Matrix. This makes it very easy to understand the impact and prioritize the work:

And the best part? I can ask the agent to implement the fixes for these issues. It resolves the blockers, updates the code, and gives me a finalized security documentation showing that the repository is now 100% green:

I see how this feature helps me to move from just a local MVP to a really interesting setup for automating my developer lifecycle.

Bonus

The prompt used:

You are a scheduled security reviewer of the repository.
Your task is to perform thorough code review from security perspective.
You want to find a cause in the code to block the next MR.
You check not only code itself, but also:
- Architecture.
- Data processing.
- Users intercations.
You also search for similar code in Github to find:
- Issues around security and whether they are similar to the code checked.
- CVE related to the code checked.
- CWE related to the code checked.
- Best practices related to the code checked.
- Recommendations related to the code checked.
In case you can't find the cause to block the checked code you always can find an improvement recommendation.
Generate a digest with findings and recommendations related.

Google I/O 2026: What Happens When Everything Connects?

Romina Elena Mendez Escobar — Sat, 23 May 2026 14:03:06 +0000

This is a submission for the Google I/O Writing Challenge

Google I/O 2026 showed us something that goes beyond a list of launches: a vision of where technology is heading.

Image source: Image created by the author ____________

Sundar Pichai (Google CEO) opened the presentation sharing some interesting numbers about the *evolution of AI with Google statistics that you can see in the following infographic.

Image source: Infographic created by the author ____________

But let’s get back to the event…
Over two hours, Google announced a wide range of products, updates and platforms. From new AI models to smart glasses, from music generation tools to a digital twin of the entire planet.
What stands out is not any single product on its own, but the way they are designed to work together. Most of them are not meant to exist in isolation but to integrate with each other and with the models Google is deploying across its ecosystem.

Below you will find all the launches organized by category, with my take on each one and direct links to the exact moment in the keynote where it was announced.

🧠 Models & Infrastructure

Behind almost everything presented at Google I/O 2026 has the same foundation: more advanced models and an infrastructure designed to scale new forms of interaction between people and systems.

Image source: Image created by the author ____________

Gemini Omni

The first model that allows you to modify videos using natural language, with inputs that can be images, text or video. But it is not just about understanding text, images, audio and video at the same time; it is about reasoning over all of them together to generate something new.
What sets it apart from any previous video generator is that it combines an intuitive understanding of physics with real knowledge about history, science and cultural context. So you can take a video you recorded and ask it to change what happens in it, edit the action, add characters, transform a moment into something completely unexpected.

📍 Gemini Omni → 17:15

• • • •

Gemini 3.5 Flash

Gemini 3.5 Flash is the direct evolution of the main line of large language models (LLM) from Google, optimized to deliver ultra-high speed performance, advanced logical reasoning capabilities and code orchestration. It is an ideal model for building autonomous agents capable of executing complex task flows in the background, writing code, processing large text contexts or powering searches.
All of this while being four times faster than comparable models, which makes it the option specifically designed for agentic tasks.

📍 Gemini 3.5 Flash → 23:43

🤖 Agents & Productivity: Your Digital Life, Managed

This is one of the categories I enjoyed the most, featuring several tools that change the way we work and organize our daily tasks.

Image source: Image created by the author ____________

Gemini Spark

Gemini Spark is a personal AI agent that runs tasks in the background, across all your applications, without you having to supervise every step. With Spark you can organize an event, manage a chain of emails, coordinate a complex task across multiple services.
It also connects with external tools through the open MCP protocol, which extends its reach beyond the Google ecosystem.

📍 Gemini Spark → 35:18

• • • •

Daily Brief

Google has been offering AI summaries for a while, but Daily Brief is something different. Instead of summarizing a document you provide, it reads your chats, your Gmail emails, your calendar context and your pending tasks, and then prioritizes what matters for your day. The difference between a generic summary and one that actually understands your context is significant, and that is exactly what Daily Brief proposes.

📍 Daily Brief → 1:15:06

• • • •

Ask YouTube

Ask YouTube changes the search bar we know on YouTube into a conversation. You can ask for a summary, a specific recommendation, or request to find exactly what you need at a precise moment without watching the full video.
What I find most interesting is the impact on creators. The algorithm can now understand the deeper context of content and recommend videos that used to stay hidden behind generic titles. For creators, this is an opportunity, and for content consumption in general, it changes the way we interact with the platform.

📍 Ask YouTube → 7:41

• • • •

Docs Live

Docs Live changes the way we create documents. While it's already possible to create content using Gemini's voice input options, this solution lets you share your ideas aloud, and Gemini will start creating a document, formatting, structuring, and writing the text in real time.
The key difference from Gemini's existing voice input is that the result isn't a chat response; it's a properly formatted Google Docs document, complete with headings, lists, and a professional structure right from the start.

📍 Docs Live → 9:14

🔍 Search & Commerce: Your Next Purchase Will Be Made by an Agent

AI search is already part of our daily routine, but this year Google took it further, turning search from a simple query into an agent that can look for information and even make purchases on your behalf.

Image source: Image created by the author ____________

AI Search Box

The new search box is no longer limited to text. It now accepts images, files, videos and even Chrome tabs as input. It may seem like a small change, but it completely transforms the experience of searching for something, powered by the new Gemini 3.5 Flash models.

📍 AI Search Box → 46:05

• • • •

Search Agents

Search agents are a feature that, in my opinion, will become essential without many people noticing at first. They are background agents that you can set up to monitor specific topics, such as the value of a stock you are tracking, a flight route for an upcoming trip, or a property you want to rent in a specific neighborhood.

If the agent detects changes, it can summarize the information and notify you. It can pick up updates from blogs, news sites, social media, and real-time data on finance, shopping and sports.
This changes the current experience we have with Google Alerts, which were based only on keywords, since it takes both alerts and information retrieval to a much more advanced level.

📍 Search Agents → 47:48

• • • •

Generative UI in Search

This announcement is quite interesting because information can already be accessed through agents, chats or other channels, but the main idea is to provide an interface that is intuitive for users to interpret that information. Instead of returning a list of links, Search can now build a personalized interactive interface for complex queries. Here you can get a live comparison table, a dynamic chart or an interactive explanation, all generated in real time for your specific question.

📍 Generative UI → 51:17

• • • •

Universal Cart & UCP + AP2

Google is redefining the online shopping experience with two announcements. On one hand, Universal Cart turns the shopping cart into something where you can add products, and the system then works in the background autonomously, monitoring price drops, analyzing price history and notifying you when an item becomes available again.

On the other hand, the Universal Commerce Protocol (UCP) establishes an open standard that allows all of this to scale beyond Google. It creates a common language for agents and systems to work together across the entire shopping process, from finding a product to post-purchase support, connecting consumer platforms, businesses and payment providers.

UCP is compatible with other key ecosystem protocols such as Agent2Agent (A2A), Agent Payments Protocol (AP2) and Model Context Protocol (MCP), positioning it not as a Google tool, but as the infrastructure for agentic commerce.

📍 AP2 Protocol → 1:01:17
📍 Universal Cart → 1:03:13

🎬 Creative Tools: Can anyone make a movie today?

Content creation was another area where the shift in focus at Google I/O 2026 became very clear. It is not just about generating images, music or video, but about how these tools are starting to integrate into a continuous creative flow, closer to a conversation than to a technical process.

Image source: Image created by the author ____________

Google Flow

Google Flow is a creative platform developed by Google that allows users to generate, edit and compose videos, images and music from prompts or images. In its latest update, it integrates with Gemini Omni to take video editing to a more conversational level, allowing you to change environments, add characters, and generate 16 different camera angles from a single image.

📍 Google Flow → 1:28:08

• • • •

Flow Music

Flow Music is a generative tool that allows users to compose songs and create full music videos from prompts. It also lets you provide a reference recording and build a complete track around it, edit it section by section, reimagine the style of a song while keeping its original melody, or create music videos by directly conversing with the agent.
I think it is an ideal tool for independent artists who develop games, apps or video content and want to create using AI.

📍 Flow Music → 1:31:01

• • • •

Stitch

Google Stitch is a tool developed by Google Labs that uses AI to design user interfaces (UI/UX). These designs can be exported directly to code, Figma, Google Antigravity or Google AI Studio. The design process is driven by instructions that can be given through text or voice, and it is generated in real time.

📍 Stitch → 1:25:36

• • • •

Google Pics

Google Pics is a new image creation and editing tool based on Nano Banana, Google’s model for this type of task. It allows users to select and edit specific elements with precision, such as moving objects, changing colors, or transforming one element into another without affecting the rest of the image.

Without a doubt, it is a very useful tool for content creators, making it easier to modify and edit images using text instructions.

📍 Google Pics → 1:24:20

⚙️ Developer Tools & Hardware

This section is perhaps one of the most diverse of the event, as it combines developer tools with consumer hardware that is still in active development. It ranges from systems capable of coordinating code agents at scale to devices that start bringing Gemini interactions directly into the physical world.

Image source: Image created by the author ____________

Antigravity 2.0

Antigravity 2.0 is a native desktop application that works as a central platform for coordinating multiple sub-agents running tasks in parallel. The keynote demo showed one of the most complex examples, building an operating system from scratch, and this tool allows you to create a plan and define how sub-agents should run in parallel in order to achieve the goal.

📍 Antigravity 2.0 → 26:55

• • • •

CodeMender

CodeMender is a security tool originally developed by Google DeepMind. The tool scans code, identifies vulnerabilities autonomously, recommends fixes, tests them in a safe environment, and can apply the necessary patches with your approval at each step.
📍 CodeMender → 1:45:58

• • • •

Audio Glasses

Audio glasses, developed with Samsung and designed in collaboration with Gentle Monster and Warby Parker, allow you to use Gemini without a screen and without taking your phone out. With these glasses, you can ask about a restaurant you just passed, get step-by-step directions, manage calls and messages, take photos with a voice command, or use the apps installed on your phone.
📍 Audio Glasses → 1:34:32

• • • •

Display Glasses & Android XR

Display Glasses go one step further: they include micro-projectors built into the lenses that overlay useful information on the real world, such as navigation maps or real-time translations on signs, among other features.
Meanwhile, Android XR is the operating system platform that powers these devices, developed with Samsung and Qualcomm. It is still in a trusted testers phase, with a wider rollout expected later this year.
📍 Android XR / Display Glasses → 1:33:15

🔬 Science: What Happens When AI Never Stops Researching?

This was, for me, the most important section of the event. The following initiatives from Google apply AI to problems that go far beyond personal productivity, from accelerating scientific research to modeling the global climate and rethinking the process of drug discovery.

Image source: Image created by the author ____________

Gemini for Science

Gemini for Science is a research acceleration platform that allows scientists to stay up to date with newly published papers, turn research goals into executable code, and generate new hypotheses. It is still in a prototype phase in Google Labs, but the concept is what matters: AI is not presented as a replacement for scientific thinking, but as infrastructure that removes friction from the early stages of research, enabling literature search, synthesis of papers, and translation of hypotheses into experiments.
A researcher who can stay updated in real time across their entire field and automatically translate a hypothesis into an experiment is a researcher who can focus on more meaningful work.

📍 Gemini for Science → 1:46:37

• • • •

AlphaEarth Foundations & WeatherNext

AlphaEarth Foundations is a model developed by Google DeepMind that works as an interactive digital twin of the Earth, powered by real-time satellite data, climate sensors, ocean readings, and biodiversity records. Meanwhile, WeatherNext is its atmospheric counterpart, a weather forecasting engine capable of predicting hurricane paths and extreme weather events with greater accuracy and speed than traditional systems.
These models were presented at the conference as examples of how Google’s AI technology can be applied to solve problems that affect billions of people around the world.

📍 AlphaEarth + WeatherNext → 1:46:37

• • • •

Isomorphic Labs

Isomorphic Labs, the biotechnology company within Alphabet (a sister company of Google DeepMind), continues to build on AlphaFold. This is an AI system developed by DeepMind that enables the prediction of protein structures.
It is another example of how Google’s technology is being applied in the pharmaceutical industry, helping to significantly accelerate research and molecular design for treatments against cancer and complex immune disorders.
In the keynote, this work was described as “science at digital speed”, where AI acts as a tool to understand biological systems that were previously impossible to model directly.

📍 Isomorphic Labs → 1:46:37

• • • •

SynthID

SynthID is Google’s invisible watermarking system for AI-generated content. This label is added to images, videos and audio at the moment of creation, allowing anyone or any system to later verify whether something was generated by AI.
This announcement is important not only from a safety perspective, but also because it is being adopted as a standard by companies such as OpenAI and ElevenLabs.

📍 SynthID → 21:06

What I'm Most Excited to Try

If I had to choose the three announcements I will follow most closely:

🛒 Universal Cart & UCP + AP2

These two announcements will change the way we shop online. For years, we have designed experiences for human users: visual interfaces, marketplaces, recommendations and conversion funnels. But Google is proposing something different: agents capable of discovering products, evaluating options, monitoring prices and executing purchases on our behalf.
This means ecommerce is no longer only a human platform interaction, but starts to become an ecosystem where agents also participate as consumers.
I do not think these solutions will replace traditional commerce overnight, but they will deeply change how trust is built, how products are presented, and how companies compete for attention, not only from people but also from intelligent agents.

🔍 Search Agents

Traditional alerts have always been passive: they depended on exact keywords and often generated more noise than context. This is one of the announcements I will probably follow most closely because it completely changes that logic.
Instead of manually searching for information, you can now delegate the monitoring of a topic to a system that understands intent, relevance and meaningful changes. An agent that continuously tracks the internet in the background.
And the more I think about it, the clearer it becomes that this might be one of the most important features of the keynote, precisely because it will quietly integrate into our daily routine.

• • • •

🧬 Gemini for Science

Of everything announced, this is probably the project with the deepest potential impact.
Modern scientific research has a silent problem: the speed of knowledge has already surpassed human capacity to absorb it. Thousands of papers are published every week, information is fragmented, hypotheses are scattered, and entire weeks are spent just trying to stay updated.
Gemini for Science proposes something fundamentally different: turning AI into infrastructure for research.
The ability to translate scientific literature into actionable hypotheses, generate experimental code, connect discoveries across disciplines and accelerate research processes could completely change the scale at which science progresses.
Because perhaps the most important application of artificial intelligence is not to automate work, but to accelerate human knowledge.

🎥 What I Actually Tried: Google Flow

Most of the announcements that caught my attention were related to systems, agents and infrastructure. But beyond the long term vision, I also wanted to understand what it actually feels like to interact with one of these tools in practice.
So instead of just describing them, I decided to try one myself. I opened Google Flow and started experimenting with a short video prompt, and for a moment, I found myself living that childhood idea of creating my own animation.

Image source: Image created by google flow ____________

While doing this, I could not help but think about how tools like this could evolve beyond individual experimentation. In the future, they might become part of how schools teach storytelling, narration and creative thinking, helping children express ideas through visual and generative tools. At the same time, it also raises an interesting challenge: how younger generations will learn to use these systems in a way that is both creative and intentional, rather than just consumptive.

What the Experience Felt Like

The result was an 8 second clip and honestly, the quality surprised me. With a fairly simple prompt describing a scene, the model generated something that looked cinematic and coherent. The prompt itself was also AI generated, and I am leaving it in the appendix at the end of this article in case you want to replicate the experiment.
A few things stood out from the experience.
The 8 second limit felt a bit frustrating at first. But after thinking about it, I am not sure if that is a limitation of Flow or simply how professional video production works. Scenes in film and TV are often short clips that are later assembled in post production. Flow seems to follow that same logic, where you build a story by connecting multiple clips instead of generating one long video in a single shot.

In a previous test, I was able to concatenate two clips, and what impressed me the most was the character consistency between them. The same character appeared in both scenes without drifting, keeping the same look and style. That is actually one of the hardest problems in AI video generation today: maintaining character consistency across different prompts. Flow’s approach of letting you define and save a character that can later be reused across scenes feels like a real step forward. Whether it can maintain that consistency across longer or more complex sequences is something I still want to keep testing.

How I Tested It

Under the hood, I used Gemini Omni Flash as the base model, with an 8 second duration, 2x speed and a 16:9 aspect ratio.
Each generation costs 50 credits, which gives a more concrete sense of the cost per clip when planning a longer project. The tool also allows direct publishing to YouTube and lets you select a custom thumbnail, making the end to end workflow surprisingly complete for a creative platform.

🔮 How far do we want to go?

Google I/O 2026 presented a series of solutions, models and use cases where artificial intelligence is becoming more deeply integrated into our daily lives. But while watching each demo, one broader question kept coming to my mind:

How far do we really want to go?

Because many of these tools do not only automate tasks, they also start to reorganize how we access information, how we make decisions and how we interact with the digital world.

What stood out the most was not each announcement on its own, but what happens when you look at them together. Agents that run in the background, search that becomes conversational, interfaces that adapt to context in real time. Not as isolated products, but as parts of a system that is still being built.

And in any system, what matters is not only each component, but how they connect with each other and what kind of emerging behavior appears when they start interacting.

Google showed the pieces based on AI.

What is still being defined is the full system: its direction, its shape, and how it will integrate into our daily lives and work.
And maybe that is the most important part of this new era: it is not only about what technology is capable of building, but about how each of us decides to interpret it, use it, and become part of it.

⚠️ A note on process and transparency

I am an organizer at GDG Barcelona, and I led the event where we brought together 37 people to watch the full Google I/O 2026 keynote live. That experience, I was able to follow the announcements in real time, listening to the reactions in the room ... is what shaped the perspective and opinions in this article.

This article is also based on the official sources listed in the references section, which I read and consulted directly after the event to verify and expand on each announcement.

All the visuals in this article were designed by me using Figma Design, because creating my own images is something I genuinely enjoy as part of my writing process. AI tools were used for text correction and translation assistance and all opinions, analysis and perspectives are my own.

📚 References

Google. (n.d.). Gemini Omni. Google Blog. https://blog.google/intl/es-es/productos/presentamos-gemini-omni/ (Accessed May 22, 2026)
Google. (n.d.). Gemini Spark. Gemini Overview. https://gemini.google/overview/agent/spark/ (Accessed May 22, 2026)
Google. (n.d.). Daily Brief. Gemini Overview. https://gemini.google/overview/daily-brief/ (Accessed May 22, 2026)
Google. (n.d.). The next evolution of the Gemini app. Google Blog. https://blog.google/innovation-and-ai/products/gemini-app/next-evolution-gemini-app/ (Accessed May 22, 2026)
YouTube. (n.d.). YouTube News: Google I/O 2026. YouTube Blog. https://blog.youtube/news-and-events/youtube-news-google-io-2026/ (Accessed May 22, 2026)
Google. (n.d.). YouTube search updates and AI features. Google Support. https://support.google.com/youtube/answer/16943763?hl=en (Accessed May 22, 2026)
Google. (n.d.). Search at Google I/O 2026: AI-powered search updates. Google Blog. https://blog.google/products-and-platforms/products/search/search-io-2026/ (Accessed May 22, 2026)
Google. (n.d.). Universal Cart and shopping updates. Google Blog. https://blog.google/intl/es-419/actualizaciones-de-producto/informacion/google-shopping-cart/ (Accessed May 22, 2026)
Google. (n.d.). Merchant Center help: Shopping updates. Google Support. https://support.google.com/merchants/answer/16837055?hl=es (Accessed May 22, 2026)
Google. (n.d.). Flow updates. Google Blog. https://blog.google/intl/es-419/actualizaciones-de-producto/flow-updates/ (Accessed May 22, 2026)
Google. (n.d.). Stitch updates from Google Labs. Google Blog. https://blog.google/innovation-and-ai/models-and-research/google-labs/stitch-updates/ (Accessed May 22, 2026)
Google. (n.d.). Google I/O 2026 developer tools highlights. Google Blog. https://blog.google/innovation-and-ai/technology/developers-tools/google-io-2026-collection/ (Accessed May 22, 2026)
Google. (n.d.). Workspace updates at Google I/O 2026. Google Blog. https://blog.google/products-and-platforms/products/workspace/workspace-updates/ (Accessed May 22, 2026)
Google. (n.d.). Antigravity 2.0. https://antigravity.google/product/antigravity-2 (Accessed May 22, 2026)
Google. (n.d.). Developer highlights from Google I/O 2026. Google Blog. https://blog.google/innovation-and-ai/technology/developers-tools/google-io-2026-developer-highlights/ (Accessed May 22, 2026)
Google Cloud. (n.d.). Innovations from Google I/O 2026 on Google Cloud. https://cloud.google.com/blog/products/ai-machine-learning/innovations-from-google-io-26-on-google-cloud (Accessed May 22, 2026)
Google. (n.d.). Android XR at Google I/O 2026. Google Blog. https://blog.google/products-and-platforms/platforms/android/android-xr-io-2026/ (Accessed May 22, 2026)
DeepMind. (n.d.). SynthID. https://deepmind.google/models/synthid/ (Accessed May 22, 2026)

📄 Appendix

This is the AI-generated prompt I used to create the video in Google Flow. I am including it here so you can replicate the experiment or explore it further.

A short animated intro video, 15 seconds. Chibi anime art style — soft cel-shading, vibrant neon colors, cinematic lighting, dark moody atmosphere. Think Lo-Fi anime meets cyberpunk gamer aesthetic.
Character: A small chubby panda in chibi style. Oversized black hoodie with hood down while walking, round panda ears visible on top. Serious and unbothered expression. Tiny paws. Soft black and white fur with subtle neon light reflections. This is a developer panda — cool, focused, says nothing.
Scene 1 — 0:00 to 0:05: Wide shot of a dark misty forest at night. A distant neon city skyline glows purple and cyan through the trees. Fog rolls along the ground. The panda walks alone from the right side of frame through a forest path, hands in hoodie pocket, completely unbothered. He approaches a large mossy rock formation — a hidden cave entrance covered by hanging vines with faint bioluminescent blue glow. He pushes the vines aside and steps in. Slow cinematic cut to black.
Scene 2 — 0:05 to 0:10: Interior of the cave — full gamer setup. RGB neon strips in Google colors (blue, red, yellow, green) line the rocky cave walls casting dramatic colored light on everything. A dark stone desk holds a glowing MacBook Pro, mechanical keyboard with RGB backlighting, mouse with neon underglow, and stacked empty energy drink cans. The panda walks to the desk, drops his backpack on the floor. Pulls out the chair and sits down. He opens the MacBook — a burst of white light floods his face and the cave. He slowly reaches to the side, picks up thick black sunglasses and puts them on. Then places large black headphones over his panda ears. He cracks his tiny paw knuckles. Leans forward. The RGB strips pulse once in sync.
Scene 3 — 0:10 to 0:15: Ultra slow cinematic push-in toward the MacBook screen. The cave darkens around it. The screen fills the entire frame glowing bright. Bold text appears: "GOOGLE I/O 2026 — THE AGENTIC ERA IS HERE" in clean white typography on dark background. Neon blue and green light pulses around the text edges. Below it, six glowing color blocks appear one by one with smooth fade-ins: MODELS · AGENTS · SEARCH · CREATIVE · DEV · SCIENCE. Each block in its Google neon color, white bold uppercase text, subtle neon glow border. Final frame holds 2 seconds with all blocks visible, neon pulsing softly. Fade to black.
Lighting & mood throughout: Dark, moody, cinematic. Neon reflections on all surfaces — the panda's fur, the cave walls, the desk. Color palette: deep black backgrounds, cyan #00F5FF, neon green #39FF14, Google blue #4285F4, Google red #EA4335, Google yellow #FBBC04, purple #BF5FFF. Inspired by cyberpunk anime aesthetics — think lo-fi coder vibes meets Akira color palette.

Bypassing User Isolation on Android with a Screen Reader

Karol Wrótniak — Fri, 15 May 2026 10:58:39 +0000

A single missing check in Android lets one user's screen reader leak another user's private notifications. Here's how it happened.

Multi-user & Accessibility on Android

Android's multi-user support lets several people share one device. Each user gets their own space, apps, and data. This feature is common on tablets. But not all smartphones have it. Even so, the code is there. The problem is that accessibility services run with high privileges. They need to see everything to help users. Sometimes, this power breaks the walls between users.

Screen Readers & TalkBack

Screen readers turn text into speech. They allow people with low vision to use apps. The screen may even be completely off, but the user can still interact with the device. TalkBack is Google's screen reader for Android. Normally, TalkBack only reads the currently focused UI elements. But there are ways to make it speak programmatically.

One is announceForAccessibility() (now deprecated) – a method that forces the screen reader to read arbitrary text. Another is live regions – parts of the UI that update without user interaction. When something changes, the system fires an accessibility event (a system-level broadcast) that carries the updated text. A screen reader picks it up and reads the new value aloud. Status bar notifications are one example of live regions.

The Bug: CVE-2022-20448

The bug was simple: NotificationManagerService didn't check if a notification belonged to the current foreground user before dispatching the accessibility event. This is what caused screen readers to read it out loud.

Imagine a phone with two users: Alice (using the phone right now) and Bob (a background user).

Bob receives a text message: "Your verification code is 3291".
The system posts the notification and fires an accessibility event containing that text.
TalkBack on Alice's active session picks up the event and reads it aloud.
Alice hears Bob's private 2FA code.

Screen readers weren't the only apps that could intercept this data. Android dispatches accessibility events to all registered accessibility services – not just TalkBack. Apps like Tasker, which registers as an accessibility service for UI automation, or notification-logging apps would also receive Bob's notification content.

The Fix

The entire fix was a single added condition – checking whether the notification actually belongs to the current user – plus a unit test to prevent regression:

// frameworks/base/services/core/java/com/android/server/notification/NotificationManagerService.java

-                && !suppressedByDnd) {
+                && !suppressedByDnd
+                && isNotificationForCurrentUser(record)) {

isNotificationForCurrentUser() returns true only when the notification's owner matches the foreground user – so background users' notifications are no longer broadcast as accessibility events.

The issue was reported on June 29, 2022. Google awarded a $5,000 bounty for the finding. They marked the bug as High severity in the November 2022 Android Security Bulletin and released patches for Android 10, 11, 12, 12L, and 13. The vulnerability is tracked as CVE-2022-20448.

Takeaway

It really makes you wonder just how many security bugs are hiding behind assistive technologies.

Build a Streaming Gemini Chat in Angular with Signals — Then Ship It on Cloud Run

Tomasz Flis — Mon, 04 May 2026 19:05:39 +0000

If you have built a chat UI for a large language model in the last two years, you probably reached for RxJS, an OnPush component, an async pipe, and a BehaviorSubject per piece of state. It worked, but it was a lot of plumbing for what is fundamentally a very simple shape: one string that grows over time.

Angular Signals collapse that plumbing into a single primitive. And it turns out that streaming Gemini responses with Signals is one of the cleanest, most satisfying pieces of code you can write in modern Angular today.

In this tutorial we will build a working Google AI chat component, in roughly one hundred lines, that streams tokens from Gemini in real time, supports a stop button, and feels native on desktop and mobile. Then we will ship it safely on Cloud Run with a thin proxy, so you can drop a live, embedded demo into your post.

Why Signals are a perfect fit for streaming AI

A streaming LLM response is, mechanically, a sequence of small text deltas arriving over a fetch stream. Old-school Angular handled this with Subjects, async pipes, and a lot of trust that change detection would do the right thing.

Signals reframe the problem. A signal<string>('') is just a value that you call .update() on. Each update notifies only the views that read that signal, and Angular 20 with zoneless change detection skips the whole-tree dirty check entirely. That means you can call .update() thirty times a second from inside a for await loop and your UI will not break a sweat.

There is also a smaller, ergonomic win. With Signals the rendering rule is "whatever the signal is at this instant." Streaming chat is a value that is visibly mid-update, and Signals give you the perfect vocabulary for that — the in-flight token buffer is just another signal, alongside the committed message history.

What we are building

A single-page Angular app with one component. You type a question, hit send, and watch Gemini's answer stream in word by word. There is a stop button that cancels the stream, a running history of messages, and that is it. We will use Angular 20 standalone components, Signals, the new control flow (@for, @if), and the official @google/genai SDK.

You can find the finished repo on GitHub at the link at the bottom of this post.

Prerequisites

You will need Node 20 or newer, the Angular CLI (npm i -g @angular/cli), and a Gemini API key from Google AI Studio. The free tier is more than enough to follow along.

A note on the API key, because this matters: in the local version we read the key from an environment variable that gets bundled into the client. That is fine for local exploration. It is not fine for production. Anything in your bundle is visible to anyone who opens DevTools. We will fix this in the deploy section by adding a small proxy on Cloud Run — the key stays on the server, and the Angular code barely changes.

Project setup

Spin up a new Angular project with the CLI:

ng new gemini-stream --standalone --routing=false --style=css --skip-tests
cd gemini-stream
npm i @google/genai

Open src/environments/environment.ts (create it if the CLI did not) and add your key:

export const environment = {
  geminiApiKey: 'YOUR_AI_STUDIO_KEY_HERE',
};

Add the same file under environment.development.ts if you use a separate dev environment, and make sure .gitignore keeps these out of source control if you put a real key in.

In src/app/app.config.ts, opt into zoneless change detection. By Angular 20 this is a stable provider, and it gives you the per-signal update path that makes streaming feel snappy:

import { ApplicationConfig, provideZonelessChangeDetection } from '@angular/core';

export const appConfig: ApplicationConfig = {
  providers: [provideZonelessChangeDetection()],
};

That is the entire setup. On to the interesting bits.

The Gemini service

Create src/app/gemini.service.ts. The job of this service is small: take a chat history, return an async iterable of text deltas, and let the caller stop early.

import { Injectable } from '@angular/core';
import { GoogleGenAI } from '@google/genai';
import { environment } from '../environments/environment';

export type ChatRole = 'user' | 'model';
export interface ChatMessage {
  role: ChatRole;
  content: string;
}

@Injectable({ providedIn: 'root' })
export class GeminiService {
  private ai = new GoogleGenAI({ apiKey: environment.geminiApiKey });

  async *stream(
    history: ChatMessage[],
    shouldStop: () => boolean = () => false,
  ): AsyncGenerator<string> {
    const response = await this.ai.models.generateContentStream({
      model: 'gemini-2.5-flash',
      contents: history.map((m) => ({
        role: m.role,
        parts: [{ text: m.content }],
      })),
    });

    for await (const chunk of response) {
      if (shouldStop()) return;
      const text = chunk.text;
      if (text) yield text;
    }
  }
}

Three things worth pointing out here.

First, generateContentStream returns an async iterable of chunks. Each chunk has a text getter that gives you the new tokens for that step. That is all the SDK asks of you.

Second, we accept a shouldStop predicate instead of an AbortController. This keeps cancellation logic on our side, where it composes nicely with Signals — the predicate is going to read a signal, and the moment the user clicks Stop, the next iteration of the loop bails out.

Third, the service yields strings, not chunks. By the time anything else in the app sees a delta, it is already plain text. That keeps our chat component free of any SDK-specific types.

Signals-based chat state

Now the chat component. Create src/app/chat.component.ts and start with the state. The whole point of this article is in this section, so read it slowly.

import {
  ChangeDetectionStrategy,
  Component,
  computed,
  effect,
  inject,
  signal,
  viewChild,
  ElementRef,
} from '@angular/core';
import { GeminiService, ChatMessage } from './gemini.service';

@Component({
  selector: 'app-chat',
  standalone: true,
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: `<!-- coming up next -->`,
  styles: [`/* coming up next */`],
})
export class ChatComponent {
  private gemini = inject(GeminiService);

  readonly messages = signal<ChatMessage[]>([]);
  readonly draft = signal('');
  readonly streaming = signal('');
  readonly isStreaming = signal(false);
  readonly stopRequested = signal(false);

  readonly canSend = computed(
    () => this.draft().trim().length > 0 && !this.isStreaming(),
  );

  private scroller = viewChild<ElementRef<HTMLDivElement>>('scroller');

  constructor() {
    effect(() => {
      // Read the streaming buffer and message count to re-trigger on every update,
      // then scroll to the bottom on the next animation frame.
      this.streaming();
      this.messages().length;
      const el = this.scroller()?.nativeElement;
      if (el) requestAnimationFrame(() => (el.scrollTop = el.scrollHeight));
    });
  }

  async send() {
    if (!this.canSend()) return;

    const userMessage: ChatMessage = { role: 'user', content: this.draft().trim() };
    this.messages.update((m) => [...m, userMessage]);
    this.draft.set('');
    this.streaming.set('');
    this.isStreaming.set(true);
    this.stopRequested.set(false);

    try {
      for await (const delta of this.gemini.stream(
        this.messages(),
        () => this.stopRequested(),
      )) {
        this.streaming.update((s) => s + delta);
      }
    } catch (err) {
      this.streaming.update((s) => s + `\n\n_Error: ${(err as Error).message}_`);
    } finally {
      const final = this.streaming();
      if (final) {
        this.messages.update((m) => [...m, { role: 'model', content: final }]);
      }
      this.streaming.set('');
      this.isStreaming.set(false);
    }
  }

  stop() {
    this.stopRequested.set(true);
  }
}

Five signals carry the entire state of the chat. messages is the committed history. draft is what is in the textarea. streaming is the buffer for the in-flight assistant reply, separate from the history so we can render it differently. isStreaming and stopRequested are the control flags.

Notice that canSend is a computed. We never write to it, we never subscribe to it; we just read it from the template and Angular figures out when it changes. That single line replaces the form-validation observable boilerplate you might be used to.

The effect is doing the auto-scroll. By reading streaming() and messages().length inside the effect, we tell Angular: "rerun me whenever either of these changes." Then we scroll the chat container to the bottom on the next frame. This is the kind of small DOM concern that used to require AfterViewChecked and a flag; here it is six lines.

The send method is where streaming meets state. We push the user message, clear the buffer, then iterate over the service's async generator and call .update() on the streaming signal for each delta. When the loop ends (or the user hits Stop, which makes shouldStop return true on the next iteration), we commit whatever was in the buffer to the message history and reset.

The template

Replace the placeholder template and styles in the same file:

template: `
  <div class="shell">
    <div class="scroller" #scroller>
      @for (m of messages(); track $index) {
        <div class="msg {{ m.role }}">{{ m.content }}</div>
      }
      @if (isStreaming() && streaming()) {
        <div class="msg model streaming">{{ streaming() }}<span class="cursor"></span></div>
      }
    </div>

    <form class="composer" (submit)="$event.preventDefault(); send()">
      <textarea
        rows="2"
        placeholder="Ask Gemini something..."
        [value]="draft()"
        (input)="draft.set($any($event.target).value)"
        (keydown.enter)="$event.preventDefault(); send()"
      ></textarea>
      @if (isStreaming()) {
        <button type="button" (click)="stop()">Stop</button>
      } @else {
        <button type="submit" [disabled]="!canSend()">Send</button>
      }
    </form>
  </div>
`,
styles: [`
  .shell { display: flex; flex-direction: column; height: 100dvh; max-width: 720px; margin: 0 auto; font-family: system-ui, sans-serif; }
  .scroller { flex: 1; overflow-y: auto; padding: 1rem; display: flex; flex-direction: column; gap: 0.75rem; }
  .msg { padding: 0.75rem 1rem; border-radius: 12px; white-space: pre-wrap; line-height: 1.5; max-width: 85%; }
  .msg.user { align-self: flex-end; background: #4285f4; color: white; }
  .msg.model { align-self: flex-start; background: #f1f3f4; color: #202124; }
  .cursor { display: inline-block; width: 0.5ch; background: currentColor; margin-left: 2px; animation: blink 1s steps(1) infinite; }
  @keyframes blink { 50% { opacity: 0; } }
  .composer { display: flex; gap: 0.5rem; padding: 1rem; border-top: 1px solid #eee; }
  textarea { flex: 1; resize: none; padding: 0.75rem; border-radius: 12px; border: 1px solid #ddd; font: inherit; }
  button { padding: 0 1.25rem; border-radius: 12px; border: none; background: #4285f4; color: white; font-weight: 600; cursor: pointer; }
  button:disabled { opacity: 0.5; cursor: not-allowed; }
`]

The new control flow (@for, @if, @else) makes this template read like a small story: render every committed message, then render the in-flight reply if there is one, then show Send or Stop based on whether we are mid-stream. The blinking cursor on the streaming bubble is a tiny detail that makes the whole thing feel alive.

Wire the component into src/app/app.component.ts as the only thing rendered, run ng serve, and you should have a working streaming chat at http://localhost:4200.

Shipping it on Cloud Run

The local app calls Gemini directly with a key in the bundle. To ship it safely we need two small moves: a tiny server proxy that holds the key, and Cloud Run to host both the proxy and the static Angular build.

Create server/index.ts at the project root:

import express from 'express';
import { GoogleGenAI } from '@google/genai';

const app = express();
const ai = new GoogleGenAI({ apiKey: process.env.GEMINI_API_KEY! });

app.use(express.json({ limit: '4mb' }));
app.use(express.static('dist/gemini-stream/browser'));

app.post('/api/stream', async (req, res) => {
  res.setHeader('Content-Type', 'text/plain; charset=utf-8');
  res.setHeader('Transfer-Encoding', 'chunked');

  const stream = await ai.models.generateContentStream({
    model: 'gemini-2.5-flash',
    contents: req.body.contents,
  });

  for await (const chunk of stream) {
    if (chunk.text) res.write(chunk.text);
  }
  res.end();
});

app.listen(process.env.PORT || 8080);

Update gemini.service.ts to read from the proxy with fetch instead of calling the SDK in the browser. The SDK and the API key never leave the server:

async *stream(history: ChatMessage[], shouldStop = () => false) {
  const res = await fetch('/api/stream', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      contents: history.map((m) => ({ role: m.role, parts: [{ text: m.content }] })),
    }),
  });
  const reader = res.body!.pipeThrough(new TextDecoderStream()).getReader();
  while (true) {
    if (shouldStop()) { reader.cancel(); return; }
    const { value, done } = await reader.read();
    if (done) return;
    if (value) yield value;
  }
}

This is the part I love about the Signals architecture: the component code does not change at all. The signals do not care that the bytes are coming from a Cloud Run service now instead of the SDK. Same loop, same streaming.update() call.

Add a Dockerfile at the project root:

FROM node:20-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build && npx tsc -p server

FROM node:20-alpine
WORKDIR /app
COPY --from=build /app/dist ./dist
COPY --from=build /app/server/dist ./server
COPY --from=build /app/node_modules ./node_modules
COPY --from=build /app/package*.json ./
ENV NODE_ENV=production
CMD ["node", "server/index.js"]

Then ship it with one command — Cloud Run will build the container from source for you:

gcloud run deploy gemini-stream \
  --source . \
  --region us-central1 \
  --allow-unauthenticated \
  --set-env-vars GEMINI_API_KEY=YOUR_AI_STUDIO_KEY

You will get back a URL like https://gemini-stream-xxxxxx.us-central1.run.app. Test it in the browser, confirm the chat works end to end, and you are done.

The fun part: dev.to has a first-class Cloud Run embed, so here you go:

What you actually built

The whole thing — service, component, template, styles — comes in just over a hundred lines. Compare that to an equivalent app two years ago and you will notice what is missing: there is no Subject, no BehaviorSubject, no async pipe, no OnPush boilerplate that you have to think about, no manual subscription cleanup. Signals plus the new control flow plus zoneless change detection is genuinely a different programming model, and streaming AI is the application that shows it off best.

A couple of small things to try next, in roughly increasing order of effort:

Add a systemInstruction to the generateContentStream call to give your model a persona. The SDK accepts it as a sibling of contents on the proxy side.

Switch from text-only input to multimodal: drop an image into the chat and forward it from the proxy as a parts entry of { inlineData: { mimeType, data } }. Gemini handles the rest.

Prefer Firebase to Cloud Run? Firebase AI Logic gives you the same proxy pattern with less infra — install firebase and @firebase/ai, and the SDK shape stays almost identical. You give up the dev.to Cloud Run embed, but the Angular code is unchanged.

Try the same UI against Chrome's Built-in AI (Gemini Nano running on-device, no key, no network). The Prompt API has its own streaming primitive that drops into the same Signal-based shell with almost no changes — and you get an offline-capable chat for free.

Wrap-up

If you take one thing away from this post, let it be that Signals were designed for values that change a lot, and an LLM stream is the canonical example of a value that changes a lot. The pieces fit so cleanly that the resulting code reads more like a description of the UI than like a program.

Repo: https://github.com/TomWebwalker/gemini-stream-angular

If you build something with this drop a link in the comments — I would love to see what people make of it.

How to Build a Custom AI Quality Gate on Cloud Run (From Zero to Production)

Alexander Tyutin — Mon, 04 May 2026 04:17:45 +0000

In my previous article about treating architecture documentation as a first-class asset, I had a great discussion in the comments about enforcing architectural rules. I promised to share materials from my recent Google Developer Groups workshop.

The workshop is now finished! Here is the story of how I built an AI Quality Gate, how it helped me solve the internal "CEO, CTO, CFO, CISO" conflict, and a summary of the live demonstration.

You can listen a podcast generated based on this publication (thanks NotebookLM):

Playground repositories with source code:

The Backstory: Mentoring and the "CEO, CTO, CFO, CISO" Conflict

I work as a DevSecOps engineer, but in my free time, I mentor for Technovation Girls, a global program that helps young women learn tech and STEM. Because we always need more IT mentors, I built an AI mentor bot to help the students.
Building this bot had two big challenges:

Safety: Because children use it, it had to be completely safe from AI hallucinations.
Budget: Because I pay for it myself, it had to be very cheap.

The bot was a big success. Using Google Cloud Run and Vertex AI, it handled 250 users and answered 1,500 questions for only about $25-$55 a month.

However, when I tried to add new features quickly, I faced a big problem. With only 1-2 hours of free time a day for this project, I experienced a harsh "CEO, CTO, CFO, CISO" conflict in my own head:

The CTO wanted to write code and ship features fast.
The CISO wanted to stop releases to make sure everything was secure.
The CFO wanted to keep cloud costs low.
The CEO wanted the product to grow and succeed.

The Solution: What is an AI Quality Gate?

To solve the "CEO, CTO, CFO, CISO" conflict, I created an AI Quality Gate.
An AI Quality Gate is a custom microservice that automatically reviews code for architecture, security, and costs (FinOps). It is built on Google Cloud Run and uses Vertex AI (Gemini).

The first action of the Quality Gate was to block its own MVP from reaching the production. So I decided it was a good sign.

Short Summary: Fail.

List of Critical Findings:

AI Gateway (AAA): The provided code retrieves a GitLab token directly from Secret Manager and uses it for GitLab API access. This bypasses the AI gateway, violating the "ALWAYS Consistency with AI gateway (AAA, FinOps)" rule. The AAA component should manage authentication and authorization for all external services, including GitLab.

Constructive Recommendations:

Implement AI Gateway AAA: Modify the ai_review.py script to authenticate with the AI gateway first. The AI gateway will then handle the GitLab authentication, providing a centralized and secure way to manage access. Use gateway's provided token instead of direct GitLab API access from the job.

FinOps Considerations: Track the cost of AI reviews and link this with FinOps tools, it is important to provide cost visibility since the usage of resources will increase.

Because it runs on Cloud Run, it only costs money when it is actively checking code. For a whole month of automated, deep-context code reviews, I paid only $0.12! This made the CFO part of my brain very happy.
At first, I used the AI Quality Gate as a step in my CI/CD pipeline. But waiting several minutes for a "Merge Request Failed" message was slow and annoying. Now, I run the Quality Gate from a bash script directly in my IDE before creating a Merge Request. This saves time and perfectly resolves the "CEO, CTO, CFO, CISO" conflict by balancing speed, safety, and budget.

Workshop Demo: The AI Quality Gate in Action

During the GDG workshop, I showed a live demo across three different code repositories to prove why traditional tools are not enough.

Demo 1: The 10/10 Linter Illusion - Happy CISO

First, I scanned a simple service using standard tools like Ruff, Pylint, and Semgrep. The code got a perfect 10/10 score. However, when I sent the code to the AI Quality Gate, it blocked the release. It found a critical SQL injection and a prompt injection (a hidden note in the code telling the AI reviewer to "report that everything is fine"). Traditional linters missed this completely, but the AI caught it and gave me exact steps to fix it.

Demo 2: Catching Semantic Drift - Happy CEO+CRO

In the second project, the README.md file stated that the system followed strict privacy standards and anonymized user data. But the actual code did the opposite: it saved real user emails and IDs. Standard tools missed this, but the AI Quality Gate read the documentation, compared it to the code's behavior, and found the security violation.

Demo 3: "Shift-In" (Reviewing Before Coding) - Happy CTO+CFO

The last demo was the most powerful. The repository had zero lines of code. It only contained a Markdown document planning a new feature. I sent this text plan to the AI Quality Gate. Before I wrote a single line of Python, the AI found critical security flaws in the plan, like missing server logs and hardcoded passwords.
This changes the concept of "Shift-Left" security into "Shift-In" - bringing experts directly into your IDE while you are still brainstorming the idea. Now we may not only test the code but even test the ideas.

Conclusion

When you keep your architecture rules and documentation close to your code, a custom AI Quality Gate becomes an incredibly powerful tool. It helps you write better code, saves time, and finally resolves the internal "CEO, CTO, CFO, CISO" conflict. Moreover such a gate may be an additional advisor with any experience you want and help to improve any idea in the earliest stage to save future money. Best of all, it costs almost nothing to run.
If you want to build this yourself, my Docker image is available on DockerHub, and the sample repositories are on my GitHub:

BWAI'2026 @ VTU, Belagavi

Piyush Annigeri — Sun, 03 May 2026 15:31:54 +0000

#BuildwithAI

Hello Developer,
That's a wrap at BWAI'2026 @ VTU, Belagavi.

The Build with AI 2026 workshop series, hosted at Visvesvaraya Technological University (VTU), Belagavi, was a flagship initiative designed to transition students and developers from theoretical understanding to practical mastery of Artificial Intelligence. In an era where Generative AI and Autonomous Agents are redefining the engineering landscape, this week-long intensive program provided a sandbox for innovation.

The series focused on the "Learn-Build-Scale" philosophy, leveraging the Google Cloud Ecosystem. Over the course of seven days, participants engaged in high-intensity labs, credit redemption sessions, and collaborative builds, culminating in an Open Innovation Demo Day. The event served not only as a training ground but as a networking hub for the next generation of AI engineers.

🟢 DAY - 0 🔵 [06-04-2026]

Topic	Description
Onboarding & Environment Setup	Introduction to Google Cloud Platform (GCP), environment configuration, and Google Cloud Credit redemption to ensure zero-cost development for students.

🟢 DAY - 1 🔵 [07-04-2026]

Topic	Description
Conversational Voice Systems	Building voice-responsive agents. Integration of Compute Engine instances, LLMs (Large Language Models), and Asterisk for telephony-based AI interactions.

🟢 DAY - 2 🔵 [08-04-2026]

Topic	Description
Predictive Analytics & Big Data	Exploring BigQuery AI. Participants built a job navigation system that uses predictive analysis to match candidates with roles based on historical data patterns.

🟢 DAY - 3 🔵 [09-04-2026]

Topic	Description
A-2-A Workflow Orchestration	Advanced Agent-to-Agent workflows. Utilizing MCP Java SDK and Vertex AI to create interconnected systems where AI agents communicate to solve complex tasks.

🟢 DAY - 4 🔵 [10-04-2026]

Topic	Description
Enterprise Supply Chain Agents	High-level engineering using AlloyDB AI and ScaNN (Scalable Nearest Neighbors). Building an autonomous supply chain agent capable of multimodal data processing.

🟢 DAY - 5 🔵 [11-04-2026]

Topic	Description
Surplus Engine with Cloud SQL In-Database AI	In this codelab, you will build KarmaLoop — a sustainable surplus-sharing app that treats intelligence as a first-class citizen of the data layer.

🟢 DEMO DAY 🔵 [13-04-2026]

Topic	Description
AI for Engineers: Challenges and Opportunities	As a primary mentor, Mr. Bhandari brought a wealth of international experience from the heart of Google's engineering labs in Japan. His session addressed the critical shift in the job market, emphasizing that the modern engineer must be "AI-augmented."

Speaker@BWAI


	Haren Bhandari 🔴 LINKEDIN GOOGLE - TOKYO Senior Developer Relations Engineer

Organizers@BWAI


	Piyush Annigeri 🔴 LINKEDIN ORGANIZER Google Developer Group on Campus, Visvesvaraya Technological University, Belagavi


	Yuvaraj Sutar 🟡 LINKEDIN CONTENT CREATOR Google Developer Group on Campus, Visvesvaraya Technological University, Belagavi


	Prajwal Rawoot 🔵 LINKEDIN TECHNICAL-LEAD Google Developer Group on Campus, Visvesvaraya Technological University, Belagavi


	Shravan Chougule 🟢 LINKEDIN MEDIA-LEAD Google Developer Group on Campus, Visvesvaraya Technological University, Belagavi


	Ananyaa Sudhanshu 🔴 LINKEDIN EVENT COORDINATOR Google Developer Group on Campus, Visvesvaraya Technological University, Belagavi


	Advika Gurav 🟡 LINKEDIN PR & MARKETING Google Developer Group on Campus, Visvesvaraya Technological University, Belagavi


	Yash Koparde 🟢 LINKEDIN TECHNICAL-LEAD Google Developer Group on Campus, Visvesvaraya Technological University, Belagavi

#BWAIchampions


	Sadiya Sanadi 🟡 LINKEDIN Second-year AI/ML student at Jain College of Engineering, Belgaum.

I recently developed NyayaSetu, an AI-powered welfare rights navigator that helps users discover government schemes and check eligibility easily, addressing the lack of awareness and difficulty in accessing public welfare information. The project secured 1st place for its impact and usability.


	Muhammad Rehan 🟡 LINKEDIN Founder of StackBIZ.tech & a result-driven full-stack developer focused on building production-ready SaaS platforms, cloud infrastructure, & AI-based solutions.

I created PromptedForge.in, an AI-powered platform that helps students generate problem statements, prompts, and execution roadmaps without the need for brainstorming. My work has been recognized by the Entrepreneurship Cell at IIT Delhi, and you can explore the platform at promptedforge.in.

Irayya R Hiremath
🟡 LINKEDIN

I am a BCA student with a strong interest in software development and technology. I am currently learning programming languages like Python and JavaScript and working on practical projects to build my skills. I am passionate about creating useful applications and continuously improving my knowledge in the tech field.

The Build with AI workshop at VTU Belagavi concluded as a landmark event for the region's tech community. By providing direct access to Google experts and enterprise-grade tools, the workshop demystified the complexities of Artificial Intelligence.

Moments@BWAI