Google Lets Developers Run Gemini Managed Agents in Their Own Sandboxes

Google has added self-hosted execution environments for developers building with Managed Agents. The Antigravity agent harness can now run code in a sandbox controlled by the developer or a supported infrastructure provider instead of relying exclusively on Google’s hosted Linux environment.

The launch includes integrations for seven providers:

• Vercel
• Modal
• Daytona
• Fly.io
• Google Cloud
• Cloudflare
• E2B

These options span managed agent sandboxes and general cloud runtimes, including microVM and container-based isolation systems covered in this runtime comparison. Google uses “self-hosted” to cover both infrastructure operated directly by a development team and environments supplied by an integrated vendor.

Google redraws the execution boundary

The earlier Managed Agents preview packaged the model and execution environment together. A single request to the Interactions API could invoke Gemini for planning, install packages, manipulate files, browse the web, and execute code inside an isolated Linux environment provisioned by Google. Developers could resume that environment across API calls until it expired or was deleted.

That design simplified deployment while limiting control over data location, network policy, base images, credentials, and compute selection. Teams already operating sandboxes inside a virtual private cloud, or paying for a service such as E2B or Modal, also had to maintain a separate Google-hosted execution path.

Self-hosted environments preserve Google’s agent orchestration while moving code execution into the selected sandbox. The division of responsibility now looks like this:

Prompts, tool calls, and outputs selected for model processing continue to pass through Google’s API. Local files and execution can remain inside the chosen environment, but self-hosting alone does not establish full data residency. Teams with regulated workloads must review what the worker returns to Gemini, alongside Google’s API terms and retention controls.

A worker links Gemini to the sandbox

The open-source Gemini API CLI provides the reference implementation. Its environments commands cover creation, inspection, deletion, file management, connection, polling, and serving. The serve and connect operations allow a worker on external infrastructure to register as an execution target for the Interactions API.

gemini-api environments create --self-hosted
gemini-api environments connect --provider modal
gemini-api agent run --agent antigravity \
  --environment my-env \
  --prompt "Analyze this repo and open a PR"

Provider workers implement Google’s environment protocol, authenticate with the API, receive execution requests, and return results to the agent runtime. Google has published reference examples for the launch partners, while providers are documenting deployment details such as long-lived services and keep-alive settings. Fly.io’s implementation work is visible in its worker guide.

State follows the environment

Managed Agents depend on persistent state across multiple model turns. A coding agent may clone a repository, install dependencies, modify files, run tests, and later resume the same workspace. Externalizing execution therefore requires the worker and provider to preserve environment identity, files, and process state for as long as the application expects.

Moving that state into a chosen runtime creates several practical options:

• Controlled network access: Teams can apply their own ingress, egress, private networking, and audit policies around executed code.
• Custom images: Internal command-line tools, approved dependencies, private registries, and language runtimes can be installed before the agent starts.
• Accelerated compute: Providers with GPU-backed sandboxes can support workloads unavailable in Google’s CPU-only hosted environment, subject to provider and plan limits.
• Existing infrastructure spend: Sandbox compute is billed separately from Gemini usage, allowing teams to use current provider contracts or cloud capacity.
• Local lifecycle controls: Retention, snapshots, cleanup, and environment reuse can follow an organization’s own policies.

You inherit the sandbox lifecycle

Google’s hosted environment supplied an Ubuntu base image, Python 3.12, Node.js 22, automatic provisioning, and a seven-day inactivity lifetime. Self-hosted deployments transfer those responsibilities to the developer or provider.

• Patch and rebuild the base image.
• Protect credentials exposed to the worker.
• Restrict network egress and internal service access.
• Set idle timeouts, retention periods, and cleanup jobs.
• Monitor worker health, capacity, and failed executions.
• Verify tenant isolation when multiple agents share infrastructure.

Provider limits also affect agent behavior. Vercel Sandbox sessions, for example, have plan-dependent duration caps, while Fly.io, Cloudflare, Modal, and other services use different timeout, suspension, and snapshot models. Applications that depend on long-running tasks or resumable state need to account for those differences.

Portability stops at the worker

Google’s partner list overlaps with providers used by other agent platforms, including Anthropic’s self-hosted tooling. That overlap gives teams more choice at the infrastructure layer, although each model vendor retains its own agent protocol, authentication flow, state model, and worker implementation.

An existing sandbox can therefore reduce migration work without making agent stacks interchangeable. Adopting Antigravity still requires a compatible worker, lifecycle configuration, security review, and application changes for the Gemini API.

Google says self-hosted environments are available through AI Studio and the Gemini API. Teams already operating a supported sandbox can connect that infrastructure to Managed Agents while keeping model inference and orchestration on Google’s platform.