Localhost & Tunnels
Test locally

Localhost & Tunnels

Testing a store that runs on your own machine — a tunnel today, the Local runtime when it lands.

What counts as local

The harness treats a host as local when it is localhost, a private or loopback address, a bare hostname, or ends in .local, .localhost, .internal, or .test. Local hosts keep their http:// scheme — public hosts are always upgraded to HTTPS — and a saved target with a local endpoint is stamped environment: local automatically.

Warning

Keeping the scheme doesn't make the host reachable. Sessions execute in the Cloud runtime — our infrastructure — and your localhost is not on our network. A local address saved as a target is valid, but a Cloud session cannot reach it.

Today: use a tunnel

  1. Expose your dev store on a public HTTPS hostname with the tunnel tool you already use (ngrok, cloudflared, or similar) — e.g. https://mystore.ngrok.app.
  2. Serve your manifest at /.well-known/ucp on that hostname so endpoint discovery works, or save a target with explicit endpoints to skip discovery.
  3. Point the Inspector or an Agent run at the tunnel domain like any other store.

Mind that a tunnel makes your dev store publicly reachable while it's up — put it behind auth if the catalog matters, and remember the harness sees exactly what any visitor would.

Next: the Local runtime

The Local runtime removes the tunnel entirely: a small runner process on your machine connects out to the Playground, and each merchant-bound request of your session executes inside your network — localhost works as-is. Three properties are the point of the design:

  • Store traffic stays local; the session does not. The runner makes the store-bound requests on your machine, so your store never has to be publicly reachable — but the responses return to your session in the cloud, where they are processed and stored like any other run. Don't point it at a store whose responses you can't send us.
  • An allowlist on both ends. The runner declares which hosts it may reach (by default only localhost), and both the cloud and the runner enforce that list independently — neither side can widen it alone.
  • Keys stay in custody. Signed requests arrive at the runner with signature headers already computed — no signing key material ever crosses onto your machine.

The Local runtime is coming soon. The Runtime picker in the Agent rail shows it, and it becomes selectable only when a runner is connected to your workspace. For early access, get in touch.

Note

Store-page (WebMCP) runs always use a browser on our side, in the Cloud runtime. To run one against a store on your machine, expose it with a tunnel.