Give your coding agent a local cloud environment with MCP

Jay Sen — Fri, 09 Oct 2026 14:25:43 +0000

LocalCloud gives AI coding agents a free cloud dev. environment for building, testing, and debugging Google Cloud applications. It provides MCP server for agent to connects for service discovery, SDK configuration, resource inspection, supported feature, readiness, and diagnostics, etc...

I'm sharing a practical setup and three small integration tests you can run locally. The application uses standard Google Cloud SDKs pointed at the discovered local endpoints.

Website · MCP setup guide · Source and releases

Install and connect your agent

Install LocalCloud CLI 0.1.9 or newer, keep Docker running.

On macOS, or Linux with Homebrew:

brew install LocalGCloud/tap/localcloud
lc --version
lc doctor
lc mcp install --client cursor

Reload Cursor and enable the localcloud MCP server. The bridge starts or reuses your local runtime. Its first connection can take longer while Docker downloads the image.

For an existing Homebrew installation, run brew update and brew upgrade localcloud. CLI and runtime versions are independent; an existing older runtime needs an explicit upgrade using the same data volume/configuration. The guide explains that process, the website installer, and setup for Claude Code/Desktop, Codex, VS Code, Cline, Gemini CLI, Antigravity, and Windsurf.

Give the agent an observable task

Try this prompt:

Use LocalCloud MCP to list local services, check readiness, and obtain SDK settings. Check compatibility before writing a small Cloud Storage, Pub/Sub, and BigQuery integration test. Use only the returned local endpoints and uniquely named test resources. Assert the actual results and clean up only resources created by this test. Stop if a required operation is unavailable; do not fall back to real Google Cloud.

The initial calls are localcloud_list_services, localcloud_check_readiness, and localcloud_get_env with {"format":"json"}. Returned SDK settings account for the runtime's actual port mappings.

Three workflows with real assertions

Cloud Storage: create a uniquely named bucket, upload a known string, download it, and assert an exact content match. Remove that test bucket in cleanup.

Pub/Sub: create a topic and subscription, publish a known message, pull it, check the exact bytes, and acknowledge it. Delete only that test's subscription and topic, including when an assertion fails.

BigQuery: run SELECT 1 AS mcp_smoke, then check that it returns exactly one row with value 1. The runnable example checks this through both localcloud_query_data and the standard BigQuery SDK.

These tests exercise application behavior as well as the MCP connection.

Run the complete example

Start an independent runtime for the three services. Dynamic ports let it run beside an everyday environment:

lc start --image agentcloud/localcloud:0.1.5 \
  --data-volume localcloud-mcp-demo \
  --services gcs,pubsub,bigquery --local-only --accept-dynamic-ports

Run the example from the public repository with its optional SDK dependencies using uv:

git clone https://github.com/LocalGCloud/localcloud-cli.git
cd localcloud-cli
uv run --with mcp==2.0.0 --with google-cloud-storage \
  --with google-cloud-pubsub --with google-cloud-bigquery \
  examples/mcp_workflows.py --data-volume localcloud-mcp-demo

The script obtains SDK settings through MCP, rejects non-loopback hosts, supplies anonymous local credentials, and removes its own bucket/topic/subscription. Its observed output was:

PASS MCP: localcloud_list_services
PASS MCP: localcloud_check_readiness
PASS MCP: localcloud_check_compatibility
PASS MCP: localcloud_get_diagnostics
PASS MCP: SDK configuration validates against its output schema
PASS MCP: BigQuery query returns the expected row
PASS Cloud Storage: upload and read back the exact content
PASS Pub/Sub: publish, pull, verify, and acknowledge
PASS BigQuery: SELECT 1 returns the expected row
Cleanup complete: only uniquely named example resources were removed

When finished, stop the example runtime:

lc stop --data-volume localcloud-mcp-demo

The named volume remains available for reuse.

Inspect a failure before changing the test

Ask the agent to check readiness, diagnostics, and recent requests, then rerun the failing assertion. A service can be present in the catalog while disabled in the running environment, so check current readiness and compatibility.

The default data volume is shared. Use test-owned resources and explicit cleanup; choose a separate named volume for an independent runtime. MCP management writes and destructive actions require explicit runtime settings. SDK operations can change local application data.

The example passed against the exact Linux ARM64 release image and the AMD64 image under emulation, through the published macOS ARM64 CLI. Google Cloud production validation and native hardware verification on every platform remain separate.

LocalCloud MCP is also active in the official MCP Registry, with a native desktop bundle.

Website · MCP guide · Original walkthrough and recorded demo

Run Google Cloud on your laptop

Jay Sen — Fri, 24 Apr 2026 23:29:21 +0000

A modern developer laptop is no longer a lightweight terminal. A current MacBook Pro comes with a 10+ core CPU, up to a 40-core GPU, and 128GB unified memory. That is serious local compute power sitting on a desk.

At the same time, organizations keep pushing more development and testing work onto paid cloud environments.

Flexera’s 2026 State of the Cloud says managing cloud spend remains a top challenge for 85% of organizations.
LocalStack claims 40% of cloud spend is wasted on dev & testing.

We keep renting compute we already own. This is one of the strangest things: we buy powerful laptops yet rely on cloud resources for basic development cycles and integration testing.

The result

Slower iteration
More credential friction
A cloud bill for work that belongs in the inner dev loop
Tooling already moving toward local-first development

The ecosystem is already moving

LocalStack provides AWS service emulation to build and test cloud apps locally
fake-gcs-server provides a Google Cloud Storage emulator as a binary or Docker image

So the question isn’t “Is this possible?” — it already is.

Are we ready to treat laptops as real infrastructure?

The real shift is whether teams are willing to treat the developer laptop as first-class infrastructure for inner-loop and non-production work.

There are still a couple of problems

LocalStack does not provide Google Cloud services
Cloud vendors are not strongly incentivized to support full local stacks
Existing emulators are partial, inconsistent, or too limited

That’s why I built:

LocalCloud — Google Cloud-In-A-Box

And It's Free: https://local.cloud

docker pull jaysen2apache/localcloud

mkdir -p ~/.localcloud/data

docker run -d \
  -p 8080:8080 -p 4443:4443 \
  -m 4g --name localcloud \
  -v ~/.localcloud/data:/var/lib/localcloud \
  jaysen2apache/localcloud

# Sets env vars
eval "$(curl -s localhost:8080/_localcloud/env?format=shell)"

# Use local Google Object Storage from Local FileSystem
gcloud storage ls gs://

With this developer can run and test most google services locally, making $0 cost and fast development.

Local is for building. Cloud is for shipping.

This does not mean the real cloud goes away. Production still needs production. Shared staging still matters. Scale testing, networking, IAM edge cases, and distributed behavior still belong in real cloud environments. But not every integration test needs cloud resources.

Future & vision: Domain-In-A-Box

One of the most under-appreciated time sinks for new developers is figuring out the data:

Which dataset has user events?
Where are model artifacts stored?
Which topics drive the workflow?

LocalCloud can help:

Like a domain data product, every domain in an organization should provide a domain-in-a-box on top of LocalCloud. This includes:

Preloaded domain services (nightly builds)
Mock data required for testing
Data catalog
Any workflows, etc...

Makes domain team devs & dependent teams productive on day one !

DEV Community: Jay Sen