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.

The two CLIs that ship with the coming release - spider and spider-mon - already make Spider accessible from a terminal.

Pointing an LLM at either of them and asking it to figure out the right invocation works, in the same way that pointing an LLM at any CLI works: well enough on simple questions, fragile on real workflows.

The two Claude Code plugins that ship alongside the CLIs solve the fragility.
They teach Claude the data model, the verbs, the conventions, and a set of investigation patterns purpose-built for Spider.

The same questions that takes five hand-prompted CLI calls in plain Claude Code become one skill invocation with a structured report.

Spider has a full self-monitoring GUI: parsing pipeline metrics, agent states, Redis and Elasticsearch internals, service CPU and latency, log search. It is great for browsing and for opening on a screen during an incident.

It is less great when the question is "diff the last hour against last week, on this specific metric".
Or "give me a new performance metrics".
Or "did the upgrade I just rolled out actually move any metric?".
These are queries, not dashboards.

spider-mon is the CLI for those questions.

Spider's UI is great when you want to see what has been captured.

But there is a long tail of moments where the UI is not the right tool:

• a 3 a.m. incident where the goal is "did the call to the payments service actually go out?",
• a CI job that needs to confirm a deployment generated the expected traffic,
• an AI agent that needs to investigate a slow endpoint before suggesting a fix.

Those use cases want a CLI command. spider.

The Controller rewrite in Go last February was a single agent.
The lessons learned there - that Claude could carry a Node service across to Go with feature parity over a handful of evenings, and that the runtime gains were real - made one thing obvious: the parsing pipeline was next.

This release ships the result:

• Seven services migrated.
• Three serialization formats swapped from JSON to Protobuf.
• Three hot paths swapped from REST to gRPC.