Public Link has always let you hand someone an OTP-gated, time-boxed view of captured traffic - HTTP, PostgreSQL, gRPC, whatever a whisperer sees - without giving them a Spider account. What it could never do is show them the network map.

That gap was not subtle. On the Network Usage screen, the "Create a public link" button was hard-disabled. Not filtered, not empty - disabled, because the code only ever checked for screen === 'NETWORK_CAPTURE'. There was no form, no filter, no path at all from a public link into Controls, the service behind the map.

Deep, protocol-level visibility into your Kafka traffic - every command, every record batch, every error - without instrumentation, without proxies, without touching a line of application code.

After HTTP, PostgreSQL, Redis and gRPC, I'm happy to announce the next protocol natively decoded by Spider Analyzer: Apache Kafka!

Spider now decodes Kafka traffic directly from live TCP sessions - reconstructing each request/response exchange from the binary wire protocol, walking RecordBatches, and mapping Kafka error codes into structured, searchable communications. 💪

Deep, protocol-level visibility into your gRPC traffic - every call, every message, every status - without instrumentation, without proxies, without touching a line of application code.

After HTTP, PostgreSQL and Redis, I'm happy to announce the next protocol natively decoded by Spider Analyzer: gRPC (gRPC-over-HTTP/2)!

Spider now reconstructs gRPC calls directly from live traffic - unary requests/responses and streaming flows - decoding the HTTP/2 frames, the HPACK headers and the length-prefixed Protobuf messages into structured, searchable communications. 💪

Spider can now decrypt TLS traffic from Go programs that use the standard library - no OpenSSL, no SSLKEYLOGFILE, no application changes. Gocipher learns a new trick, and a whole class of services stops being a blind spot. 🔓

Spider's pcapng export is now a standard, portable artifact: a capture you export decrypts directly in Wireshark, and any standard pcapng + key-log - from Wireshark, tcpdump, or an SSLKEYLOGFILE - imports into Spider and decrypts in the full analysis views. No more Spider-only files. 🔁

Deep, protocol-level visibility into your Redis traffic - without instrumentation, without MONITOR, without slowing anything down.

After HTTP and PostgreSQL, I'm happy to announce the next protocol natively decoded by Spider Analyzer: Redis wire-protocol (RESP) parsing!

Spider now reconstructs Redis commands and replies directly from live traffic - RESP2 and RESP3 - giving you structured, searchable insight into exactly what your applications do with Redis, at runtime and at scale. 💪

The Go and Protobuf migration cut the parsing pipeline's CPU and memory bills in half. But it left the back office with a different kind of cost: the same plumbing copied across two parsers, a handful of small services doing one job each, and more deployments to operate than the work actually required.

This round of work is about that - not raw performance, but shape. Three changes, all aimed at the same goal: fewer moving parts, less duplicated code, and a foundation that makes the next parsers cheap to build.

Spider has been parsing HTTP/1.1 traffic for years - request lines, headers, status codes, response bodies - and let operators write tag and template rules that pull values out of those parts.

This works perfectly when the body is text.
JSON and XML carry their field names in plain sight, so a rule looking for a client id finds the string clientId sitting right there in the bytes.

Protobuf and MessagePack do not work that way: the body is a compact binary blob, and the field names live in a separate schema, not in the payload. The information is there - it just is not readable as text, so the text rules have nothing to grab onto.

The new HTTP body transcoding feature closes that gap.

• The operator uploads the schema once and declares which requests it applies to.
• From then on, Spider quietly converts each matching binary body into the equivalent JSON before the existing tag and template rules run.
• The same rules that already worked for JSON now also work for protobuf and MessagePack - with no change to the rules themselves.

This version introduces:

• a redesigned UI with new visualizations (multi-protocol view, waterfall),
• a parsing pipeline migrated to Go with Protobuf serialization and gRPC for the hot paths,
• and a new tooling layer for humans and AI agents: the spider and spider-mon CLIs plus two Claude Code plugins that wrap them.
• a vulnerability upgrade agent to lands the release with all known CVEs patched across all 44 active components.

Spider is 40+ Node.js services, 10 Go services, 3 Go clients, and 3 GUIs.
Each one has its own package.json or go.mod with its own dependency tree, its own vulnerable transitive packages, and its own breaking-change risk on every upgrade.

To manage technical debt, I wrote a Claude Code agent that does the entire run on its own.
Result:

• Total elapsed time: about 3h30 for 43 active components.
• Output: 43 fully fixed, 0 failed, 0 CVEs left where a fix existed.