The 132 passing tests cover the recorder's repository
Keploy's 132 passing repository tests sit behind a simple promise: put the agent around an application, exercise real API paths, then keep the resulting calls as tests and dependency mocks. Its eBPF capture works at the network layer, so the application does not need a Keploy SDK. The README says it can record HTTP, database traffic, Kafka, RabbitMQ, and other dependencies. That makes it broader than a mock HTTP server and potentially more useful for integration suites that currently need a crowded Docker Compose file.
Our repository run passed all 132 Go tests, which is a solid result for the recorder's own code. It does not prove that your service's protocol mix will replay correctly. A captured test contains assumptions about matching, ordering, time, and which fields may vary. Keploy can freeze time and supply generated mocks, but a team still has to inspect the first recordings and decide whether a passing replay represents the business behavior it cares about.
An 802-package install led to a clean build
Our fresh Debian sandbox installed commit 037dcfd in 86 seconds and covered 802 packages. Compilation took 194 seconds. The checkout itself contained 1,100 files, about 300,198 lines of source, and occupied 12.9 MB. That is a substantial Go project, yet the setup did not stall or require secrets. The repository also had a Dockerfile, a tests directory, and 52 CI workflow files in our scan.
The quick start is shorter than the operating setup. You install the agent, launch the application through keploy record, send traffic, and later run it through keploy test. Those commands need the application command, its reachable dependencies during capture, and storage for generated YAML tests and mocks. A developer can try that locally. CI adoption also needs fixture review, stable paths, artifact retention, and a policy for refreshing recordings when an API intentionally changes.
What happened when we ran it
Our run built Keploy successfully in 194 seconds, then go test completed in 271 seconds with 132 passed and 0 failed out of 132. The sandbox had 3 CPUs, 8 GB of RAM, Go 1.24 on Debian, no secrets, and no elevated privileges. Installation had already succeeded in 86 seconds. Our test method covered repository setup, compilation, and its Go suite, not end-to-end traffic capture.
We did not grant the container eBPF capabilities, start a sample API under Keploy, or replay calls against Postgres, Kafka, or RabbitMQ. That boundary matters because the product's value begins where our repository test stops. The clean 132-test result earns confidence in the codebase, while protocol behavior and host permissions still need a pilot on the target environment. A one-service trial with a known failure is more useful than recording a large production trace first.
Open v3 reports put matcher output under scrutiny
Keploy v3.6.82 shipped on September 29, 2026, with a fix that keeps mocks after a partial or unanswered replay. Nearby open issues show why replay output deserves careful reading. Issue 4636 reports a case where the printed Testrun passed banner can disagree with the assertion verdict returned by the matcher. A related open pull request exists, but the issue remained open when checked.
The gRPC path has a more direct gap. Open issue 4609 says test-case assertions are decoded but not read by the gRPC matcher, so a case can pass regardless of the assertion values. HTTP users have a different concern: issue 4531 reports that five utility commands can log an error and still exit with status 0. Until those reports close in a release you have verified, CI should check machine-readable results or artifacts rather than trusting one banner or shell status.
Host access can stop capture before matching begins. Open issue 3832 shows Keploy v2.5.2 failing to attach tracepoints inside an unprivileged Docker container without CAP_BPF, CAP_NET_ADMIN, or CAP_SYS_ADMIN. It is an older report, so it does not prove every current container needs that exact capability set. It does prove that eBPF changes the deployment conversation. Test the current release under your runner's real security profile instead of assuming a successful binary install settles it.
The September 29 release shows an actively changing tool
GitHub listed 18,509 stars and 759 open issues and pull requests on September 30, 2026. The repository was pushed on September 29, the same day v3.6.82 was released. Current issues and pull requests were also active that week, including fixes around matcher verdicts, Postman import, and replay behavior. Keploy is being maintained quickly, which is reassuring for a low-level recorder but makes version pinning important.
Choose Keploy when its unusual strength matches the problem: one recording layer can replace several live dependencies during an integration run. WireMock is easier when only HTTP needs a stand-in, and Testcontainers is more faithful when a real database or broker is affordable. Keploy sits between those choices. Our 132 passing tests justify a serious pilot. Captured fixtures and independent business assertions belong in that pilot from the start.