Playwright Webserver Capture

Overview

A host list with status codes is not a picture of those servers. Titles repeat, login walls look like 200s, and a parked page looks the same as a forgotten admin until you open it. Doing that one URL at a time does not scale once the list is more than a handful of hosts.

This workflow takes that list, opens each URL in a real browser on its own fleet worker, and keeps the screenshot, the HTML the engine painted, and a meta.json per host. A report node merges those shards into captures.jsonl and report.md. Schedule it when the same host file is the thing that changes. That gallery is what an offensive security pass reads before picking the next workflow.

The playwright node does the navigation. Distribution is per URL, not one browser walking the file in series.

Pipeline

1. Normalize the list. targets reads a mounted host file or the seeded example URLs, adds https:// when a scheme is missing, and writes at most 50 lines to urls.txt.
2. Open each URL. playwright (capture) runs one worker per line, mode set to screenshot, and writes screenshot.png, page.html, and meta.json.
3. Merge the shards. report walks every capture folder and writes captures.jsonl, report.md, and a screenshot per host.

Inputs

• URL list. Hosts or full URLs, one per line. Seeded as https://example.com, https://example.org, and https://example.net. A file under in/ replaces the seed.
• Mode. screenshot on the capture node. Switch a run to trace when you need a HAR and trace.zip per host.
• Host cap. 50 URLs. The cap sits in targets so a public run cannot fan out hundreds of browsers.

Outputs

• captures.jsonl. One row per URL with status, title, final URL, and the screenshot path.
• Screenshot gallery. One screenshots/<host>.png per captured URL.
• Rendered HTML. One <host>.html per URL as the browser painted it.
• report.md. The same rows in a short markdown packet.

Integrations

• playwright opens each URL on its own worker.

Sample output

From a completed run against the seeded three-host list (example.com, example.org, example.net). Three playwright workers ran; each returned HTTP 200.

url	final_url	status	title	mode	browser	elapsed_ms	error	screenshot
https://example.com	https://example.com/	200	Example Domain	screenshot	chromium	254	null	screenshots/example.com.png
https://example.org	https://example.org/	200	Example Domain	screenshot	chromium	248	null	screenshots/example.org.png
https://example.net	https://example.net/	200	Example Domain	screenshot	chromium	130	null	screenshots/example.net.png

report.md from that run listed three hosts, each with status 200 and title Example Domain.

FAQ

How is this different from Playwright Page Capture?

That workflow opens one URL. This one takes a list and starts one playwright worker per line so the captures run in parallel.

How is this different from Website Screenshot and Visual Recon?

That workflow enumerates a domain, probes live hosts, and screenshots a host file with gowitness. This one starts from a list you already have and uses playwright, so you can keep a HAR or run a script per host if you change the mode.

How many hosts get a browser?

50 at most. targets writes at most 50 lines before the workers start. Raise that cap in targets for a list you own.

Do you need an API key?

No. The run opens the URLs in the list. There is no third-party key on the graph.

Does a dead host fail the whole run?

No. That worker writes meta.json with the error and the report still merges the hosts that answered.

Related workflows

• Playwright Page Capture. Reach for this instead when you have one URL and do not need a distributed host list.
• Website Screenshot and Visual Recon. Reach for this instead when you have a domain and need subdomain enum plus a gowitness gallery, not a list you already hold.
• Webpage Reading Queue Digest. Reach for this instead when an HTTP fetch of the page text is enough and you do not need a browser render.