Spider's whole pitch is unusual enough that people do not quite believe it until they see it: capture network traffic from a Kubernetes pod, decrypt the TLS, and reconstruct the conversation - without touching a line of application code. No SDK, no sidecar baked into the image, no instrumentation.

Telling someone that is one thing. Watching it happen is another. So there is now a demo where you can watch it happen yourself, live, at spider-analyzer.io/demo.

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.