Tools
Using the debugger
Breakpoint, step, and inspect live Redis traffic through the opt-in proxy.
The debugger is an opt-in local proxy. Point a client at it — your app, a script, or Varc itself — and every command that flows through becomes something you can hold, inspect, and release.
Start a session
- Open the Debugger tab on a connected profile.
- Choose a local port (Varc suggests one) and hit Start proxy.
- Point the client you want to debug at
127.0.0.1:<port>.
The proxy binds to localhost only by default and can require the debugged client to authenticate before any command is forwarded.
Set a breakpoint
Breakpoints match on what matters to you:
- Any command — pause everything, like a global breakpoint.
- Writes only — let reads flow, hold every mutation.
- A command name — e.g. only
DELor onlyFLUSHDB. - A key pattern — e.g.
sess:*, held no matter which command touches it. - A single connection — isolate one misbehaving client.
When a command matches, the stream pauses and the held command is shown with its full arguments:
varc · debugger — cache-main-01
14:22:07.119HSET cart:42 items 3→ 1
■ Paused · breakpoint: writes
SET session:42 ‘{“uid”:42}’ EX 3600
Step, continue, skip
While paused you have five moves:
| Action | What it does |
|---|---|
| Step | Release this one command, pause at the next match. |
| Continue | Release and run this connection until the next breakpoint hit. |
| Skip | Drop the command; the client gets a synthesized error. Nothing reaches Redis. |
| Mock reply | Answer the client with a reply you craft. Nothing reaches Redis, nothing is captured. |
| Edit | Change the request, then forward it. |
| Run | Disable stepping and let traffic flow. |
Pipelined batches can be single-stepped one command at a time. If the debugged client disconnects while a command is held, the command is dropped — it is never executed twice.
Cluster sessions
The proxy is cluster-transparent: your client sees one endpoint while Varc routes each held-and-released command to the node that owns its keys.