API

--server runs zshot as an HTTP server, exposing capture as an API that other clients call over HTTP. It keeps a browser warm between requests, runs in Docker, exposes Prometheus metrics, and supports Basic and token authentication. Server mode is a Pro feature; signed-URL authentication requires Enterprise.

Run zshot inside your own infrastructure and reach it from your own services. It is not built to sit on the public internet.

See Server for endpoints and tuning flags, and Docker to run it in a container.

Security

The server offers Basic, token, and signed-URL authentication, and --block-private-ips keeps a rendered page from reaching internal hosts. These controls protect a service running among trusted callers; they are not a hardening layer against wide public exposure. Put zshot behind your own network boundary and front it with a gateway that handles public traffic.

Additional assets and the Link header

A render returns its primary output as the response body. It can also produce additional artifacts. Request each with its matching with_* field: with_har, with_warc, with_pprof_cpu, with_pprof_memory, with_trace, with_navigator_video, with_network_log, and with_axtree. Most are booleans; with_axtree instead takes true/json for the JSON accessibility tree or text for the indented snapshot.

Each asset the server produces is written to a temporary location and advertised with a Link header on the render response, one per asset:

Link: </assets?file=<id>.har>; rel="related"; type="application/json"

The URL is relative, so it resolves against whatever host or reverse proxy fronts the server. Fetch the asset with a GET to that URL. Its lifetime is set by --server-additional-asset-expiration; after it expires the URL returns 404. When the server requires signed URLs, the asset links are signed and carry the same expiry.