Question 1

What is MockMesh?

Accepted Answer

MockMesh is an open-source Python library that intercepts cloud API calls from AWS (boto3), Azure (azure-sdk), GCP (google-cloud), SQL databases, MongoDB, Redis, Kafka, RabbitMQ, and HTTP endpoints at the transport level. It provides real stateful local mocking of 60+ cloud services with zero credentials and zero cost. Install with pip install mockmesh.

Question 2

How do I mock AWS services locally with Python?

Accepted Answer

Install MockMesh with pip install mockmesh, then call mockmesh.initialize() at the top of your script. All boto3 calls (S3, DynamoDB, SQS, etc.) are automatically intercepted at the botocore transport layer — no credential setup, no Docker, no code changes to your application.

Question 3

What is the difference between MockMesh and LocalStack?

Accepted Answer

LocalStack runs actual AWS service emulators in Docker containers. MockMesh intercepts at the Python SDK transport layer — no Docker required. MockMesh also supports Azure, GCP, SQL databases, MongoDB, Redis, Kafka, RabbitMQ and any HTTP endpoint in the same library, with a 4-tier response resolution system, auto-detection, fallback modes, and real file-backed stateful storage.

Question 4

How does MockMesh compare to Moto?

Accepted Answer

Moto is an AWS-only mocking library that requires decorators or context managers on each test. MockMesh intercepts at the transport layer with a single initialize() call — no decorators needed. MockMesh also goes beyond AWS to support Azure, GCP, SQL databases, MongoDB, Redis, Kafka, RabbitMQ, and HTTP endpoints in one unified library with real stateful storage.

Question 5

Does MockMesh support Azure SDK mocking?

Accepted Answer

Yes. MockMesh patches azure-core's RequestsTransport.send at the transport level, intercepting all Azure SDK calls including Blob Storage, Cosmos DB, Service Bus, Key Vault, Event Hubs, Storage Queue, Table Storage, App Configuration, and ARM-based services like SQL Database, Redis Cache, AKS, ACI, and Container Apps.

Question 6

How do I mock GCP services locally with Python?

Accepted Answer

MockMesh intercepts google-cloud SDK calls at the transport layer. After calling mockmesh.initialize(), Cloud Storage, Firestore, Pub/Sub, Secret Manager, BigQuery, Spanner, GKE, and Cloud Run calls are all mocked locally. No service account JSON files or GOOGLE_APPLICATION_CREDENTIALS needed — MockMesh handles it all with zero configuration.

Question 7

Does MockMesh require Docker?

Accepted Answer

No. MockMesh is a pure Python library with zero Docker dependency. Unlike LocalStack or other emulator-based tools, MockMesh intercepts SDK calls at the transport layer within your Python process. Just pip install mockmesh and call initialize() — it runs anywhere Python runs, including CI/CD pipelines, notebooks, and serverless environments.

Question 8

How do I mock MongoDB with MockMesh?

Accepted Answer

MockMesh intercepts pymongo connections at the transport level, routing all MongoDB operations to an in-memory store. Collections, documents, indexes, and queries all work as expected. Call mockmesh.initialize() and your existing pymongo code works without any MongoDB server running — ideal for unit tests and local development.

Question 9

How do I mock Kafka producers and consumers locally?

Accepted Answer

MockMesh intercepts both confluent-kafka and kafka-python at the transport layer. After calling mockmesh.initialize(), producers write to an in-memory topic store and consumers read from it. Messages are properly partitioned and offset-tracked. No Kafka broker needed — your existing Kafka code runs unchanged.

Question 10

How do I use MockMesh with pytest?

Accepted Answer

MockMesh provides pytest integration with session-scoped and per-test isolation. Add a conftest.py fixture that calls mockmesh.initialize() with your desired configuration. Session scope shares state across tests for integration scenarios, while per-test scope gives each test a clean slate. MockMesh cleans up all interceptors automatically when the fixture tears down.

Question 11

Is MockMesh stateful?

Accepted Answer

Yes. Storage-backed operations (S3, DynamoDB, SQS, GCS, Cosmos DB, Service Bus, Key Vault, SSM, SecretsManager, ElastiCache) use real local file-backed stores. MongoDB and Redis use in-memory stores. SQL databases use a SQLite backend. A DynamoDB PutItem actually writes to .mockmesh/nosql/TableName.json. A subsequent GetItem reads from that same file. Your application cannot distinguish this from the real cloud.

Question 12

How do I override responses for specific AWS operations?

Accepted Answer

Create a folder with files named aws.json, azure.json, etc. (matching the built-in defaults naming) and pass the folder path via responses_path to mockmesh.initialize(). MockMesh deep-merges your overrides on top of built-in defaults — only include the operations you want to change. Alternatively, place the files in your .mockmesh/ workspace and they are picked up automatically.

LocalStack is gone.
What now?

One initialize() call

Multi-cloud by default

Zero infrastructure

Actually stateful

MockMesh vs. Alternatives