Most "run the cloud locally" setups ask you to learn a new tool, a new mock API, or a new test framework. The faithful way is far smaller: keep your real SDK, and point its endpoint URL at a local cloud. Here's the exact pattern for AWS, GCP, and Azure.
The one rule
Every major cloud SDK lets you override the service endpoint. Real cloud uses
the default (e.g. s3.amazonaws.com); a local cloud like
Vyomi answers the same API at http://localhost:9000.
Nothing else in your code changes.
AWS — boto3
import boto3
s3 = boto3.client("s3", endpoint_url="http://localhost:9000",
aws_access_key_id="test", aws_secret_access_key="test",
region_name="us-east-1")
s3.create_bucket(Bucket="demo")GCP — google-cloud-storage
from google.cloud import storage
client = storage.Client(
project="local",
client_options={"api_endpoint": "http://localhost:9000"},
)
client.create_bucket("demo")Azure — azure-storage-blob
from azure.storage.blob import BlobServiceClient
svc = BlobServiceClient(account_url="http://localhost:9000",
credential="test")
svc.create_container("demo")Why "real SDK, local endpoint" beats mocks
A mock re-implements the API's shape; a digital twin runs the real backends behind it. With Vyomi, S3/GCS/Blob are served by MinIO, SQL by real Postgres, NoSQL by DynamoDB Local and friends — so behavior matches production, not a best-effort imitation. And because the same appliance answers all three clouds, a cross-cloud test (write to S3, read from GCS, queue on Azure) runs entirely on localhost.
From local to production
When it works locally, Vyomi exports the running stack to Terraform, so the environment you developed against is the one you ship. That round trip — local twin to real cloud — is the difference between a test fixture and a faithful replica.
Want the step-by-step? See How to run AWS locally and the local cloud emulator comparison.