Standalone server

For most Python tests you want the @mock_gcp decorator, which patches the clients in-process. But sometimes you need a real HTTP endpoint:

• your SDK is in another language (Go, Node, Java, ...),
• you run the google clients in emulator mode (pointed at an env var),
• you want a long-lived fake shared across processes.

drongo server is the same trick as moto_server: it replays drongo's HTTP route tables over a real socket.

Starting the server

drongo server --port 9090

Then point the relevant emulator env var at it. For Cloud Storage:

export STORAGE_EMULATOR_HOST=http://localhost:9090

from google.cloud import storage
from google.auth.credentials import AnonymousCredentials

client = storage.Client(project="p", credentials=AnonymousCredentials())
client.create_bucket("b")  # served by the drongo server over HTTP

Emulator env vars

Each google-cloud client honors a service-specific env var that points it at an alternative host. Set the one for the service you are testing and the client sends its requests to drongo instead of Google:

Service	Env var
Cloud Storage	STORAGE_EMULATOR_HOST
Pub/Sub	PUBSUB_EMULATOR_HOST
BigQuery	BIGQUERY_EMULATOR_HOST

When you use the in-process @mock_gcp decorator instead, drongo sets and clears these for you where needed (for example, it runs the Pub/Sub gRPC emulator and sets PUBSUB_EMULATOR_HOST automatically).

Non-Python SDKs

Because the server speaks the real REST/JSON API, any language's SDK can point at it the same way. This is what makes drongo usable from a polyglot test suite or a docker-compose stack, not just Python.

When to use which

	@mock_gcp (in-process)	drongo server (HTTP)
Python unit tests	Best choice	Overkill
Other-language SDKs	Not possible	Best choice
Cross-process / shared state	No	Yes
Speed	Fastest (no sockets)	Fast (local socket)
Setup	One decorator	Start a process + env var