datumctl v0.18.0 — Point any local tool at the Datum Cloud API

[scotwells]

You can now run datumctl api proxy to start a local, authenticated gateway to the Datum Cloud API. Point a dev server, a test harness, or curl at a localhost port and it talks to the platform using your active session — no tokens to copy, no expiry to babysit.

A loopback proxy that carries your session

datumctl api proxy starts a proxy on 127.0.0.1 that forwards every request to the API endpoint of your current session, attaching your credentials on the way through and refreshing them before they expire. Anything on your machine that can make an HTTP request can now reach the platform without ever handling a token.

$ datumctl api proxy --port 8001
  Session:    maya@datum.net (api.datum.net)
  Upstream:   https://api.datum.net
  Scope:      full endpoint (use --project/--organization to serve one control plane)
  Listening:  http://127.0.0.1:8001

$ curl http://127.0.0.1:8001/apis/resourcemanager.miloapis.com/v1alpha1/organizations

By default it's a pure passthrough: the same paths that work against the real API work against the local port, so swapping one base URL gives you dev/prod parity. This is useful when a local service or test suite needs to hit the platform repeatedly — you get a stable local address instead of wiring token handling and refresh into every tool.

• Scope it to one control plane. Add --project or --organization and the proxy serves that single control plane at its root, so your URLs drop the long control-plane prefix.
• Streaming just works. Watches, server-sent events, and chunked responses pass through unbuffered — each event reaches your client the moment the platform sends it, so long-lived watch clients behave exactly as they would against the real endpoint.
• Built for scripts. With no --port, the proxy picks a random free port and prints the bare URL as the first line on stdout once it's ready — a harness can read that one line as its readiness signal. --quiet silences per-request logs; Ctrl+C shuts down gracefully.

Important

The session and scope are pinned when the proxy starts. Running datumctl auth switch or datumctl ctx use afterward does not repoint a running proxy — restart it to pick up a new session or scope.

Safe by default

• Loopback only — binds 127.0.0.1 with no flag to change it.
• Host-header validation rejects requests whose Host isn't localhost/127.0.0.1/[::1], defeating DNS-rebinding from web pages.
• No CORS headers, so browsers won't script cross-origin reads — the proxy is for server-side and command-line clients.
• Token hygiene — any Authorization header your client sends is stripped and replaced with the session's real token, and tokens never appear in logs.
• Clear failures — if your session is expired or logged out, the proxy stays up and answers with a 502 and a message telling you to run datumctl login, and it recovers automatically once you log back in. A 401/403 from the platform itself passes through untouched, so you can always tell a local auth problem from a real platform answer.

📖 Docs: Local API proxy

Fixed

• User-facing hints now point to the top-level datumctl login instead of auth login, matching how you actually sign in.

Thanks to the team who requested a friction-free way to point local tooling at the platform. What's the first tool you'll wire up behind the proxy — a dev server, a test suite, or something else?

Full changelog: v0.17.4...v0.18.0