How do I run integration tests without Docker in CI?

Record your containerised service once with its Compose stack up, then replay in CI. Because dependency responses come from the recording, the test runs as a plain process with no Docker runtime in the job.

Is Keploy a Testcontainers alternative?

For replay, yes. Testcontainers starts real images in every job and needs a Docker-API-compatible runtime. Keploy records those dependencies once and replays them with neither. Keep Testcontainers for exploring unrecorded behaviour.

Do I need to change my Dockerfile to use Keploy?

No. Keploy records at the socket inside the container, so there is no entrypoint wrapper to add, no layer to install, and no change to the image you ship to production.

Can Keploy replace a docker-compose test stack?

For test runs, largely yes. The stack is needed while recording, and replay answers those calls itself — so docker-compose.test.yml stops being a per-job dependency and its healthcheck ordering stops mattering.

Does Keploy work on runners that disallow privileged containers?

Yes, and this is a common reason to use it. Replay is an ordinary process with no Docker socket and no privileged mode, so integration tests can run on hardened runners that rule out Testcontainers.

Is Keploy free to use with Docker?

Yes. The Keploy CLI is open source under Apache 2.0 and free to run on any container with no seat limits. Paid cloud plans add hosted test storage, dashboards, and team management.

Keploy as a Docker testing framework

Keploy records traffic inside a running Docker container, capturing the requests a service serves and every downstream call it makes, then replays them in CI. The resulting tests need no Compose stack, no Testcontainers, and no Docker daemon in the runner.

Generate Docker tests free

keploy record -c "docker compose up orders"

18.4K+

1.2M+300M+mocks createdSlack

What Keploy gives a Docker team

Any image, any language

Keploy records inside the container at the socket layer, so the base image, language, and framework do not matter. A Compose service, a standalone container, or a plain binary all record the same way.

Any base image or runtime
Compose services and standalone containers
No Dockerfile change
No entrypoint wrapper in the image

Try Keploy for free Explore the docs

The problem

Why Docker integration tests slow teams down

The friction is rarely the assertions. It is everything around them — spinning up dependencies, keeping mocks honest, and repairing tests after every refactor.

Book a call Explore the docs

Three ways to do it

Testing Docker: by hand, with Docker Compose + Testcontainers, or with Keploy

Compose and Testcontainers start a real stack in every job and need a Docker runtime to do it. Keploy records that stack once and replays it as a plain process.

By hand

Docker Compose + Testcontainers

With Keploy

Select any row for the full comparison, with code.

Get started Book a call

Same coverage, three costs

What you write for Docker vs what Keploy records

All three produce the same assertion. Only the third still passes after the next refactor without anyone editing it.

By hand2–4 hours

deps_fakes.js

hand-written

// Hand-written: one fake per containerised dependency.

// Three services in Compose become three fakes to maintain.

exports.fakePostgres = {

query: async () => ({ rows: [{ id: 'ord_1', amount_minor: 4200 }] }),

};

exports.fakeRedis = {

// Always a hit, so the miss path is never exercised.

get: async (key) => JSON.stringify({ state: 'NEW' }),

setex: async () => 'OK',

};

exports.fakeKafka = {

// No serialiser runs, no partition is chosen, no offset returns.

send: async () => [{ partition: 0, baseOffset: '0' }],

};

Three fakes standing in for three images, each encoding a guess about behaviour nothing verifies against the real container.

Docker Compose + Testcontainers1–2 hours

docker-compose.test.yml

tool-assisted

# A test stack: real images, started in every job.

services:

orders:

build: .

depends_on:

postgres: { condition: service_healthy }

redis: { condition: service_started }

kafka: { condition: service_healthy }

postgres:

image: postgres:16

healthcheck:

test: ["CMD-SHELL", "pg_isready -U postgres"]

interval: 2s

retries: 15

redis:

image: redis:7

kafka:

image: confluentinc/cp-kafka:7.6.0

healthcheck:

test: ["CMD", "kafka-topics", "--bootstrap-server", "localhost:9092", "--list"]

interval: 5s

retries: 20

Genuine fidelity, and a second deployment definition to maintain — plus four image pulls and two healthcheck loops before the first assertion.

With Keploy~5 minutes

ci-replay.yml

auto-generated

# Replay recorded container traffic — no daemon needed.

name: integration

on: [pull_request]

jobs:

replay:

runs-on: ubuntu-latest

steps:

- uses: actions/checkout@v4

- name: Install Keploy

run: curl -sSL https://keploy.io/install.sh | bash

- name: Build

run: npm ci && npm run build

# No Compose, no image pulls, no healthcheck waits.

- name: Replay

run: keploy test -c "node dist/server.js" --delay 8

The recording already contains Postgres, Redis, and Kafka responses, so this job exercises the same paths without starting a single container.

Times are estimates for authoring one endpoint’s coverage from scratch, not measurements.

Explore the docs Request a trial

Keploy vs the alternatives

Docker testing tools, compared

The options a team on service and platform integrations actually reaches for, and where each one genuinely wins. Select a row for the full comparison.

Keploy

WireMock

LocalStack

Mountebank

Hoverfly

Postman

SmartBear ReadyAPI

Best in classStrongPartialNot covered

Assessments reflect each tool’s documented behaviour, not benchmark measurements.

Request a trial Book a call

How it works

Record your Docker app once, replay it forever

Keploy sits below your Docker process at the network layer. It watches the calls your app already makes, then serves them back on replay so tests run with no dependencies attached.

Your Docker appGET/api/v1/orders/{id}200

RecordingKeploy proxyeBPF · userspace

PostgreSQLPostgres protocol to a linked container

MySQLMySQL protocol to a linked container

RedisRESP to a linked container

MongoDBWire protocol to a linked container

+3 more Docker dependencies

An example shape of a captured call. Your own endpoints and dependencies come from your real traffic, so nothing here has to be written by hand.

Try Keploy for free Request a trial

Mock coverage

What Keploy mocks for Docker, with zero config

7 of the 7 dependencies a typical Docker service talks to are stubbed from the recording itself — no mock classes, no fixture files, no containers in CI.

Auto-mocked
PostgreSQLView page
Postgres protocol to a linked container
Auto-mocked
MySQLView page
MySQL protocol to a linked container
Auto-mocked
RedisView page
RESP to a linked container
Auto-mocked
MongoDBView page
Wire protocol to a linked container
Auto-mocked
Apache KafkaView page
Kafka protocol to a linked broker
Service-to-service HTTP
Auto-mocked
Service-to-service HTTP
Any call between Compose services
Auto-mocked
gRPCView page
HTTP/2 framed calls between containers

Explore the docs Book a call

Quick start

Your first Docker test suite in under five minutes

Every command below runs against your existing Docker service. Nothing in your source tree changes.

1
1Install the Keploy CLI
A single binary. It needs a Linux kernel with eBPF support, or Docker on macOS and Windows — and it adds nothing to your project's dependencies.
curl -sSL https://keploy.io/install.sh | bash
2
2Record your service
Pass the command you already use to start the app. Keploy runs it and watches every socket it opens.
keploy record -c "docker compose up orders"
3
3Exercise the paths you care about
Record once with your Compose stack up. Every database, cache, and broker call the request triggered is captured, so later runs need none of them.
docker compose up -d postgres redis kafka
curl -X POST localhost:8080/orders/ord_1/confirm -d '{"paymentToken":"tok_123"}'
4
4Replay in CI
Replay serves the recorded dependency responses, so the job needs no service containers and no Docker daemon.
keploy test -c "node dist/server.js" --delay 8