If you have searched for a way to get API tests without writing them by hand, you have probably run into Keploy. It promises something that sounds almost too convenient: point it at your running application, let it watch real traffic, and walk away with a test suite. So what is Keploy actually doing under the hood, and where does it fit in your testing stack?

This guide explains what Keploy is, how its record-and-replay engine works at the eBPF network layer, the two workflows it offers, how to install and run it, and the honest limits you should know before you adopt it.

What is Keploy

Keploy is an open-source platform (Apache-2.0 licensed) for creating safe, isolated production sandboxes for API, integration, and end-to-end testing. The core idea is that your real application already exercises the behavior you want to test. Instead of asking you to describe that behavior in test code, Keploy observes it and turns it into reproducible tests.

It gives you two ways to do that:

1. Record and replay captures real API interactions and their dependencies, then replays them deterministically.
2. AI test generation builds validated API test suites from a spec, a collection, a cURL command, or a live endpoint.

Both produce runnable tests plus the mocks needed to run them without hitting live dependencies. The project is open source, so you can read the code and self-host it. The repository lives at github.com/keploy/keploy, and the official docs are at keploy.io/docs.

How keploy record works at the eBPF layer

This is the part that makes Keploy distinct. When you run keploy record, it does not ask you to add an SDK or change a single line of your application code. It captures traffic at the network layer using eBPF, a Linux kernel technology that lets programs observe and act on system events safely.

Here is what that buys you in practice:

• Code-less capture. No instrumentation, no test harness, no decorators in your handlers. Keploy sits below your application and watches the bytes going in and out.
• Language-agnostic capture. Because the capture happens at the kernel network layer rather than inside a runtime, it works the same whether your service is written in Go, Python, or Rust.
• Dependency capture. Keploy does not only record the inbound API call and its response. It also records the outbound calls your service makes to its dependencies, like database queries and network or streaming events.

That last point matters. When Keploy records a request, it captures the full picture: the API request, the API response, and every dependency call that happened in between. It then writes two artifacts from that single observed interaction:

• A test case describing the expected request and response.
• Mocks and stubs for each dependency call, so the test can replay without a live database or downstream service.

Replay closes the loop. When you run keploy test, it sends the recorded requests back at your application, serves the captured dependency responses from the generated mocks, and compares the new responses against the recorded ones. A mismatch means something changed. This is why the approach is called record and replay: you record real runtime behavior once, then replay it deterministically as a regression test on every change.

The two Keploy workflows

Record and replay

Use this when you already have a working application and want regression coverage fast. You run the app under Keploy, exercise it the way a real user or client would (manual calls, an existing integration test, or live traffic), and Keploy banks each interaction as a test plus its mocks. Later runs replay those interactions and flag any behavioral drift.

AI test generation

Use this when you want broader coverage than your manual exercising produced, or when you are starting from a contract rather than a running flow. Keploy can generate validated API test suites from an OpenAPI spec, a Postman collection, a cURL command, or a live endpoint. It mocks dependencies automatically and runs an auto-cleanup pass so you are not left with redundant cases.

The two workflows are complementary. Record and replay anchors tests in real observed behavior; AI test generation fills gaps from your spec. If you are evaluating tools that generate tests from a schema, our roundup of AI test case generators and the guide to generating test scripts from OpenAPI are good companions.

Installing Keploy

Keploy ships an install script. On a supported system you run:

curl --silent -O -L https://keploy.io/install.sh && source install.sh

That fetches the binary and sets up the keploy command. From there you drive everything through two commands.

The core Keploy commands

There are two commands you will use most. The first records:

keploy record -c "CMD_TO_RUN_APP"

You pass the exact command that starts your application through -c. Keploy launches your app, watches the traffic while you exercise it, and saves the captured test cases and mocks.

The second replays:

keploy test -c "CMD_TO_RUN_APP" --delay 10

The --delay 10 flag tells Keploy to wait ten seconds before it starts firing recorded requests, which gives a slower service enough time to finish booting before the replay begins. If your app needs longer to come up, raise the number; if it boots fast, you can lower it.

A typical first session looks like this:

# 1. Record while you hit your API
keploy record -c "node server.js"

# 2. Replay the captured cases and check for drift
keploy test -c "node server.js" --delay 10

That is the whole loop. Record once against a known-good build, then run keploy test in CI on every change.

Supported languages, protocols, and datastores

Because capture happens at the network layer, Keploy covers a wide surface:

The breadth is a direct consequence of the eBPF design. Keploy is reading network conversations, so a new language or framework does not need a new plugin as long as it speaks one of these protocols.

Running Keploy in CI

Both commands are built for automation. In a pipeline you commit the recorded test cases and mocks alongside your code, then run keploy test -c "..." as a step. Because the mocks stand in for real dependencies, the replay does not need a live database or downstream service in the CI runner, which keeps the job fast and deterministic. A failing replay fails the build, the same way a unit test would.

Honest limitations to weigh

Keploy is strong at what it does, but it is not a fit for every situation. A fair assessment includes the trade-offs:

• It leans toward Linux and elevated privileges. eBPF is a Linux kernel feature, and capturing at that layer generally needs elevated permissions. That shapes where and how you can run it.
• Generated tests need curation. Tests built from real traffic or AI generation are a starting point, not a finished suite. You still review them, prune noise, and decide which captured behaviors are actually contracts worth enforcing.
• It is a testing and test-generation tool, not a full API lifecycle platform. Keploy focuses on capturing, generating, and replaying tests. It is not designed to handle API design, documentation, mock-server publishing for consumers, or team collaboration around an API spec.

None of these are knocks against Keploy. They are the natural boundaries of its category. Knowing them helps you decide whether it solves your problem or only part of it.

Where Apidog fits as the designed-testing alternative

If your need is broader than “turn observed traffic into regression tests,” it is worth looking at a full-lifecycle platform. Apidog is an all-in-one API platform that covers design, debugging, mocking, documentation, and testing in one place. The difference in philosophy is the key thing to understand, because Apidog and Keploy sit in different categories.

Keploy captures and replays real runtime behavior, including dependency mocks, with no code. Apidog takes the opposite path: you design and author maintainable test scenarios, then run them from the terminal and CI with the Apidog CLI. The CLI runs your authored collections with data-driven testing via CSV or JSON, environment switching, and CLI, HTML, and JSON reports. Apidog also offers AI test case generation from your API schema and endpoints, authored inside the app, which is where the two tools overlap.

To be clear about the boundary: Apidog does not capture live traffic via eBPF, and it does not auto-generate tests by recording production calls plus dependency mocks. That record-from-real-traffic capability is genuinely Keploy’s. The honest framing is that you pick based on the job. Reach for Keploy when you want runtime capture and replay with zero code. Reach for Apidog when you want designed, maintainable test suites inside a platform that also handles the rest of the API lifecycle. For a deeper side-by-side, see Apidog vs Keploy, and if you have decided to switch, the migration walkthrough covers moving your tests over.

If maintainable, authored API tests are what you are after, you can download Apidog and start with the guide to testing an API with Apidog.

Frequently asked questions

Is Keploy free and open source? Yes. Keploy is open source under the Apache-2.0 license, and the code is on GitHub. You can self-host it.

Does Keploy require changing my application code? No. The record-and-replay workflow captures traffic at the eBPF network layer, so there is no SDK to add and no code changes. That is also why it works across many languages.

What does the --delay flag in keploy test do? It sets how many seconds Keploy waits before sending recorded requests, giving your app time to boot. --delay 10 waits ten seconds; raise it for slow-starting services.

Can Keploy mock my database during tests? Yes. When it records an interaction, it also captures the dependency calls (such as database queries) and writes mocks for them, so replays run without a live database.

Is Keploy a replacement for an API design and documentation tool? No. Keploy is a testing and test-generation tool. For API design, documentation, mocking for consumers, and collaboration alongside testing, a full-lifecycle platform like Apidog is the better fit.

The short version

Keploy is an open-source tool that turns real API behavior into tests. Its record-and-replay engine uses eBPF to capture requests, responses, and dependency calls at the network layer with no code changes, then replays them as deterministic regression tests. Its AI test generation builds suites from a spec or endpoint. It is fast to adopt and language-agnostic, with the trade-offs of a Linux-leaning capture model, tests that need review, and a scope limited to testing. If you want authored, maintainable test suites inside a complete API platform, Apidog is the alternative to compare it against.