27
Local service guides
Google Cloud APIs an agent can call without leaving the machine.
Agent environment · dependency boundary
A local cloud for AI coding agents
A code sandbox isolates where an AI agent runs. It does not change what the agent's code calls. LocalCloud supplies that missing half: Google Cloud APIs answered on localhost, so agent-written cloud code executes with no credentials, no billing project, and no real cloud side effects.
0
Credentials by default
No service-account key or billing project is required for documented local workflows.
1
Command to start
One CLI lifecycle, one health endpoint, one generated environment export.
The distinction that matters
An agent environment has two boundaries
Most agent tooling addresses only the first one. Cloud cost and cloud blast radius live in the second.
Where the generated code runs
Owned by a code sandbox. Containers, microVMs, or a hosted runtime keep an agent from touching your workstation, your repository, or your production hosts.
Typically owned by: E2B, Modal, Daytona, Docker Sandboxes, Northflank
What the generated code calls
Owned by a local cloud runtime. Google Cloud SDK calls resolve to localhost instead of googleapis.com, so an agent cannot create real cloud resources or real charges.
Typically owned by: LocalCloud
Honest comparison
Where each tool is the right answer
LocalCloud is not a replacement for a code sandbox, and a code sandbox is not a replacement for a local cloud. Pick by which boundary you are trying to close.
| What you need | Code sandbox | LocalCloud |
|---|---|---|
| Contain arbitrary generated shell and code execution | Primary purpose. Use a code sandbox. | Not the isolation layer for arbitrary shell risk. |
| Stop an agent from creating billable Google Cloud resources | Not addressed. A sandbox holding real credentials still reaches the real cloud. | Primary purpose. No default credentials or billing project. |
| Exercise BigQuery, Pub/Sub, Spanner, or Bigtable behavior | Requires real Google Cloud access from inside the sandbox. | Local endpoints for 27 available service guides. |
| Run an AWS-shaped local cloud | Not applicable. | Not supported. LocalStack is the right tool for AWS. |
| Give a coding agent a repeatable, inspectable local target | Varies by provider. | Health endpoint, generated env export, seed data, and a web console. |
Setup
Give an agent a local cloud target
Start the runtime, load its generated environment values into the agent's shell, and let the standard Google Cloud SDKs resolve to localhost.
Host CLI quick start
localcloud doctor
localcloud start
eval "$(localcloud env)"
localcloud console
Trust the URLs and values the CLI returns. Occupied ports are remapped, so read the generated environment rather than assuming a fixed port. Health is reported at http://localhost:24080/health.
Machine-readable setup
LocalCloud publishes a raw AGENTS.md template and Markdown route index that agents can read directly, without parsing marketing HTML.
Setup by coding agent
Boundaries
What this does not give you
- Permitted workflows use local endpoint values and should stop rather than fall back to real Google Cloud or real credentials. The Public Preview License permits individuals and organizations, including for-profit companies, to use LocalCloud for non-production internal development, testing, CI, evaluation, and pilots.
- LocalCloud emulates bounded local development workflows. Validate application behavior against real Google Cloud before production deployment.
- Before production deployment, unset LocalCloud emulator environment variables and validate behavior against real Google Cloud.
LocalCloud does not isolate arbitrary code execution. If an agent runs untrusted shell commands, pair it with a code sandbox. Review the compatibility matrix for per-operation status and the licensing reference for permitted use.
FAQ
Agent environment questions
What is an agent environment?
An agent environment is everything an AI coding agent can reach while working: where its code executes and what that code is allowed to call. A code sandbox owns the execution half. A local cloud runtime such as LocalCloud owns the dependency half by answering cloud SDK calls on localhost.
Is a code sandbox enough to keep an AI agent from touching my cloud account?
No. A sandbox isolates where code runs, not what it calls. If the sandbox holds Google Cloud credentials, agent-written code can still create real resources and real charges from inside it. Removing credentials and pointing the SDKs at a local runtime closes that gap.
How do I give an AI agent a cloud to test against without credentials?
Start LocalCloud, load its generated environment values into the agent process, and let the standard Google Cloud SDKs resolve to localhost. No cloud project, service-account key, or billing account is required by default for the documented local workflows.
Does LocalCloud replace E2B, Modal, or Docker Sandboxes?
No, and it is not trying to. Those products isolate arbitrary code execution, which LocalCloud does not do. They are complementary: run the agent inside a code sandbox and point its Google Cloud calls at LocalCloud.
Can an AI agent write code against LocalCloud and then ship it to real Google Cloud?
Local runs are a development and testing step, not a release gate. Compatibility is documented per operation and is narrower than managed Google Cloud, so validate the same code against real Google Cloud in a separate guarded step before production.
Which coding agents work with LocalCloud?
Any agent that can run shell commands and read environment variables. LocalCloud publishes setup pages for Claude Code, Codex-style CLIs, Cursor, and Gemini CLI, plus a raw AGENTS.md template agents can read directly.