Keploy

Last reviewed Aug 26, 2026 · 788 words

Keploy hooks your running service at the kernel with eBPF, watches every HTTP request in and every Postgres, MySQL, MongoDB, Redis or outbound HTTP call it makes, and writes the whole exchange down as a YAML test plus a mock of the dependencies. Replay later and the test asserts your responses still match while the mocks stand in for the database, so the suite runs with no database at all. It needs no changes to your code, which is the entire pitch, and it needs Linux with root, which is the entire catch. For a self-hoster with a couple of homegrown services and no tests, it is the fastest route from zero to a regression suite I know of.

Record once, replay forever

curl --silent -O -L https://keploy.io/install.sh && source install.sh
# start your app under keploy, then exercise it with curl, a browser, a script
sudo keploy record -c "go run main.go"
# later, replay
sudo keploy test -c "go run main.go" --delay 10

record starts your app, intercepts its traffic, and writes keploy/test-set-0/tests/test-1.yaml and onwards for every request, with a mocks.yaml beside them capturing what the app asked its dependencies. test starts the app again with the mocks answering outbound calls, replays each recorded request, and diffs the response against the recording. --delay is the seconds to wait for the app to come up before firing; set it generously for anything on the JVM. Each recording session becomes a new test-set-N, so record one per feature and commit them next to the code.

The stack determines how smooth this is

The Go path is the most polished, then Java, Node and Python, which matches the project's origins. Dependency mocks are protocol-level, so the Postgres and MySQL wire protocols, MongoDB, Redis, gRPC and plain HTTP are understood; an unusual driver or a database not on that list gets recorded as opaque bytes and may not replay. Because interception is eBPF, the host needs a reasonably modern Linux kernel, root or equivalent capabilities, and the same applies inside Docker: the documented pattern for a containerised app is keploy record -c "docker compose up" --container-name api, with Keploy itself running privileged. On macOS or Windows you are running it inside a Linux VM one way or another; it works, and it takes longer to set up than the README implies. 256 MB is enough for the agent itself; the recorded app is the real memory user.

Noise is the failure mode, not false confidence

A recorded response contains timestamps, generated IDs and cache headers, and a naive replay fails on every one. Keploy has a noise mechanism: fields you mark (or that it detects as differing between two recordings of the same call) are ignored on comparison. Budget an hour after your first recording to go through the failures, mark Date, request IDs and anything derived from the clock as noise in the test YAML, and re-run. Tests that pass after that mean something. Tests you never de-noise become the thing everyone learns to ignore, which is worse than having none.

Where it sits next to Postman, Hoppscotch and WireMock

This is not an API client. Hoppscotch and Bruno are the Postman replacements for poking at endpoints by hand; Keploy is what turns the poking you already did into a suite. WireMock mocks HTTP dependencies you describe by hand; Keploy's mocks are derived from real traffic, database included, and you never write them. In CI the pairing is a Gitea or Forgejo runner with a privileged job step that runs keploy test, fails the build on a diff, and publishes coverage if your language's coverage tool is wired in. Keep the recorded YAML in the repository with the service it tests, and re-record a set whenever the API it covers intentionally changes.

What I'd do

Pick the one service you are most afraid to change, record 30 minutes of realistic use against it on a Linux box, de-noise until the replay is green, and wire keploy test into the pipeline that builds that service. Do not try to cover everything on day one; the value is highest on code with no tests and a database it talks to constantly. If your services run somewhere Keploy cannot intercept, or you need mocks for a third-party API you can describe better than you can record, WireMock and a normal test framework are the honest tools. For a typical homelab of Go and Node services on Docker, Keploy is the tests you were never going to write.