How Cloud Run gVisor sandboxes bring isolated Python and Bash to Apps Script

A sandbox sidecar for Workspace automations

A tutorial published on dev.to details how to wire Google Apps Script into Google Cloud Run Sandboxes, giving Workspace automations a fast, isolated place to run Python and Bash code. According to the author, dynamic scripts execute in 200 to 450 milliseconds inside gVisor-isolated containers, and the deployment costs nothing while idle.

The motivation is a set of long-standing Apps Script constraints. Standard accounts are capped at a six-minute runtime, the environment runs only JavaScript on V8 — ruling out native Linux binaries and external compilers — and a single unhandled exception stops the whole script.

The gap between V8 and LLM agents

The author positions the setup as a middle ground between two existing options. Plain Apps Script is too limited for scientific computing or shell work. At the other extreme, a previous article by the same author connected Apps Script to Linux sandboxes provisioned by Gemini Managed Agents, which handle heavy multi-turn workflows such as Playwright scraping and FFmpeg transcoding.

That agent-based route depends on LLM prompts through the Interactions API, which the article says pushes response times to seconds or tens of seconds and burns token quotas (the author cites a 200k TPM figure). Many everyday tasks — arithmetic evaluation, string parsing, regex matching, shell commands — are deterministic and gain nothing from an LLM in the loop. The article credits Romin Irani's hands-on guide to Cloud Run Sandboxes as the spark for building a direct, non-LLM execution path instead.

Three layers, one HTTP call

The architecture has three components: the Apps Script orchestrator, a FastAPI proxy runner on second-generation Cloud Run instances, and the gVisor isolation layer.

Execution runs in three stages. Apps Script first sends an HTTPS POST with a JSON payload containing the code snippet, the language (Python or Bash), a timeout, and security override flags. The FastAPI service then invokes the sandbox launcher with a sandbox do command, capturing wall-clock runtime, exit codes, stdout and stderr. Finally, gVisor intercepts every system call the guest code makes.

Because the sandbox forks inside an already-running container, there are no cold VM boots and no prompt overhead, which is how the author lands at 200–450 ms execution. Script logic changes require no image rebuilds either: new code is simply posted as a string and run immediately.

Runaway code is contained rather than fatal. If an offloaded script segfaults or spins in an infinite loop, gVisor terminates only the child process with SIGKILL while the parent FastAPI runner stays healthy and returns a structured JSON error. Cost-wise, setting min-instances to zero lets Cloud Run scale to nothing when idle, and combined with Google Cloud's Always Free tier the author reports zero idle maintenance cost for everyday automation.

What gVisor actually blocks

Acting as an application kernel that intercepts guest system calls, the sandbox applies several default restrictions, according to the article:

• Access to the Google Cloud Metadata Server at 169.254.169.254 is blocked, removing a common SSRF target
• Host environment variables are stripped from the guest
• The root filesystem is read-only
• External network egress is disabled by default

Verified from Apps Script

To check both functionality and security boundaries, the author built an eight-axis test suite that runs directly from Apps Script. The documented cases cover basic Python arithmetic (2**32 returns 4294967296 with exit code 0), syntax error handling (an unclosed string literal produces a structured SyntaxError response without taking down the container), and a denial-of-service defence where an infinite loop under a two-second timeout is killed by gVisor. Full setup and deployment instructions live in the project's GitHub repository.

Why it matters

Code produced by large language models is untrusted by definition, and the article's core argument is that sandboxing is a prerequisite for any automation that executes AI-drafted scripts, not a nice-to-have. Pairing gVisor with scale-to-zero Cloud Run pricing makes that isolation affordable for occasional Workspace tasks, not just always-on services.

The design also draws a useful line between workload types: agentic, multi-step work still benefits from Gemini Managed Agents, while deterministic computation — the bulk of routine automation — gets sub-second execution with no token spend. In practice, that turns Apps Script from a bounded JavaScript runtime into an orchestrator that can offload Pandas and Seaborn data science, complex data transformations and shell workloads it could never run natively.