Which cloud platforms support local development?

This guide validates LocalCloud behavior only.

Local-First Development

Local cloud development guide

Q: What is local cloud development?

Local cloud development means running cloud service emulators on your local machine instead of connecting to remote cloud APIs. Developers use local versions of S3, DynamoDB, BigQuery, Cloud Storage, and other services during development and testing.

Q: Do I need different tools for each cloud?

Use localcloud env for the actual loopback endpoint map; this guide does not validate other vendors.

Use LocalCloud for bounded Google Cloud development workflows on loopback endpoints, with explicit evidence and production-validation boundaries.

Google Cloud setup Compare platforms

Why develop against local cloud services?

Local emulation provides a controlled inner loop, but does not reproduce production latency, IAM, quotas, or every API behavior. Runtime telemetry and configured features can make outbound requests.

Local cloud emulators by platform

This page focuses on LocalCloud. Consult each vendor's current documentation when comparing other local cloud tools.

Platform	Tool	Services	Popular Services
Google Cloud (LocalCloud)	LocalCloud	27	Available local services with documented workflows

Google Cloud local development with LocalCloud

LocalCloud exposes 27 available Google Cloud services in one managed container. Firestore is available but disabled by default. The CLI returns local endpoint settings for the actual host ports.

Quick start

curl -fsSL https://local.cloud/install.sh | sh
localcloud doctor
localcloud start
eval "$(localcloud env)"
localcloud console

Supported GCP services

Data & Analytics: BigQuery, Cloud Storage, Firestore, Dataproc

Messaging: Pub/Sub, Cloud Tasks

Databases: Spanner, Bigtable, Cloud SQL, AlloyDB

Compute: Cloud Functions, Cloud Run, GKE, Compute Engine (Pro)

Operations: Secret Manager, Cloud Scheduler, Logging, Monitoring

View all 27 service guides →

Key features

• Service-specific gRPC/REST compatibility with documented limits

• Export actual local endpoint values with localcloud env

• Client support varies by service and tested profile

• Persistence varies by service and backing store

• Containerized workflows remain subject to the governing license

• Terraform support is partial and resource-specific

• Native ARM64 support (Apple Silicon)

Complete GCP setup guide Documentation

Best practices for local cloud development

1. Environment variable separation

Use different environment variables for local vs production. Never accidentally hit production APIs during local development.

# .env.local
BIGQUERY_EMULATOR_HOST=http://localhost:24087
STORAGE_EMULATOR_HOST=http://localhost:24081

# .env.production
# (no emulator variables — uses real GCP)

2. Seed data for testing

Pre-populate local services with test data. Can make supported fixtures repeatable. Seed support is service-specific.

• Create seed scripts that run on container startup

• Store seed data in version control

• Use realistic data volumes for performance testing

• Automate seed data creation in a permitted internal workflow

3. Internal automation

The Public Preview License permits containerized development and testing for individuals and organizations, including ongoing internal team CI.

• Use Docker Compose for multi-service setups

• Wait for emulators to be healthy before running tests

• Cache Docker images in an authorized internal runner

• Run parallel test suites with isolated emulator data volumes

4. Feature parity awareness

Know what's supported and what's not. Emulators have documented gaps — always validate against real cloud services before production.

• Read emulator coverage documentation

• Test edge cases against real cloud in staging

• Monitor for behavior differences

• Have a staging environment that mirrors production

5. Performance testing considerations

Local emulators have different performance characteristics than production cloud services. Don't rely on local benchmarks for production capacity planning.

• Do not infer production latency from local behavior

• Throughput limits differ significantly

• Resource contention behaves differently

• Always load test against real cloud before launch

6. Team consistency

Pin the reviewed image and configuration for repeatable personal workflows. Shared organization use must comply with the governing license.

• Pin Docker image versions in docker-compose.yml

• Document setup in README

• Provide one-command setup script

• Include emulator config in version control

Frequently asked questions

What is local cloud development?

Local cloud development points supported client workflows at loopback emulators instead of production endpoints. Emulator behavior, persistence, IAM, and performance differ from production.

Do I need different tools for each cloud?

This guide documents LocalCloud only. External vendor counts and capability claims were not validated from authorized local evidence.

Can I use LocalCloud in CI/CD?

Yes. The Public Preview License permits non-production internal CI for individuals and organizations, including for-profit companies. Exact runner behavior must still be tested.

Should I test against real Google Cloud before production?

Yes. Local emulation covers bounded workflows and does not reproduce every production behavior. Run final validation against real Google Cloud.

Start with Google Cloud local development

Use the CLI for bounded local workflows, then review compatibility and the governing proprietary license.

Setup guide Documentation