DEV Community: Bruce Mcpherson

From Kubernetes to a Self-Healing, Low-Cost Infrastructure

Bruce Mcpherson — Mon, 22 Jun 2026 12:20:53 +0000

I've been running a background project on Kubernetes for a while now. It's not a project that needs 100% uptime, and neither is it one I wanted to spend a lot of time managing or even checking up on, so Kubernetes with Spot VM's seemed the most cost effective solution, and it's been solid and trouble free. However running a couple of pre-emptible nodes with a managed ingress was still costing $150 a month or so. Way too much for a hobby project.

This article is about retaining the self healing capability you get with Kubernets, but migrating to a much more cost effective (about $40 a month) approach. I found that without Kubernetes in the the mix, i could get away with a single VM, but of course that doesn't give me recovery from pre-emption, so here's how to get that too.

Managed instance group

The transition from a high-cost Google Kubernetes Engine (GKE) cluster to a single, highly available Spot VM managed by a Stateful Managed Instance Group (MIG) offers a path to significant cost savings without sacrificing resilience. By leveraging Docker Compose and automated infrastructure orchestration, the platform—comprising microservices such as GraphQL gateways, Elasticsearch processors, and Redis queues—now operates at the lowest possible compute cost while maintaining full recovery capabilities.

Decoupling Compute from State

The core challenge with using Spot VMs is their preemptible nature. To make this architecture immune to data loss during preemption, it utilizes GCP Stateful MIG Policies alongside stable device-id path targeting.

A critical component of this decoupling is Storage State Preservation. Standard attachment targets (like /dev/sdb) are prone to swapping order during VM initialization. To guarantee consistency across machine replacements, the persistent volume is targeted via its unchangeable physical serial header: /dev/disk/by-id/google-existing-data.

The Autonomous Recovery Workflow

When Google Cloud preempts a Spot VM, the system triggers a fully automated self-healing pipeline:

Detection & Provisioning: The MIG detects the deletion and instantly provisions a fresh instance node to maintain the target capacity of one.
Stateful Attachment: The MIG automatically binds the regional static IP and hot-plugs the persistent block storage to the new node at boot time.
Guest OS Bootstrapping: A custom startup-script.sh holds execution until hardware attachment is verified. It then mounts the filesystem, installs the Docker Engine, and restarts microservices seamlessly using ./start-all.sh.

This entire process typically brings the platform back online with zero manual intervention within 60–90 seconds.

Operational States: Preemption vs. Scaling Down

It is vital to distinguish between a True Spot Preemption and a Manual Scale Down to 0.

Spot Preemption: The MIG's intent is to keep one machine online. Per-instance configurations are preserved, and the recovery is fully autonomous.
Scale Down to 0: This decommission command destroys the unique stateful metadata ties. When scaling back to 1, the new VM will get stuck in a boot loop because the MIG no longer knows to attach the existing disk or IP. Recovery in this scenario requires a manual orchestration script, ./create-mig.sh, to re-bind the regional static IP and existing data disk.

Comparing Infrastructure Models

Aspect	Kubernetes (GKE)	Standalone VM	Stateful MIG
Compute Cost	High (Cluster + Nodes)	Medium (Standard VM)	Lowest (Spot VM)
Preemption Recovery	Automatic	Manual Recreate	Fully Automatic
Volume Mounts	PVCs with GCE PD	Local Static /dev/sdb	Stable by-id path
IP Persistence	K8s LoadBalancer	Bound to Instance	Preserved via Config

Docker-compose benefit

Previously I was using kubernetes, cloud build and the artifact registry to manage my builds and releases. This meant that testing was a bit awkward, involving minikube, ngrok and various other workaraounds. Now that I've transitioned to docker compose, the exact same scripts and yaml files work both locally on my mac and on my vm, so i have a complete end to end simulation locally.

Replacing the Kubernetes Ingress

If you need to access the VM externally, you're going to need to create some kind of ingress. Under GKE I was using a managed ingress, with letsencrypt handling the ssl certificate. On our vanilla VM, we can use a traefix proxy. All my services run on docker, as does the traefik proxy. Here's how to set it up.

start-traefik.sh

#!/bin/bash

GREEN='\033[0;32m'
YELLOW='\033[1;33m'
RED='\033[0;31m'
NC='\033[0m'
if [[ "$(uname)" == "Darwin" ]]; then
    echo "Skipping Traefik on Mac (not needed)"
    exit 0
fi

echo -e "${GREEN}🚀 Starting Traefik...${NC}"

# Ensure network exists
docker network create fid-network 2>/dev/null

# Start Traefik
docker compose -f docker-compose-traefik.yml up -d

sleep 3

if curl -s -o /dev/null -w "%{http_code}" http://localhost:80 | grep -q "200\|301\|302"; then
    echo -e "${GREEN}✅ Traefik is running${NC}"
    echo ""
    echo "Traefik is listening on ports 80 (HTTP) and 443 (HTTPS)."
    echo "Check logs: docker compose -f docker-compose-traefik.yml logs -f traefik"
else
    echo -e "${RED}❌ Traefik may not be ready. Check logs.${NC}"
fi

docker-compose-traefik.yml

services:
  traefik:
    image: traefik:v3.2
    container_name: fid-traefik
    command:
      - "--entrypoints.web.address=:80"
      - "--entrypoints.websecure.address=:443"
      - "--providers.file.directory=/etc/traefik/conf"
      - "--certificatesresolvers.letsencrypt.acme.httpchallenge=true"
      - "--certificatesresolvers.letsencrypt.acme.httpchallenge.entrypoint=web"
      - "--certificatesresolvers.letsencrypt.acme.email=admin@xliberation.com"
      - "--certificatesresolvers.letsencrypt.acme.storage=/letsencrypt/acme.json"
      - "--entrypoints.web.http.redirections.entrypoint.to=websecure"
      - "--entrypoints.web.http.redirections.entrypoint.scheme=https"
      - "--entrypoints.web.http.redirections.entrypoint.permanent=true"
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./conf:/etc/traefik/conf
      - traefik_certs:/letsencrypt
    networks:
      - fid-network
    restart: unless-stopped

volumes:
  traefik_certs:

networks:
  fid-network:
    external: true

Some example scripts

All of this is a little tricky and precise, so here are some scripts I have used to get my services running, along with a few hints. I'll assume you already have a reserved static address (if you need to expose publicly)

Your startup script (startup-script.sh)

This is mine - note the connection string that uses the by-id path. google-exisiting-data refers to the persistent disk it should attach. This is not the disk name (in my case that name is fid-data), but a standard name that a mig applies to an incoming state fule disk attachment. Note the subsequent mount command that mounts the disk as its correct name. The systemd platform file describes what to do once all that is complete. I have a start-all.sh there that will actually start all my services using the persistent disk fid-data.

#!/bin/bash
set -e

# --- 1. Wait for persistent disk to physically attach ---
echo "Waiting for persistent disk to attach..."
while [ ! -e /dev/disk/by-id/google-existing-data ]; do
    sleep 1
done

# Give the storage driver a brief moment to stabilize the block mapping
sleep 2

# --- 2. Mount persistent disk ---
mkdir -p /mnt/disks/fid-data
if ! mountpoint -q /mnt/disks/fid-data; then
    mount -o discard,defaults /dev/disk/by-id/google-existing-data /mnt/disks/fid-data
fi

# --- 3. Create symlink to repo on persistent disk ---
mkdir -p /home/brucemcpherson
chown -R brucemcpherson:brucemcpherson /home/brucemcpherson
ln -sf /mnt/disks/fid-data/fidmaster /home/brucemcpherson/fidmaster

# --- 4. Install Official Modern Docker Engine & Compose ---
apt-get update -qq
apt-get install -y -qq ca-certificates curl gnupg

# Add Docker's official GPG key and repository
install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/debian/gpg | gpg --dearmor --yes -o /etc/apt/keyrings/docker.gpg
chmod a+r /etc/apt/keyrings/docker.gpg

echo \
  "deb [arch="$(dpkg --print-architecture)" signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/debian \
  "$(. /etc/os-release && echo "$VERSION_CODENAME")" stable" | \
  tee /etc/apt/sources.list.d/docker.list > /dev/null

# Install the exact modern packages (restores "docker compose" with a space)
apt-get update -qq
apt-get install -y -qq docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# --- 5. Configure Docker data root ---
if ! grep -q '"data-root": "/mnt/disks/fid-data/docker"' /etc/docker/daemon.json 2>/dev/null; then
    echo '{"data-root": "/mnt/disks/fid-data/docker"}' | tee /etc/docker/daemon.json
    systemctl restart docker
fi

# --- 6. Create systemd service file ---
# Using 'tee' inside the script ensures no root permission redirection blocks
cat << 'EOF' | tee /etc/systemd/system/fid-platform.service > /dev/null
[Unit]
Description=FID Platform (all services)
After=docker.service network.target
Requires=docker.service

[Service]
Type=oneshot
RemainAfterExit=yes
User=brucemcpherson
WorkingDirectory=/home/brucemcpherson/fidmaster/vm-docker/local-compose
ExecStartPre=/bin/sleep 5
ExecStart=/bin/bash /home/brucemcpherson/fidmaster/vm-docker/local-compose/start-all.sh
ExecStop=/bin/bash /home/brucemcpherson/fidmaster/vm-docker/local-compose/stop-all.sh
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable fid-platform

# --- 7. Start all services ---
cd /home/brucemcpherson/fidmaster/vm-docker/local-compose
./start-all.sh

echo "Startup complete."

Create a managed group template

Note that the template references this startup-script. If you subsequently change the startup-script, you'll need to replace the template.

gcloud compute instance-templates create fid-vm-template-ephemeral \
    --region=europe-west2 \
    --machine-type=e2-standard-4 \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --boot-disk-size=50GB \
    --boot-disk-type=pd-ssd \
    --provisioning-model=SPOT \
    --metadata-from-file startup-script=startup-script.shgcloud

Create a managed group (create-mig.sh)

The size=1 means i want a single VM. This VM will be called your_mig_name-random_chars.

#!/bin/bash

# 1. Define your known environment variables
PROJECT_ID="your project"
REGION="europe-west2"
ZONE="europe-west2-b"
MIG_NAME="the name for your new mig"
IP_NAME="your static ip name"
DISK_NAME="your persistent disk name"

# Check if the MIG already exists before trying to create it
if gcloud compute instance-groups managed describe "$MIG_NAME" --zone="$ZONE" >/dev/null 2>&1; then
    echo "Managed Instance Group '$MIG_NAME' already exists. Skipping creation..."
else
    echo "Creating Managed Instance Group '$MIG_NAME'..."
    gcloud compute instance-groups managed create "$MIG_NAME" \
        --zone="$ZONE" \
        --template=fid-vm-template-ephemeral \
        --size=1

    # Give GCP a moment to spin up the instance before querying it
    echo "Waiting 15 seconds for instance to initialize..."
    sleep 15
fi

# 2. Automatically grab the dynamic instance name
INSTANCE_NAME=$(gcloud compute instances list --filter="name~'^fid-mig-'" --format="value(name)")

# Safety check: Ensure an instance actually exists
if [ -z "$INSTANCE_NAME" ]; then
    echo "Error: No running instance found starting with '$MIG_NAME-'."
    exit 1
fi

echo "Found target instance: $INSTANCE_NAME"

# 3. Handle the per-instance config cleanly (Create if missing, update if exists)
echo "Configuring stateful IP and Disk resources..."

if gcloud compute instance-groups managed instance-configs describe "$MIG_NAME" --instance="$INSTANCE_NAME" --zone="$ZONE" >/dev/null 2>&1; then
    CONFIG_ACTION="update"
else
    CONFIG_ACTION="create"
fi

gcloud compute instance-groups managed instance-configs $CONFIG_ACTION "$MIG_NAME" \
    --zone="$ZONE" \
    --instance="$INSTANCE_NAME" \
    --stateful-external-ip interface-name=nic0,address=projects/"$PROJECT_ID"/regions/"$REGION"/addresses/"$IP_NAME" \
    --stateful-disk=device-name=existing-data,source=projects/"$PROJECT_ID"/zones/"$ZONE"/disks/"$DISK_NAME",auto-delete=never

# 4. Trigger the MIG to apply these stateful settings to the live VM
echo "Applying configurations to $INSTANCE_NAME..."
gcloud compute instance-groups managed update-instances "$MIG_NAME" \
    --zone="$ZONE" \
    --instances="$INSTANCE_NAME"

echo "Done! Dynamic setup complete."#!/bin/bash

Ssh to your instance (ssh.sh)

My mig group is called fid-mig, so i can extract the instance name and attach to it like this.

gcloud compute ssh $(gcloud compute instances list --filter="name~'^fid-mig-'" --format="value(name)") --zone=europe-west2-b

Simulate a pre-emption to test (simulate-preemption.sh)

In this case, just deleting the instance will simulate a preemption. It will come back up and execute your startup without needing intervention. This differs from the deliberate resizing the MIG to 0 which would need manual intervention to restart the VM.


# 1. Find the current instance name
INSTANCE_NAME=$(gcloud compute instances list --filter="name~'^fid-mig-'" --format="value(name)")

# 2. Simulate a sudden crash/preemption by deleting the instance body directly
gcloud compute instances delete $INSTANCE_NAME --zone=europe-west2-b --quiet

gcloud compute instance-groups managed list

Take down the VM (down-mig.sh)

If you're not using it, might as well save the cost. All you have to do is set the Mig size to 0.

gcloud compute instance-groups managed resize fid-mig \
    --size=0 \
    --zone=europe-west2-b \
    --quiet

gcloud compute instance-groups managed list

Bring up the VM (up-mig.sh)

Setting the size to 1, will reinstate the vm. However at this point it knows nothing about what it's supposed to do, so you also need to run create-mig.sh to get back to a running system.

gcloud compute instance-groups managed resize fid-mig \
    --size=1 \
    --zone=europe-west2-b \
    --quiet

gcloud compute instance-groups managed list

links

article
video

Combining local and hosted llm to minimize token cost

Bruce Mcpherson — Tue, 09 Jun 2026 13:13:55 +0000

My current large project is gas-fakes, which is an emulation that allows local execution, continuous integration, and containerization of native Apps Script code. In other words, we are not just ’emulating Apps Script’ – we are liberating it.

Initially, AI generated code and testing was not something I was comfortable publishing, so to this point real people have coded and tested the majority of the repo. However, now the architecture and techniques are fully mature the remaining work is largely just busy work implementing and testing the remaining, less used, Apps Script platform methods.

As of gas-fakes v2.5.3 we are at 4399/6708 methods and 10,500 parity tests on the emulation against the live Apps Script platform. Now feel a little more confident about allowing AI to do some of coding work.

As an open source developer, my work is voluntary and unpaid, and therefore have to balance the potential token cost at my own personal expense, versus the value of any time saving I might make.

This article is about combining the planning capability of antigravity, with the a free local model (Gemma running under oMLX on a Mac) doing the grunt work. Like this my Gemini costs are minimal, and the local heavy work is free.

Note: this article is specific to Mac/AntiGravity combination. You can use a similar technique for other combinations but I’m not covering them here. gas-fakes collaborators will have this set up already implemented in their repo fork (but need to tweak the .gemini/settings to point to their local path for the mcp tools) , and the local model oMLX delegation will be ignored if they don’t have it running.

Evaluation of the repo content.

Before we start this is the status of the repo according to a Gemini assessment, before I start to use this local model to help with the grunt work. Clearly my priority is to maintain (or improve) the current quality.

You can get a detailed analysis here.

Executive Summary & Core Metrics

Evaluation Dimension	Grade	Key Focus Area / Findings
Architectural Design & Viability	A+	Exceptional synchronous design mimicking V8 GAS on top of Node’s async landscape.
Parity Tracking & Completeness	A	Data-driven tracking system mapping thousands of live Apps Script methods via `/progress`.
Testing, Quality Assurance & Fidelity	A	Massive test footprint (~10,000+ internal/cyclical validation passes) proving true 1:1 behavioral parity.
Edge-Case & Platform Oddities Handling	A-	Deeply transparent about platform limits, script execution quirks, and modern auth drift.
Ecosystem & Modern Stack Readiness	A+	Integrated Model Context Protocol (MCP) server, `gf_agent` automation tool, and containerization.

💎 Overall Project Score: 94/100 (Enterprise Grade / Production Dev Tool)

Gemini Directive & Hybrid Planned Hierarchy

We’ll be using a strict, hierarchical delegation model.

The Roles

Strategic Planner (Gemini): The hosted, powerful LLM. Its role is high-level planning, context management, decision-making, and orchestration. It determines what needs to be done.

Focused Executor (Local Model): The local, specialized LLM. Its role is high-fidelity, resource-intensive execution of specific tasks. It determines how the task is completed.

The Delegation Mechanism (query_local_model)

The Planner is equipped with a specific tool, query_local_model. When the Planner determines that a task requires local computation, it does not attempt to solve it itself. Instead, it generates a structured call to query_local_model, passing the necessary context and instructions to the local MCP Server.

The local model executes the task and returns the result to the Strategic Planner, which then integrates it into the final response.

Operational Constraints (The Golden Rule)

To prevent unnecessary cloud API usage, we can give the Planner strict directives:

The Planner is strictly forbidden from drafting implementation details, writing production code, or creating tests directly when the query_local_model tool is available. If the task falls within the scope of a specialized, local execution, the Planner must delegate the task to the local Executor.

We specify this as part of the skills training – snippet of the important rule below:

Implementation & Focused Execution (CRITICAL DELEGATION GATE)

[!IMPORTANT] ZERO-TOLERANCE DELEGATION GATE You are FORBIDDEN from using write_file or replace to implement logic, write tests, perform refactoring, diagnose/fix debug errors, or draft documentation yourself. MANDATORY SEQUENCE:
Gather context (Research).
CALL omlx/query_local_model with a comprehensive prompt containing specific constraints.
Review and synthesize the output.
Apply changes to files (e.g., in src/, test/, etc.).
EXCEPTION: This mandate only applies if the local model is available and its use has not been explicitly forbidden by the user. If unavailable or forbidden, you may proceed with the tasks using your own weights, but you MUST document the reason in your update_topic.

Cost and Token Savings

Hosted LLMs operating under token-based pricing complex can quickly accumulate unaffordable costs. By offloading the heavy lifting to the local model, you reduce the number of hosted tokens you have to pay for.

oMLX Setup and Documentation

Since I’m using oMLX to serve my local model, let’s look at how to set that up. If you are not using a Mac, there are other local model orchestrators you can use, but the initial setup of those up is outside the scope of this article.

Overview: What is oMLX?

oMLX allows the Planner to offload specific, resource-intensive tasks to a local, specialized LLM (the Executor).

Instead of relying solely on the hosted API for every request, oMLX acts as a middleware layer. The hosted model dynamically decides when a task is best suited for local execution.

Setup and Configuration

The core of the oMLX system is the MCP Server (Model Communication Protocol Server), which acts as the local endpoint for the Focused Executor.

The oMLX MCP Server

an mcp tool acts as a local server. This server listens for requests from the hosted LLM (Gemini) and routes them to the locally running model instance.

Configuration Methods

You control the server and the overall system behavior via these environment variables. the mcp tool uses these to know where to delegate tasks.

Validating that AntiGravity is using the local server

An important step to verify everything is working.

Ask the agy cli – ‘are you able to use the local model’
The mcp server will inform you when it is are using the local model – you’ll see messages like this – omlx/query_local_model(Delegate documentation generation to local model)
Check the oMlx dashboard (http://127.0.0.1:8000/admin/dashboard)- notice the ‘generating’ comment against the gemma model

Links

See this to get started with gas-fakes.

GitHub: gas-fakes

Bringing Apps Script to the desktop – the why, where and how of gas-fakes

Bruce Mcpherson — Wed, 03 Jun 2026 13:20:05 +0000

A brief summary on approaching parity of Google Apps Script methods and classes, some of the 'extras' gas-fakes provides for platform variety, production, development and testing and glimpse of some of the techniques used to get there.

Introduction: The Challenge of the Scripting Layer

Google Apps Script (GAS) is a powerful tool for extending Google Workspace, automating workflows, and building lightweight backend services. It excels at rapid prototyping and integration within the Google ecosystem. However the limitations of the GAS environment (its proprietary runtime, laborious deployment cycle, and lack of modern tooling and debugging) become significant bottlenecks.

We love the power and integration of GAS, but we require the debuggability and flexibility of a modern Node.js environment.

This is the problem that gas-fakes is designed to address.

gas-fakes is an architectural emulation layer designed to bring the entire GAS runtime experience (its APIs, its behaviors, and its constraints) into a robust, controllable Node.js environment. It allows developers to write GAS-like code while leveraging the full power of modern software engineering practices.

1. The Path to Parity: Emulating the GAS Runtime

The core challenge in building gas-fakes is the fundamental mismatch between the GAS execution model and the Node.js event loop. GAS is inherently asynchronous, relying on a managed, proprietary execution environment. Node.js, is designed for high-throughput, asynchronous execution and non-blocking I/O.

Our architectural approach to achieving parity focuses on accurate API simulation and execution model transformation.

The API Contract: Discovery Documents and REST

The foundation of GAS is its reliance on Google's ecosystem of REST APIs, exposed through its own managed runtime. We've mapped the exact schema, parameters, and expected responses of every GAS service (e.g., SpreadsheetApp, GmailApp). This allows gas-fakes to treat the GAS environment as a highly structured, predictable API contract.

The Execution Model: Synchronous Emulation via Worker Threads

The most complex hurdle is the transformation of GAS's asynchronous API calls (which often feel synchronous to the developer) into a predictable, synchronous-feeling flow within Node.js.

We achieve this by employing Worker Threads and Atomics.

Worker Isolation: When a GAS method is called (e.g., SpreadsheetApp.getActiveSpreadsheet().getRange().getValue()), the request is routed to a dedicated Worker Thread. This isolates the simulated GAS execution from the main Node.js event loop, preventing blocking while maintaining the illusion of synchronous execution.
Asynchronous-to-Synchronous Bridge: The Worker Thread executes the simulated API call. Instead of returning a standard Promise, we use Atomics to manage shared memory state between the Worker and the main thread. This allows the main thread to effectively "wait" for the combined result from the Worker, mimicking the blocking behavior of the original GAS runtime, while allowing the worker to execute multiple asynchronous activities.

The Importance of Behavioral Oddities

A perfect API contract is insufficient. GAS has numerous subtle, undocumented behaviors such as rate limiting quirks, specific error codes, divergences from the associated API behavior, ID transformations, and timing dependencies that need to be understood and emulated for true parity.

A significant part of the gas-fakes development process is the meticulous documentation and reproduction of these behavioral oddities. We don't just emulate the happy path; we emulate the edge cases and the developer experience of the live GAS environment, ensuring that code written in gas-fakes behaves identically to how it would in production.

🧪 Rigorous Testing Regime: `gas-fakes` fidelity assurance

To validate the claim of behavioral parity, gas-fakes operates under a massive, dual-environment testing regime. We maintain a comprehensive suite of over 10,500 tests (as of version 2.5.3) that are executed across two distinct environments:

The Local gas-fakes Emulator: This allows for rapid, isolated unit and integration testing of the simulated runtime, ensuring the internal logic and API contracts are sound.
The Live Google Apps Script Environment: Crucially, every test suite is also executed against the actual, live GAS runtime.

This dual-environment verification ensures that the emulation is not merely "close," but behaviorally identical to production GAS, including the precise handling of complex error states, rate limiting, and obscure edge cases that only manifest in the live Google ecosystem.

2. Transparency and Auditing: The Documentation Layer

Beyond achieving functional parity, gas-fakes is engineered with a core commitment to engineering transparency. We recognize that for enterprise adoption, developers require not just a working emulator, but a fully auditable and self-documenting environment.

To address this, we have built a sophisticated documentation layer that provides unprecedented visibility into the emulation process.

📚 Embedded API Documentation

The repository includes a locally accessible and searchable version of the official Google Apps Script documentation. This documentation is integrated directly into the development environment, allowing developers to reference precise API definitions, parameter types, and expected behaviors without needing to switch context or leave their local codebase. This eliminates the friction of external documentation lookups, accelerating the development cycle while maintaining technical accuracy.

📊 Fidelity Progress Summary

To manage the monumental task of API parity, we provide an automated Fidelity Progress Summary. This system offers a clear, high-level overview of the implementation status for every class and method across all supported services. Developers can instantly see whether a specific function is Completed, In Progress, or Not Started, providing a transparent roadmap of the emulation effort and allowing them to gauge the maturity of the API they are using.

As of version 2.5.3, 4399 of Apps Scripts total of 6708 are implemented.

🔍 Deep Implementation Links: The Audit Trail

A unique feature of gas-fakes is deep implementation transparency. The documentation includes direct, clickable links to the exact line of source code where every single method is implemented within the emulator. This feature allows for instant verification and auditing of the emulation logic. If a developer questions the behavior of SpreadsheetApp.getRange(), they can instantly trace the call through the documentation to the specific line of code in gas-fakes that dictates its behavior, providing a high level of trust and debuggability.

3. Beyond Parity: The gas-fakes Advantage

While achieving parity is a huge task, another value of gas-fakes lies in the capabilities it enables. Capabilities that are fundamentally impossible or prohibitively difficult within the constraints of the live Google Apps Script environment. This includes the elimination of theat troublesome 6 minute execution time limit on Live Apps Script.

gas-fakes transforms the Apps Script language into a modern application development platform by separating its syntax from the place it traditionally runs.

🚀 GAS Syntax for Regular Node Apps: Simplified Workspace Access

A transformative features of gas-fakes is its ability to inject the familiar, high-level syntax of Google Apps Script directly into a standard Node.js runtime.

Even if you have no intention of ever deploying to Google Apps Script, you can use the simple, intuitive GAS syntax (e.g., SpreadsheetApp, DriveApp) in your regular Node.js apps. This provides a much simpler interface for accessing Workspace resources compared to the complex, low-level parameters of the raw REST APIs. It reduces cognitive load, improves maintainability, and abstracts away the complexity of OAuth scopes and request formatting.

🔑 Auth Provisioning & Token Reuse: A Unified Credential Manager

Managing authentication tokens across multiple services is an operational burden. gas-fakes auth acts as a powerful, centralized credential manager. It provisions OAuth tokens for multiple backends (Google, KSuite, MS Graph) scoped to your provided manifest which can then be easily retrieved and reused by other parts of your Node application or even by separate CLI tools. This creates a streamlined, single source of truth for credentials.

☁️ Containerization and Multi-Cloud Deployment

The entire GAS runtime emulation can be packaged using Docker. This allows developers to deploy and run GAS-like logic in modern, serverless, and scalable multi-cloud environments. By leveraging the container image, gas-fakes is fully compatible with leading cloud platforms, including:

Google Cloud Run, Azure Container Apps, AWS Lambda, IBM Cloud, and Kubernetes.

This capability fundamentally breaks the vendor lock-in associated with proprietary GAS deployment, allowing the same business logic to be executed in any serverless or containerized architecture.

🚀 CLI Workflow and Initialization

While the core functionality of gas-fakes provides a local execution environment, the initial setup and integration with live cloud services are handled through a streamlined Command Line Interface (CLI). This workflow is designed to minimize friction, automate complex configuration tasks, and ensure that your local testing environment perfectly mirrors the permissions and dependencies of your production Apps Script project.

🛠️ Streamlined Project Setup (`gas-fakes init`)

The gas-fakes init command serves as the foundational step for any new project. It automates the tedious process of environment configuration, allowing developers to focus immediately on coding. It automatically generates a local .env file, which securely stores necessary configuration variables and prompts the user to select the target cloud backends (e.g., Google Workspace, KSuite, MS Graph).

🔑 Authentication and Token Management (`gas-fakes auth`)

Connecting a local environment to live cloud services requires managing complex OAuth flows and token lifecycles. The gas-fakes auth command abstracts this complexity, providing a robust mechanism for secure, persistent authentication across all supported backends. It handles initial authorization guiding the user through browser redirects and manages secure token storage and refresh logic.

🔬 Automatic Scope Discovery: Precision Permissions

The CLI automatically reads the appsscript.json manifest file from your project. By parsing this file, gas-fakes automatically infers and registers the exact OAuth scopes necessary for local execution. This ensures that your local environment is provisioned with the precise permissions required by the live project, guaranteeing parity without requiring developers to manually track or update scope lists.

gas-fakes even supports existing published Apps Script libraries. If they are mentioned in your manifest, they can be accessed remotely from live Apps Script and executed locally.

🚀 Local Web Server and RPC Testing

In live GAS, testing a Web App requires deployment and a live URL. In gas-fakes, you can use its cli to instantiate the entire GAS environment locally, deploy your code to a simulated endpoint, and test complex google.script.run interactions and HTML Service templating with full local debugging tools without the need for any actual deployments. This accelerates the development feedback loop, with code changes showing up live in your local environment.

🌐 Multi-Backend Architecture

Live GAS is tightly coupled to Google services. gas-fakes decouples the business logic from the data source. By simply switching a configuration property, your GAS-like code can run against Google Services, KSuite, or MS Graph. This enables hybrid architectures and sovereign cloud, with increased parity for non-Google backends currently being prioritized.

🧠 The Automation Layer: CLI, `gf_agent`, and `togas`

While the sandbox provides the secure environment, the gas-fakes CLI and the specialized gf_agent provide the intelligence and accessibility needed for modern automation.

The CLI: A robust command-line tool for running scripts, starting local servers, and managing the sandbox.
gf_agent: This AI-powered companion acts as a translator, bridging the gap between natural language intent and executable code. For example, a request like "Summarize my last 5 emails and put them in a new spreadsheet" is instantly converted into optimized Apps Script and executed by your AI agent. This is a self learning skills agaent which can both enhance its own knowledge, and optionally contribute towards community skills.
togas & Clasp Integration: The togas command acts as a high-level orchestrator for deployment. It automates the process of bundling and synchronizing local files with a live GAS project. It builds upon and enhances the core functionality of clasp, providing a streamlined local-to-cloud workflow and making the necessary adjustments to local 'Node specific' ES syntax.
Sandbox-Agent Synergy: This combination enables safe, instant Workspace automation. The agent handles the what, and the sandbox ensures the how, guaranteeing that code only touches whitelisted resources without the overhead of building complex specialized agents or MCP servers.

🛠️ Modern Tooling and Developer Experience

A big pain point for GAS developers is the lack of modern tooling. gas-fakes eliminates this by providing a full Node.js development stack:

NPM Ecosystem: Utilize any modern NPM package, allowing access to thousands of specialized libraries.
Advanced Debugging: Leverage industry-standard Node.js debuggers (e.g., VS Code, AntiGravity) to step through code, inspect variables, and trace execution paths—a luxury unavailable in the GAS runtime—while simultaneously inspecting client-side HTML Service code in the Chrome debugger in its original structure, line numberings and format.

🛡️ Granular Sandbox and Security

The live GAS environment offers a broad permission model. gas-fakes provides a fine-grained, developer-controlled sandbox:

File-Level Whitelisting: Define exactly which files or modules the script is allowed to access.
Service-Level Permission Controls: Explicitly define which simulated services (e.g., GmailApp, DriveApp) the script is permitted to call, allowing for highly secure, auditable execution environments.

This optional level of granularity gives protection against Vibe coding hallucination.

🔗 Hybrid Interoperability: Bridging Local and Live

You often need to maintain state across environments. gas-fakes supports Hybrid Interoperability.

By integrating with external services like Redis or Upstash, gas-fakes allows the local development environment to share cache data, properties, and session state with the live, deployed GAS instance. This means your local tests are not isolated; they are running against a realistic, persistent state, ensuring seamless transition from development to production. We provide a drop-in replacement property and cache service library for live Apps Script, so you can share exactly the same stores between your local environment and the live deployed GAS.

Conclusion: Apps Script as a 'Lingua Franca'

gas-fakes elevates Apps Script, a powerful yet constrained scripting language, to the level of a modern, maintainable, and scalable application framework—a lingua franca for Google Workspace integration. It allows teams to write the code they know, test it with the fidelity they require, and deploy it with the control they deserve.

We are not just emulating GAS; we are liberating it.

Links

This full article
This repo

Run Apps Script on an Office 365 back end with gas-fakes

Bruce Mcpherson — Mon, 16 Mar 2026 14:41:35 +0000

gas-fakes emulates the Google Apps Script (GAS) environment natively within a Node.js runtime. By translating standard GAS service calls into granular API requests, it provides a high-fidelity, local sandbox for debugging, automated testing, and execution without the constraints of the Google Cloud IDE.

Microsoft as an Apps Script backend

Apps Script: A ‘Lingua Franca’ for the Multi-Cloud Era introduces the concept of replacing Apps Script's regular Workspace backend with ksuite. You write Apps Script code as normal, but behind the scenes gas-fakes translates the code into ksuite API requests.

I’m now adding the Microsoft Graph (Msgraph) backend. This represents a strategic evolution for the project. This addition allows developers to apply the familiar Apps Script programming model directly to the Microsoft 365 ecosystem.

By acting as a “lingua franca” for workspace platforms, gas-fakes enables you to treat the underlying productivity suite as a pluggable component.

This allows for the maintenance of a single business logic codebase that can target both Google Workspace and Microsoft 365.

Configuring the Microsoft Graph Backend

As usual, handling auth is the trickiest part of all this. However, the gas-fakes cli handles initializing and authentication against Azure to allow access to Msgraph. Just provide a normal apps script manifest that contains all the scopes you want to use.

gas-fakes init and auth will handle setting up the necessary app registration (this is similar to the Google Service Account). Access delegation is a little like Google domain wide delegation (DWD).

gas-fakes automatically translates the google oauthScopes section in your manifest into their Azure equivalents.

Initializing the platforms you ever want to use

Simply list the backends you want to be able to use in the init phase. The default is of course just “google”.

For this example, we want Apps Script to be able to access all 3 supported backends from the same project. You need az (the azure cli ) and gcloud (the google cli) installed.

gas-fakes init -b "google,msgraph,ksuite"

This will ask a series of questions and create any required registrations and service accounts, and create variables in your selected .env file

Authing the platform your project want to use

The auth phase will read the information you provided in the init phase, and execute the selected auth process for the selected back end platforms.

gas-fakes auth -b "msgraph,google"

This will set any permissions and scopes on the service accounts and registrations.

Keyless auth

In both google and microsoft, the authentication processes are ‘keyless’ – meaning gas-fakes doesn’t store service account credentials locally.

With Google, you have the choice of Application Default Credential (–auth-type adc) or the default domain wide delegation (the default –-auth-type dwd).

Microsoft is a kind of hybrid. Caveat: there are many variations depending on whether you have a SPO license, and using a business or consumer license. There are additional complications around multi tenants and other weird things.

I don’t have any of those. So I have only been able at this time to test the consumer account track in the auth process. This means you may get an occassional consent screen popping up occassionally even after the auth stage as the consumer track does not fully support delegation in the way that google does.

Development Experience

When targeting the msgraph backend, gas-fakes maps familiar GAS-style service synchronous calls to the Microsoft Graph API. You can now target OneDrive and Excel data without bothering to learn the nuances of the Microsoft Graph SDK.

Because the environment emulates the global GAS objects, the same code to process a Google Sheet can be applied to an Excel workbook on OneDrive without modification.

At the time of writing , I’ve only implemented a subset of the msgraph methods for OneDrive and Excel. I’ll add more over time.

Example: recursively list the entire contents of multiple platforms

Here’s an example app showing how you can combine platforms using the same Apps Script code. Here we are recursively list all the files in Drive, OneDrive and Ksuite

import '@mcpher/gas-fakes'

// run explore on each platform
const dual = () => {
  ScriptApp.__platform = 'msgraph'
  const rootFolder0 = DriveApp.getRootFolder()
  console.log('--- msgraph Recursive Explorer ---')
  explore(rootFolder0)

  ScriptApp.__platform = 'ksuite'
  const rootFolder = DriveApp.getRootFolder()
  console.log('--- KSuite Recursive Explorer ---')
  explore(rootFolder)

  ScriptApp.__platform = 'google'
  const rootFolder2 = DriveApp.getRootFolder()
  console.log('--- Google Workspace Recursive Explorer ---')
  explore(rootFolder2)

}

const explore = (folder, depth = 0) => {
  const indent = ' '.repeat(depth)
  console.log(`${indent}FOLDER: ${folder.getName()} (ID: ${folder.getId()})`)

// Show files in this folder
  const files = folder.getFiles()
  while (files.hasNext()) {
    const file = files.next()
    console.log(`${indent} FILE: ${file.getName()} (ID: ${file.getId()})`)
  }

  // Drill into subfolders
  const folders = folder.getFolders()
  while (folders.hasNext()) {
    explore(folders.next(), depth + 1)
  }
}

dual ()

Example: copying folder contents between platforms

Here we use the same code to copy all the files in a given folder between various combinations of platforms, and validate that each file content has been successfully written

import '@mcpher/gas-fakes'

const demoTransfer = () => {
  // copy the files from ksuite
  copyFiles({
    sourcePlatform: 'ksuite',
    targetPlatform: 'google',
    sourceFolderName: 'gas-fakes-assets',
    targetFolderName: 'from-ksuite-to-google'
  })

  // and back again
  copyFiles({
    sourcePlatform: 'google',
    targetPlatform: 'ksuite',
    sourceFolderName: 'from-ksuite-to-google',
    targetFolderName: 'from-google-to-ksuite'
  })

  // now copy them from google to ms-graph
  copyFiles({
    sourcePlatform: 'google',
    targetPlatform: 'msgraph',
    sourceFolderName: 'from-ksuite-to-google',
    targetFolderName: 'from-google-to-ms-graph'
  })

  // and back again
  copyFiles({
    sourcePlatform: 'msgraph',
    targetPlatform: 'ksuite',
    sourceFolderName: 'from-google-to-ms-graph',
    targetFolderName: 'from-ms-graph-to-ksuite'
  })

  // check that the final files in ksuite match the original
  const sourceBlobs = getBlobs({
    sourcePlatform: 'ksuite',
    sourceFolderName: 'gas-fakes-assets'
  })
  const finalBlobs = getBlobs({
    sourcePlatform: 'ksuite',
    sourceFolderName: 'from-ms-graph-to-ksuite'
  })

  // check blobs by checking their digest
  if (sourceBlobs.length !== finalBlobs.length) {
    throw new Error(`expected ${sourceBlobs.length} blobs but got ${finalBlobs.length}`)
  }

  sourceBlobs.forEach((b, i) => {
    const sourceDigest = Utilities.base64Encode(Utilities.computeDigest(Utilities.DigestAlgorithm.MD5, b.getBytes()))
    const finalDigest = Utilities.base64Encode(Utilities.computeDigest(Utilities.DigestAlgorithm.MD5, finalBlobs[i].getBytes()))

    if (sourceDigest !== finalDigest) {
      console.log(`${b.getName()} blob mismatch with ${finalBlobs[i].getName()}`)
    }
  })
}

const getBlobs = ({ sourcePlatform, sourceFolderName }) => {
  // set which platform to use
  ScriptApp.__platform = sourcePlatform
  const sourceFolders = DriveApp.getFoldersByName(sourceFolderName)

  if (!sourceFolders.hasNext()) {
    throw new Error(`Source folder ${sourceFolderName} not found`)
  }

  // get the files in that source folder
  const files = sourceFolders.next().getFiles()
  const blobsToCopy = []
  while (files.hasNext()) {
    const file = files.next()
    blobsToCopy.push(file.getBlob())
  }
  return blobsToCopy
}

const copyFiles = ({ sourcePlatform, targetPlatform, sourceFolderName, targetFolderName }) => {
  const blobsToCopy = getBlobs({ sourcePlatform, sourceFolderName })

  // now use an alternative platform
  ScriptApp.__platform = targetPlatform

  // create the folder if it doesn't exist
  const targetFolders = DriveApp.getFoldersByName(targetFolderName)
  let targetFolder = targetFolders.hasNext() 
    ? targetFolders.next() 
    : DriveApp.createFolder(targetFolderName)

  // now copy the blobs to the target folder
  blobsToCopy.forEach(blob => {
    targetFolder.createFile(blob)
  })
  return blobsToCopy
}

demoTransfer()

Advanced Feature: Leveraging Native Apps Script Libraries

gas-fakes further bridges the platform gap by allowing the execution of native Apps Script libraries within the Node.js emulation layer. gas-fakes manages the loading and execution of external library dependencies. Any libraries mentioned in your Apps Script manifest will be loaded and available.

Example 3: Using a live apps script library across platforms

In this case, we’ll use the bmPreFiddler library to manipulate sheet contents in both platforms. Again we are leveraging gas-fakes sandbox to both clean up and limit access to intended files.

import '@mcpher/gas-fakes'

/**
 * Creates a spreadsheet on the specified platform.
 * @param {Object} params
 * @param {string} params.platform - The target platform (e.g., 'google', 'msgraph').
 * @param {string} params.title - The name of the new spreadsheet.
 */
const createSpreadsheet = ({ platform = "google", title }) => {
  ScriptApp.__platform = platform
  const ss = SpreadsheetApp.create(title)
  console.log(`Created spreadsheet ${ss.getName()} on ${platform}`)
  return ss
}

/**
 * Sets the active platform for ScriptApp.
 */
const setPlatform = (name) => ScriptApp.__platform = name

/**
 * Copies a sheet's data between two platforms and verifies the result.
 * @param {Object} params
 * @param {Object} params.source - Source details {platform, id, sheetName}.
 * @param {Object} params.target - Target details {platform, title}.
 */
const copySheetBetweenPlatforms = ({ source, target }) => {
  // Get a fiddler for the source
  setPlatform(source.platform)
  const fiddler = bmPreFiddler.PreFiddler().getFiddler(source)

  // Create the output spreadsheet on the target platform
  setPlatform(target.platform)
  const dst = createSpreadsheet(target)

  // Get a fiddler for the destination
  const dstFiddler = bmPreFiddler.PreFiddler().getFiddler({
    id: dst.getId(),
    sheetName: source.sheetName,
    createIfMissing: true
  })

  // Copy the data and dump to target
  dstFiddler.setData(fiddler.getData()).dumpValues()

  // Verify that both sheets match using fingerprints
  const after = bmPreFiddler.PreFiddler().getFiddler({
    id: dstFiddler.getSheet().getParent().getId(),
    sheetName: dstFiddler.getSheet().getName()
  })

  if (after.fingerPrint === fiddler.fingerPrint) {
    console.log('Bingo: Data matches perfectly')
  } else {
    console.log('Error: Data fingerprint mismatch')
  }
}


// load any libraries
LibHandlerApp.load()

// enable sandbox mode
ScriptApp.__behavior.sandBoxMode = true;

// create some spreadsheets with data and copy between them
const source = {
  id: "1h9IGIShgVBVUrUjjawk5MaCEQte_7t32XeEP1Z5jXKQ",
  platform: "google",
  sheetName: 'airport list'
}

// add that to sanbox for read without marking it for trashing
ScriptApp.__behavior.whitelistFile(source.id)

copySheetBetweenPlatforms({ source, target: {platform: 'msgraph', title: 'test-msgraph-libraries'}})

// cleanup any files created
ScriptApp.__behavior.trash()

Help us develop gas-fakes

gas-fakes is an open-source project. We encourage developers to collaborate, contribute to the extension of supported services, and help refine this bridge between the world’s most popular workspace platforms.

This would be especially helpful if you have Microsoft knowledge and would like to help develop the msgraph connection. Ping me on bruce@mcpher.com if you want to get involved.

Links

GitHub: gas-fakes
GitHub: gas-fakes-containers
More gas-fakes articles: desktop liberation

What is `gas-fakes`

gas-fakes is a powerful emulation layer that lets you run Apps Script projects on Node.js as if they were native. By translating GAS service calls into granular Google API requests, it provides a secure, high-speed sandbox for local debugging and automated testing.

Built for the modern stack, it features plug-and-play containerization—allowing you to package your scripts as portable microservices or isolated workers. Coupled with automated identity management, gas-fakes handles the heavy lifting of OAuth and credential cycling, enabling your scripts to act on behalf of users or service accounts without manual intervention. It’s the missing link for building robust, scalable Google Workspace automations and AI-driven workflows.

Watch the video

Yes – you can execute native Apps Script with Office 365 back end

Bruce Mcpherson — Mon, 16 Mar 2026 14:32:32 +0000

Microsoft as an Apps Script backend

By acting as a “lingua franca” for workspace platforms, gas-fakes enables you to treat the underlying productivity suite as a pluggable component.

This allows for the maintenance of a single business logic codebase that can target both Google Workspace and Microsoft 365.

Configuring the Microsoft Graph Backend

gas-fakes automatically translates the google oauthScopes section in your manifest into their Azure equivalents.

Initializing the platforms you ever want to use

Simply list the backends you want to be able to use in the init phase. The default is of course just “google”.

For this example, we want Apps Script to be able to access all 3 supported backends from the same project. You need az (the azure cli ) and gcloud (the google cli) installed.

gas-fakes init -b "google,msgraph,ksuite"

This will ask a series of questions and create any required registrations and service accounts, and create variables in your selected .env file

Authing the platform your project want to use

The auth phase will read the information you provided in the init phase, and execute the selected auth process for the selected back end platforms.

gas-fakes auth -b "msgraph,google"

This will set any permissions and scopes on the service accounts and registrations.

Keyless auth

In both google and microsoft, the authentication processes are ‘keyless’ – meaning gas-fakes doesn’t store service account credentials locally.

With Google, you have the choice of Application Default Credential (–auth-type adc) or the default domain wide delegation (the default –-auth-type dwd).

Development Experience

Because the environment emulates the global GAS objects, the same code to process a Google Sheet can be applied to an Excel workbook on OneDrive without modification.

At the time of writing , I’ve only implemented a subset of the msgraph methods for OneDrive and Excel. I’ll add more over time.

Example: recursively list the entire contents of multiple platforms

Here’s an example app showing how you can combine platforms using the same Apps Script code. Here we are recursively list all the files in Drive, OneDrive and Ksuite

import '@mcpher/gas-fakes'

// run explore on each platform
const dual = () => {
  ScriptApp.__platform = 'msgraph'
  const rootFolder0 = DriveApp.getRootFolder()
  console.log('--- msgraph Recursive Explorer ---')
  explore(rootFolder0)

  ScriptApp.__platform = 'ksuite'
  const rootFolder = DriveApp.getRootFolder()
  console.log('--- KSuite Recursive Explorer ---')
  explore(rootFolder)

  ScriptApp.__platform = 'google'
  const rootFolder2 = DriveApp.getRootFolder()
  console.log('--- Google Workspace Recursive Explorer ---')
  explore(rootFolder2)

}

const explore = (folder, depth = 0) => {
  const indent = ' '.repeat(depth)
  console.log(`${indent}FOLDER: ${folder.getName()} (ID: ${folder.getId()})`)

// Show files in this folder
  const files = folder.getFiles()
  while (files.hasNext()) {
    const file = files.next()
    console.log(`${indent} FILE: ${file.getName()} (ID: ${file.getId()})`)
  }

  // Drill into subfolders
  const folders = folder.getFolders()
  while (folders.hasNext()) {
    explore(folders.next(), depth + 1)
  }
}

dual ()

Example: copying folder contents between platforms

Here we use the same code to copy all the files in a given folder between various combinations of platforms, and validate that each file content has been successfully written

import '@mcpher/gas-fakes'

const demoTransfer = () => {
  // copy the files from ksuite
  copyFiles({
    sourcePlatform: 'ksuite',
    targetPlatform: 'google',
    sourceFolderName: 'gas-fakes-assets',
    targetFolderName: 'from-ksuite-to-google'
  })

  // and back again
  copyFiles({
    sourcePlatform: 'google',
    targetPlatform: 'ksuite',
    sourceFolderName: 'from-ksuite-to-google',
    targetFolderName: 'from-google-to-ksuite'
  })

  // now copy them from google to ms-graph
  copyFiles({
    sourcePlatform: 'google',
    targetPlatform: 'msgraph',
    sourceFolderName: 'from-ksuite-to-google',
    targetFolderName: 'from-google-to-ms-graph'
  })

  // and back again
  copyFiles({
    sourcePlatform: 'msgraph',
    targetPlatform: 'ksuite',
    sourceFolderName: 'from-google-to-ms-graph',
    targetFolderName: 'from-ms-graph-to-ksuite'
  })

  // check that the final files in ksuite match the original
  const sourceBlobs = getBlobs({
    sourcePlatform: 'ksuite',
    sourceFolderName: 'gas-fakes-assets'
  })
  const finalBlobs = getBlobs({
    sourcePlatform: 'ksuite',
    sourceFolderName: 'from-ms-graph-to-ksuite'
  })

  // check blobs by checking their digest
  if (sourceBlobs.length !== finalBlobs.length) {
    throw new Error(`expected ${sourceBlobs.length} blobs but got ${finalBlobs.length}`)
  }

  sourceBlobs.forEach((b, i) => {
    const sourceDigest = Utilities.base64Encode(Utilities.computeDigest(Utilities.DigestAlgorithm.MD5, b.getBytes()))
    const finalDigest = Utilities.base64Encode(Utilities.computeDigest(Utilities.DigestAlgorithm.MD5, finalBlobs[i].getBytes()))

    if (sourceDigest !== finalDigest) {
      console.log(`${b.getName()} blob mismatch with ${finalBlobs[i].getName()}`)
    }
  })
}

const getBlobs = ({ sourcePlatform, sourceFolderName }) => {
  // set which platform to use
  ScriptApp.__platform = sourcePlatform
  const sourceFolders = DriveApp.getFoldersByName(sourceFolderName)

  if (!sourceFolders.hasNext()) {
    throw new Error(`Source folder ${sourceFolderName} not found`)
  }

  // get the files in that source folder
  const files = sourceFolders.next().getFiles()
  const blobsToCopy = []
  while (files.hasNext()) {
    const file = files.next()
    blobsToCopy.push(file.getBlob())
  }
  return blobsToCopy
}

const copyFiles = ({ sourcePlatform, targetPlatform, sourceFolderName, targetFolderName }) => {
  const blobsToCopy = getBlobs({ sourcePlatform, sourceFolderName })

  // now use an alternative platform
  ScriptApp.__platform = targetPlatform

  // create the folder if it doesn't exist
  const targetFolders = DriveApp.getFoldersByName(targetFolderName)
  let targetFolder = targetFolders.hasNext() 
    ? targetFolders.next() 
    : DriveApp.createFolder(targetFolderName)

  // now copy the blobs to the target folder
  blobsToCopy.forEach(blob => {
    targetFolder.createFile(blob)
  })
  return blobsToCopy
}

demoTransfer()

Advanced Feature: Leveraging Native Apps Script Libraries

Example 3: Using a live apps script library across platforms

In this case, we’ll use the bmPreFiddler library to manipulate sheet contents in both platforms. Again we are leveraging gas-fakes sandbox to both clean up and limit access to intended files.

import '@mcpher/gas-fakes'

/**
 * Creates a spreadsheet on the specified platform.
 * @param {Object} params
 * @param {string} params.platform - The target platform (e.g., 'google', 'msgraph').
 * @param {string} params.title - The name of the new spreadsheet.
 */
const createSpreadsheet = ({ platform = "google", title }) => {
  ScriptApp.__platform = platform
  const ss = SpreadsheetApp.create(title)
  console.log(`Created spreadsheet ${ss.getName()} on ${platform}`)
  return ss
}

/**
 * Sets the active platform for ScriptApp.
 */
const setPlatform = (name) => ScriptApp.__platform = name

/**
 * Copies a sheet's data between two platforms and verifies the result.
 * @param {Object} params
 * @param {Object} params.source - Source details {platform, id, sheetName}.
 * @param {Object} params.target - Target details {platform, title}.
 */
const copySheetBetweenPlatforms = ({ source, target }) => {
  // Get a fiddler for the source
  setPlatform(source.platform)
  const fiddler = bmPreFiddler.PreFiddler().getFiddler(source)

  // Create the output spreadsheet on the target platform
  setPlatform(target.platform)
  const dst = createSpreadsheet(target)

  // Get a fiddler for the destination
  const dstFiddler = bmPreFiddler.PreFiddler().getFiddler({
    id: dst.getId(),
    sheetName: source.sheetName,
    createIfMissing: true
  })

  // Copy the data and dump to target
  dstFiddler.setData(fiddler.getData()).dumpValues()

  // Verify that both sheets match using fingerprints
  const after = bmPreFiddler.PreFiddler().getFiddler({
    id: dstFiddler.getSheet().getParent().getId(),
    sheetName: dstFiddler.getSheet().getName()
  })

  if (after.fingerPrint === fiddler.fingerPrint) {
    console.log('Bingo: Data matches perfectly')
  } else {
    console.log('Error: Data fingerprint mismatch')
  }
}

// load any libraries
LibHandlerApp.load()

// enable sandbox mode
ScriptApp.__behavior.sandBoxMode = true;

// create some spreadsheets with data and copy between them
const source = {
  id: "1h9IGIShgVBVUrUjjawk5MaCEQte_7t32XeEP1Z5jXKQ",
  platform: "google",
  sheetName: 'airport list'
}

// add that to sanbox for read without marking it for trashing
ScriptApp.__behavior.whitelistFile(source.id)

copySheetBetweenPlatforms({ source, target: {platform: 'msgraph', title: 'test-msgraph-libraries'}})

// cleanup any files created
ScriptApp.__behavior.trash()

Help us develop gas-fakes

This would be especially helpful if you have Microsoft knowledge and would like to help develop the msgraph connection. Ping me on bruce@mcpher.com if you want to get involved.

Links

GitHub: gas-fakes
GitHub: gas-fakes-containers
More gas-fakes articles: desktop liberation

DEV Community: Bruce Mcpherson

From Kubernetes to a Self-Healing, Low-Cost Infrastructure

Managed instance group

Decoupling Compute from State

The Autonomous Recovery Workflow

Operational States: Preemption vs. Scaling Down

Comparing Infrastructure Models

Docker-compose benefit

Replacing the Kubernetes Ingress

Some example scripts

Your startup script (startup-script.sh)

Create a managed group template

Create a managed group (create-mig.sh)

Ssh to your instance (ssh.sh)

Simulate a pre-emption to test (simulate-preemption.sh)

Bring up the VM (up-mig.sh)

links

Combining local and hosted llm to minimize token cost

Evaluation of the repo content.

Executive Summary & Core Metrics

💎 Overall Project Score: 94/100 (Enterprise Grade / Production Dev Tool)

Gemini Directive & Hybrid Planned Hierarchy

The Roles

The Delegation Mechanism (query_local_model)

Operational Constraints (The Golden Rule)

Implementation & Focused Execution (CRITICAL DELEGATION GATE)

Cost and Token Savings

oMLX Setup and Documentation

Overview: What is oMLX?

Setup and Configuration

The oMLX MCP Server

Configuration Methods

Validating that AntiGravity is using the local server

Links

Bringing Apps Script to the desktop – the why, where and how of gas-fakes

Introduction: The Challenge of the Scripting Layer

1. The Path to Parity: Emulating the GAS Runtime

The API Contract: Discovery Documents and REST

The Execution Model: Synchronous Emulation via Worker Threads

The Importance of Behavioral Oddities

🧪 Rigorous Testing Regime: gas-fakes fidelity assurance

2. Transparency and Auditing: The Documentation Layer

📚 Embedded API Documentation

📊 Fidelity Progress Summary

🔍 Deep Implementation Links: The Audit Trail

3. Beyond Parity: The gas-fakes Advantage

🚀 GAS Syntax for Regular Node Apps: Simplified Workspace Access

🔑 Auth Provisioning & Token Reuse: A Unified Credential Manager

☁️ Containerization and Multi-Cloud Deployment

🚀 CLI Workflow and Initialization

🛠️ Streamlined Project Setup (gas-fakes init)

🔑 Authentication and Token Management (gas-fakes auth)

🔬 Automatic Scope Discovery: Precision Permissions

🚀 Local Web Server and RPC Testing

🌐 Multi-Backend Architecture

🧠 The Automation Layer: CLI, gf_agent, and togas

🛠️ Modern Tooling and Developer Experience

🛡️ Granular Sandbox and Security

🔗 Hybrid Interoperability: Bridging Local and Live

Conclusion: Apps Script as a 'Lingua Franca'

Run Apps Script on an Office 365 back end with gas-fakes

Microsoft as an Apps Script backend

Configuring the Microsoft Graph Backend

Initializing the platforms you ever want to use

Authing the platform your project want to use

Keyless auth

Development Experience

Example: recursively list the entire contents of multiple platforms

Example: copying folder contents between platforms

Advanced Feature: Leveraging Native Apps Script Libraries

Example 3: Using a live apps script library across platforms

Help us develop gas-fakes

Links

What is gas-fakes

Watch the video

Yes – you can execute native Apps Script with Office 365 back end

Microsoft as an Apps Script backend

Configuring the Microsoft Graph Backend

Initializing the platforms you ever want to use

Authing the platform your project want to use

🧪 Rigorous Testing Regime: `gas-fakes` fidelity assurance

🛠️ Streamlined Project Setup (`gas-fakes init`)

🔑 Authentication and Token Management (`gas-fakes auth`)

🧠 The Automation Layer: CLI, `gf_agent`, and `togas`

What is `gas-fakes`

What is `gas-fakes`