Toxiproxy

Toxiproxy is a free, self-hosted TCP proxy for developers checking how applications behave when connections fail or degrade. It is a strong fit for targeted tests in development and CI, but not for teams that need scheduled experiments or cloud-wide fault injection.

Overview

Route test connections through Toxiproxy, then change their behavior through its HTTP API or command-line interface. That gives developers a way to exercise failure handling without changing the application’s upstream service. Its scope is deliberately narrow: it manipulates TCP connections rather than orchestrating broad infrastructure experiments.

Tests can apply deterministic changes for repeatable cases or use randomized behavior, including jitter, packet loss, and toxicity probability. The former makes specific failure scenarios easier to reproduce; the latter can expose less predictable edge cases. Toxiproxy is self-hosted, with no Kubernetes support, cloud fault injection, or experiment scheduling.

Key features

• Connection fault controls: Built-in toxics can add latency or jitter, restrict bandwidth or transmitted data, delay socket closure, time out or reset connections, slice TCP data, and drop packets. That is a useful range for testing how an application responds to disrupted dependencies, though it remains focused on TCP connection behavior.
• HTTP API and CLI: The API can create, update, list, and delete proxies and toxics, reset proxies, and return version and Prometheus-compatible metrics. A proxy configured with listen port 0 receives an ephemeral port; the API itself listens on port 8474. The project advises choosing ports outside the ephemeral range to reduce random conflicts.
• Language clients: Client libraries are available for Ruby, Go, Python, .NET, PHP, Node.js, Java, Haskell, Rust, and Elixir, which can make it easier to manage test proxies from different application stacks. Toxiproxy 2.x has API changes incompatible with 1.x, so the client library must support the server version in use.
• Deployment choices: Install options include Linux packages and binaries, Homebrew or MacPorts on macOS, a Windows download, a GitHub Container Registry image, and building from Go source. This gives teams several ways to fit it into self-hosted development and CI environments.
• Security controls: The API is unauthenticated by default and can create proxies to arbitrary upstreams, making unrestricted network exposure risky. Toxiproxy supports bearer token authentication, and its API should be kept away from untrusted networks.

Pricing

Toxiproxy is free: its Toxiproxy plan costs nothing and includes an open-source TCP proxy under the MIT license. There is no paid tier or trial to weigh against a free allowance, and no seat or usage cap is stated. The trade-off is operational rather than financial: teams run it themselves and must secure the API and manage compatibility between server and client versions.

Platforms

Toxiproxy supports API, Linux, macOS, Windows, and self-hosted deployment. Installation options include packages or binaries for Linux, Homebrew and MacPorts for macOS, a Windows download, a container image, and a Go source build. It supports network fault injection, but not Kubernetes or cloud fault injection.

Who it's for

Developers and teams testing service failure handling in development, unit and integration tests, or CI will get the most from Toxiproxy. It is particularly suitable when a test needs repeatable control over a dependency’s TCP connection. Teams seeking scheduled experiments, Kubernetes support, or fault injection across cloud infrastructure should look elsewhere.

Pros and cons

• Pro: A varied set of connection faults supports testing latency, bandwidth limits, resets, timeouts, packet loss, and other failure modes without changing the application’s upstream.
• Pro: Deterministic controls and randomized behavior serve both repeatable test cases and less predictable chaos scenarios.
• Pro: Multiple language clients and installation routes make it adaptable to different development and CI setups.
• Con: Its TCP proxy focus does not cover Kubernetes, cloud fault injection, or experiment scheduling.
• Con: The default unauthenticated API can configure proxies to arbitrary upstreams, so it requires careful network isolation or bearer token authentication.
• Con: API incompatibility between versions 1.x and 2.x requires matching the client library to the server.

Alternatives

For a broader set of chaos-engineering options, browse Chaos Engineering Platforms. Consider these alternatives when their stated approach or deployment scope better matches the work:

• Reliably is an open-source option for readers who want its stated approach of avoiding lock-in; its free plan includes one team member.
• Chaos Toolkit is a free, open-source CLI under Apache License 2.0 for readers who prefer a command-line tool.
• ChaosBlade is a free, open-source tool for readers looking for support across multiple system platforms, programming-language applications, and experiment scenarios.
• Krkn is another free option for readers considering a self-hosted tool.
• Chaos Mesh is a free, open-source cloud-native chaos engineering platform for readers running Kubernetes.
• Krkn-AI is a free, open-source option under Apache License 2.0 for readers considering Linux self-hosting.
• LitmusChaos offers a free hosted SaaS plan as well as a free open-source option for installation on a team's own cluster.
• Pumba is a free, open-source container chaos testing tool for readers focused on container testing.

Verdict

Choose Toxiproxy if your team needs a free, self-hosted way to control TCP failures in development, tests, or CI. Its broad connection-level fault controls and language clients make it a practical fit for that work. Look elsewhere if you need Kubernetes or cloud fault injection, scheduled experiments, or a broader chaos-engineering platform; whichever route you choose, keep Toxiproxy’s API protected and align the client library with the server version.