A high-performance load testing engine designed for standalone (CLI) or Kubernetes cluster-internal use.

Supports load generation with a pluggable architecture for HTTP, gRPC and Kafka engines.

Configuration is loaded from a YAML file. The file location is resolved in priority order:

1. --config-file CLI flag
2. CONFIG_FILE environment variable
3. Default path: /etc/taiko/config.yaml

The HTTP engine sends requests to one or more HTTP endpoints. Multiple targets are supported simultaneously, each with its own URL, method, headers, body, and target RPS. A worker pool is automatically scaled up or down every 2 seconds to match the configured RPS across all targets, with weighted target selection proportional to each target's RPS share.

engine: http
targets:
  - url: http://localhost:8081/api/endpoint?id={{id}}
    method: POST
    timeout: 5s
    body: '{}'
    headers:
      Content-Type: application/json
    rps: 500
load:
  duration: 1m
metrics:
  type: console
variables:
  - name: id
    type: uuid

The gRPC engine calls unary RPC methods on one or more gRPC services. Service schema is resolved either from .proto source files (compiled at startup) or via gRPC server reflection when no proto files are provided. Multiple targets are supported, each pointing to a different endpoint or method, with workers automatically scaled to hit the configured RPS.

engine: grpc
targets:
  - endpoint: localhost:9090
    service: taiko.TaikoService
    method: Taiko
    proto_files:
      - examples/taiko.proto
    payload: '{"message": "{{user_id}}"}'
    metadata:
      x-request-id: "{{uuid}}"
    rps: 10
    timeout: 5s
load:
  duration: 60s
variables:
  - name: user_id
    type: uuid

The Kafka engine produces messages to one or more Kafka topics. A single shared producer client is used across all targets, with broker addresses pooled from all target definitions. Multiple targets are supported, each with its own topic, key, value template, and RPS. Workers are automatically scaled to match the configured message throughput.

The Kafka engine optionally supports Avro serialization with Confluent Schema Registry. When configured, key and/or value templates are treated as JSON, encoded to Avro binary using the specified schema, and (when fetched from a registry) prepended with the Confluent wire format header (0x00 + 4-byte schema ID).

schema_registry fields:

key_schema / value_schema fields (specify either subject or file, not both):

engine: kafka
targets:
  - brokers: ["localhost:9092"]
    topic: taiko
    key: "{{user_id}}"
    value: '{"event": "click", "user": "{{user_id}}", "timestamp": "{{timestamp}}"}'
    rps: 5
load:
  duration: 10s
variables:
  - name: user_id
    type: uuid
  - name: timestamp
    type: timestamp
    generator:
      format: rfc3339

engine: kafka
targets:
  - brokers: ["localhost:9092"]
    topic: user-events
    key: "{{user_id}}"
    value: '{"id": "{{event_id}}", "user_id": {{user_id}}, "action": "click"}'
    rps: 500
    schema_registry:
      url: "http://schema-registry:8081"
    value_schema:
      subject: user-events-value
load:
  duration: 60s
variables:
  - name: user_id
    type: int_range
    generator: { mode: rnd, min: 1, max: 1000000 }
  - name: event_id
    type: uuid

Variables let you inject dynamic values into request payloads at runtime. They are defined under the top-level variables key and referenced anywhere in a payload using {{variable_name}} placeholders. Substitution is applied per-request and is supported across all engines:

• HTTP: url and body fields
• gRPC: payload and metadata values
• Kafka: key, value, and headers values

Each variable has a name, a type, and an optional generator block with type-specific parameters.

mode: seq cycles through values sequentially (thread-safe); mode: rnd picks randomly on each request.