Toxiproxy

Toxiproxy is a TCP proxy for injecting network faults into development, tests, and CI. It suits developers who need repeatable control over individual connections rather than a broad, scheduled chaos programme. Its focused scope and free, MIT-licensed distribution make it a practical choice for testing failure handling, provided its unauthenticated API is kept off untrusted networks.

Overview

Applications send test traffic through Toxiproxy, then an HTTP API or command-line interface changes how those connections behave. That makes it useful for checking whether an application handles disrupted dependencies without requiring those disruptions in production. The approach is deliberately connection-level: Toxiproxy is not a cloud fault-injection service or a Kubernetes platform.

Testing can be deterministic or randomized. Teams can apply specific conditions for repeatable cases, or introduce variability through settings such as jitter, packet loss, and toxicity probability. This combination is valuable in development and CI, though teams seeking experiment scheduling or cloud-level injection will need a different class of tool.

Key features

• Connection faults: Built-in toxics add latency or jitter, constrain bandwidth or transmitted data, delay socket closure, time out or reset connections, slice TCP data, and drop packets. This gives developers a varied set of failure modes without changing the application’s upstream service.
• HTTP API and CLI: The API creates, updates, lists, and deletes proxies and toxics, resets proxies, and returns version information and Prometheus-compatible metrics at /metrics. Its breadth suits automated test setup and teardown; the API listens on port 8474.
• Client libraries: Libraries are available for Ruby, Go, Python, .NET, PHP, Node.js, Java, Haskell, Rust, and Elixir. That range helps teams integrate fault controls into tests in many languages, but library compatibility matters: version 2.x changed the API incompatibly with 1.x.
• Flexible installation: Linux packages and binaries, Homebrew and MacPorts for macOS, a Windows download, a GitHub Container Registry image, and a Go source build cover common development and self-hosted environments.

A proxy configured with listen port 0 receives an ephemeral port, which is convenient for tests that need an assigned port. For other setups, the project advises avoiding the ephemeral port range to reduce random conflicts.

Pricing

Toxiproxy costs nothing. Its free plan is the open-source TCP proxy under the MIT license, with no trial period or paid tier described. That makes it accessible to individual developers and teams that can operate it themselves; there is no hosted service or paid support tier to choose instead.

Platforms

Toxiproxy supports API, Linux, macOS, self-hosted, and Windows environments. Its self-hosted deployment options and multiple installation routes suit teams integrating it into their own test infrastructure. It supports network fault injection and blast-radius controls, but not Kubernetes support, cloud fault injection, or experiment scheduling.

Who it's for

Choose Toxiproxy when developers or test teams need to verify how services behave under TCP connection failures in unit tests, integration tests, development, or CI. It is especially relevant when the failure cases should be repeatable and controlled through code. Look elsewhere if the requirement is a wider operational programme built around Kubernetes, cloud fault injection, or scheduled experiments.

Security needs deliberate handling. The HTTP API is unauthenticated by default and can create proxies to arbitrary upstreams, so it should not be exposed to untrusted networks. Bearer token authentication is supported, but teams still need to manage API access as part of deployment.

Pros and cons

• Pro — precise TCP fault controls: Latency, resets, timeouts, bandwidth limits, and packet drops let teams exercise concrete dependency-failure cases.
• Pro — automation-friendly interfaces: An HTTP API, CLI, language clients, and Prometheus-compatible metrics fit naturally into test workflows.
• Pro — no license cost: The free MIT-licensed project can be self-hosted across Linux, macOS, and Windows-oriented environments.
• Con — narrow operational scope: No Kubernetes support, cloud fault injection, or experiment scheduling makes it a poor fit for teams seeking a full chaos-engineering platform.
• Con — API exposure risk: The unauthenticated default API can configure arbitrary upstream proxies, requiring careful network isolation or bearer-token authentication.
• Con — version matching is essential: The incompatible API change between 1.x and 2.x means the client library must support the server version in use.

Alternatives

For a broader range of chaos-engineering tools, browse Chaos Engineering Platforms. Consider these alternatives when Toxiproxy’s TCP-focused scope is not the right match:

• Chaos Toolkit is another free, open-source option, with a free-forever CLI under Apache License 2.0 and API, desktop, self-hosted, web, and Windows platforms.
• ChaosBlade is a free alternative with support for three system platforms, four programming-language applications, and more than 200 experiment scenarios.
• Reliably is a freemium, open-source option whose approach avoids lock-in; its free plan costs nothing for one team member.
• Krkn is another free option, available across API, Linux, self-hosted, and web environments.
• Chaos Mesh is a free, open-source cloud-native chaos engineering platform that runs on Kubernetes, making it the more relevant choice for Kubernetes-focused teams.
• chaosd is a free Apache-2.0-licensed alternative distributed as a Linux binary, with a glibc v2.17-or-later requirement.
• FaultMesh offers a free Starter plan for up to three services, with core fault types, basic resilience scoring, and community support; it also has a $49 a month Growth plan.
• LitmusChaos offers both a free hosted SaaS plan and a free open-source option for installation on a cluster.

Verdict

Toxiproxy is a strong fit for developers who need free, controllable TCP fault injection in tests and CI. Its combination of deterministic and randomized connection tampering is the main reason to choose it; its narrow scope and security-sensitive API are the reasons to look elsewhere when you need a broader platform or cannot safely isolate its control interface.