Feature: standalone server mode ('minikube for cloud') so out-of-process apps can point real SDK clients at cloudemu

[NitinKumar004]

Use case

I'd love to use cloudemu the way minikube is used for Kubernetes: run it as a long-lived local process that my app's separate, real service processes point their cloud SDK clients at — so live flows (e.g. resource discovery) actually run against cloudemu and results show up in the app's own UI, end-to-end, with no real cloud.

Today this isn't quite reachable out of the box, and the docs intentionally scope cloudemu to in-process test usage (httptest.NewServer, "keep in _test.go", "never import from production"). That's perfect for tests — this is an additive ask for a local dev-cloud mode.

What's missing for the minikube-style flow

1. A standalone runner — there's no cmd/ / no ListenAndServe anywhere, so each user must hand-roll http.ListenAndServe(":port", azureserver.New(Drivers{...})). A first-class cloudemu serve (per-provider, stable configurable ports) would be the minikube start equivalent.
2. TLS for a real listener — the Azure SDK requires HTTPS; in tests httptest.NewTLSServer auto-certs. A standalone server needs a self-signed cert + a documented trust path (CA file, or an insecure-skip-verify flag) for out-of-process clients.
3. A documented, stable auth/cloud-config story for external clients — i.e. how to point azcore's cloud.Configuration (ResourceManager endpoint + authority/token endpoint) at the running server. There are already login.microsoftonline/GetToken references internally; exposing the token/authority endpoint as a stable, documented standalone endpoint (so azidentity against a fake cred just works over the network) would close the loop. Same idea for AWS/GCP auth.
4. State seeding + optional persistence — state is in-process memory, so a freshly-started server is empty. A way to seed resources at startup (config file / admin API) and optionally persist across restarts — like minikube's persistent cluster — so discovery flows find something.
5. An endpoints/“cloud-config” bundle — the kubeconfig equivalent: one artifact listing the emulated endpoints so an app can be pointed at the whole emulated cloud at once.

Why it's valuable

This turns cloudemu from an excellent in-process test double into a full local dev cloud for multi-service apps — you could bring up your real services against it and exercise live, UI-visible workflows without real accounts or Docker. The existing test-only mode stays exactly as is.

Totally understand if this is out of scope vs. the library's focus — wanted to capture the use case. Thanks!

[NitinKumar004]

Thanks — great use case, and the good news is the core is already reachable today; it's mostly packaging that's missing.

What cloudemu actually does: awsserver.New(...), azureserver.New(...), and gcpserver.New(...) each return a standard http.Handler. httptest.NewServer is just a convenience around it — so a long-lived standalone server is already:

srv := azureserver.New(azureserver.Drivers{ /* … */ })
log.Fatal(http.ListenAndServe(":4566", srv)) // out-of-process clients can point here now

On auth (point #3): cloudemu doesn't validate signatures or AAD/OAuth tokens — see the "No signature validation" note in the SDK-server docs. So you don't need a served token/authority endpoint: AWS/GCP use dummy creds (option.WithoutAuthentication()) and Azure uses a static fake azcore.TokenCredential. The fake credential lives on the client, over the network just the same as in tests.

The _test.go / "don't import from production" guidance is advice for the in-process test-double pattern, not a limitation — the handler is plain Go and is happy as a long-lived process.

So what's genuinely additive (and worth doing for a first-class "local dev cloud" mode):

1. A packaged cmd/cloudemu serve (stable ports, multi-provider) — the minikube start equivalent.
2. Built-in self-signed TLS cert + a documented trust path (only Azure needs HTTPS).
3. Startup state seeding + optional persistence.
4. An endpoints/"cloud-config" bundle to point an app at the whole emulated cloud at once.

Keeping this additive — the in-process test mode stays exactly as is. Thanks for the detailed writeup!