Keploy published a comparison of Speedscale that introduces us to a product we only partly recognize. Apparently, we require an SDK and handwritten tests. Neither is required. The page also describes our Kubernetes capture as a sidecar proxy, an architecture we did build and have since deprecated.
Keploy’s article reads like AI slop: confident claims, stale architecture, and an SDK that turns up in the page’s closing summary with nothing in our product behind it. The writing process is anyone’s guess. The errors are easy to check.
Comparisons are fair game. Recording real traffic and turning it into tests is a useful idea, and Keploy has built a product around it. But if you’re choosing what to run against your applications, an imaginary installation guide is a poor starting point. Here’s how Speedscale actually works, with documentation you can inspect. For the broader evaluation, see our technical comparison of Speedscale and Keploy.
The SDK we apparently forgot to build
Keploy frames the choice as automatic traffic-based testing on its side and manual tests, configured mocks, and SDK or sidecar setup on ours. Its handwritten code sample is labeled “Manual with Speedscale,” and its summary contrasts the infrastructure changes each product needs as “none vs SDK/sidecar/containers.” Elsewhere on the same page, Keploy correctly describes Speedscale as generating dependency simulations from recorded traffic. Those claims don’t fit together.
Speedscale capture doesn’t require an application SDK. Our eBPF collector observes traffic outside application code. For supported JVM traffic, a Java instrumentation agent supplies the capture data. For local development, proxymock uses an explicitly configured proxy.
There is no Speedscale SDK import to add to your application. We would struggle to help you configure it, since we’d first have to invent it.
The practical distinction is between changing source code and configuring capture. Installing a collector, enabling a Java agent, or setting a local proxy still requires setup. None of those steps becomes an SDK because a comparison page lists one.
The sidecar comparison is out of date
Keploy describes Speedscale as using “Kubernetes sidecar proxy-based capture.” We did run that architecture for years. Our documentation now marks sidecar capture as deprecated for new Kubernetes installs.
The current collector, nettap, runs as a DaemonSet on Kubernetes nodes and observes traffic passively. It doesn’t inject a capture sidecar into each application pod. We covered the move in our post about replacing sidecars with eBPF.
flowchart TD
app[Application] --> dependency[Real dependency]
app -. Observed data .-> collector[nettap]
collector --> recording[Recording]
The solid application arrow shows its connection to a real dependency. The dotted arrow shows observation data going to nettap; the collector is outside that connection path. TLS capture still depends on the supported library or Java agent.
The sidecar remains available for existing deployments and workloads outside the eBPF requirements. Describing that fallback as the only capture architecture gives readers an obsolete picture of the product.
For JVM capture, the Java agent needs new pods and a JVM restart. That belongs in an honest comparison too. It still doesn’t turn the agent into a traffic proxy.
eBPF tells you where probes run
The useful question is what happens to your application’s connections while recording. The word eBPF alone doesn’t answer it. A system can use kernel instrumentation to observe traffic, or use it as part of a design that redirects traffic through a proxy. Ask for the full connection path.
Keploy’s general architecture guide describes outbound calls going through a transparent proxy, including TLS interception. Its source also documents an observe-only, low-latency capture path that doesn’t redirect connections, and its Kubernetes guide offers both sidecar and DaemonSet modes. Those distinctions matter. We wouldn’t describe every Keploy deployment as a proxy or a sidecar, and Keploy should apply the same care to Speedscale.
With nettap, application traffic continues directly to its destination. The collector observes the traffic without terminating connections or adding a proxy hop. That’s the architecture described in our workload impact documentation.
For supported TLS libraries, probes observe plaintext at the library boundary, before encryption or after decryption. The application keeps its existing certificates and trust configuration during capture. The Java agent provides that visibility inside the JVM for its supported transports.
Proxy-based TLS capture has a different setup. When a proxy terminates TLS on behalf of a dependency, the application must trust the certificate it presents. In our experience, that trust configuration was often the hard part: a JVM truststore here, a Python environment variable there, a minimal container image with no convenient place to install a CA.
Passive capture removes that certificate step for supported workloads. It doesn’t remove the need to check compatibility.
Traffic replay supplies the tests and mocks
Consider a service that accepts an HTTP request, queries Postgres, and calls another API. Speedscale records the inbound request and response along with the supported downstream exchanges. During replay, recorded requests exercise the service, and recorded dependency responses supply its mocks. You don’t have to recreate that Postgres interaction as a JSON fixture or keep a database container running solely to answer the mocked calls. Our service mocking documentation explains the workflow.
flowchart TD
requests[Replay requests] --> app[Service under test]
app <--> mocks[Recorded mocks]
app --> compare[Assertions]
In this replay, both downstream dependencies are mocked from the recording. The comparison checks the service’s new responses against the recorded ones using your configured assertions.
You still decide which traffic to replay, which dependencies to mock, and how to compare responses. Fields such as timestamps may need comparison rules. Recorded behavior also needs review: a response being real doesn’t make it correct. Those are testing decisions, not a requirement to handwrite the original requests and expected responses.
The technology support matrix lists HTTP/1.1, HTTP/2, gRPC, Postgres, MySQL, MongoDB, Redis, Kafka, and other technologies. Check capture, analysis, and replay support separately; visibility into a protocol doesn’t automatically promise every replay scenario. For streaming RPCs, verify the specific interaction you need rather than treating a gRPC checkbox as a complete test plan.
Captured traffic also drives load testing. You can use the same recording to check behavior after a change and then increase traffic to investigate performance. Our Kubernetes load testing guide walks through that workflow.
Local testing starts on your laptop
Keploy’s comparison also treats Kubernetes expertise as a prerequisite. That misses proxymock, our local CLI, which runs on macOS, Linux, and Windows. Its installation guide and architecture guide cover recording, mocking, and replay without a cluster.
proxymock is a proxy. You configure your app or client to route traffic through it. TLS interception through that proxy requires the corresponding certificate trust setup. It is a different capture path from passive eBPF recording in Kubernetes, and evaluating it requires understanding that difference.
Speedscale is a commercial product, and the proxymock CLI has its own license terms. Compare the edition and deployment you would actually use. A free tier, an open-source repository, and an enterprise deployment can have different entitlements even when they share a product name.
Our limits belong in the comparison too
Plaintext TCP capture doesn’t depend on your application’s programming language. TLS capture depends on the library and build. OpenSSL 3.x, Go’s standard TLS library, rustls, and the JVM each have their own capture path and requirements. The eBPF reference documents those requirements.
Go TLS capture requires Go 1.18 or newer and an ELF binary with its symbol table preserved. The documented rustls path requires nettap v0.1.77 or newer, retained symbols, and probe targets that haven’t been removed or inlined by build optimization. The verified Rust matrix includes rustls 0.23 and tokio-rustls 0.26. Java transport and TLS-provider coverage is listed in the agent compatibility guide.
The collector needs BTF enabled and a supported Linux kernel: 5.15 or newer on x86_64, 6.0 or newer on arm64, and RHEL 9.2 or newer for RHEL nodes. It needs host visibility and Linux capabilities to attach its probes. Non-root doesn’t mean permission-free.
Traffic capture is TCP-based, with DNS observation handled separately. HTTP/3 over QUIC falls outside that scope. OpenSSL uprobe capture supports 3.x, rather than older OpenSSL releases, BoringSSL, or LibreSSL. Connections already open when the collector attaches can be incomplete; multiplexed HTTP/2 and gRPC connections need a new connection before capture can reconstruct them reliably.
There is also measurable overhead. Our published measurements from one production cluster show roughly 0.8 microseconds per TCP send probe, 1.7 microseconds for receive entry and exit, and 20 to 30 microseconds for TLS read and write probes. Those are probe execution costs on that hardware, not an end-to-end latency guarantee. Measure your own workload’s CPU and latency before and after enabling capture.
When the capture pipeline saturates, it can drop observation events. Applications keep serving traffic, but the recording becomes incomplete. Monitor nettap_ringbuf_drops_total so you can see that loss.
Replay has a different job from recording. A responder must sit in the request path to answer dependency calls with mocks. If it presents TLS certificates, the application must trust them. Passive production capture and dependency impersonation during a test solve different problems.
Check the architecture before believing the table
The funny part of Keploy’s comparison is how much effort it spends differentiating itself from a Speedscale installation we couldn’t perform. The useful part is the reminder to verify product claims against a working setup.
When evaluating Speedscale traffic replay or Keploy, ask:
- What sits in my application’s traffic path during recording?
- Which certificates or trust stores must change for my TLS stack?
- What requires source changes, configuration changes, or a restart?
- Can I run it locally, and what requires a cluster?
- Which protocols support capture and replay in the edition I’d buy?
- What happens to application traffic and captured data when the recorder falls behind?
Then ask the vendor to demonstrate the answers against your application. Start with the Speedscale quick start, record a representative interaction, and verify the requests, responses, and dependency mocks. A replay you can inspect tells you more than another confident comparison table.