Top Related Projects
Quick Overview
Pumba is a chaos testing tool for Docker environments. It allows users to simulate various network conditions, resource constraints, and failure scenarios to test the resilience and reliability of containerized applications. Pumba helps identify potential issues and weaknesses in distributed systems running on Docker.
Pros
- Easy to use and integrate into CI/CD pipelines
- Supports a wide range of chaos experiments, including network emulation, resource limits, and container manipulation
- Highly configurable with command-line options and YAML-based experiment definitions
- Active development and community support
Cons
- Limited to Docker environments, not suitable for other container runtimes or non-containerized applications
- May require careful configuration to avoid unintended consequences in production environments
- Documentation could be more comprehensive, especially for advanced use cases
- Limited built-in reporting and analysis features
Getting Started
To get started with Pumba, follow these steps:
-
Install Pumba:
docker pull gaiaadm/pumba -
Run a simple chaos experiment (e.g., kill a container after 30 seconds):
docker run -it --rm -v /var/run/docker.sock:/var/run/docker.sock gaiaadm/pumba pumba kill --signal SIGKILL --interval 30s re2:^myapp -
Create a YAML configuration file for more complex experiments:
version: "0.1" name: network-delay-experiment description: Add 100ms delay to all network traffic tasks: - name: add-delay containers: - re2:^myapp commands: - netem --duration 5m delay 100 -
Run the experiment using the YAML file:
docker run -it --rm -v /var/run/docker.sock:/var/run/docker.sock -v $(pwd)/experiment.yaml:/experiment.yaml gaiaadm/pumba pumba --log-level info chaos --config /experiment.yaml
For more advanced usage and configuration options, refer to the official Pumba documentation on GitHub.
Competitor Comparisons
:alarm_clock: :fire: A TCP proxy to simulate network and system conditions for chaos and resiliency testing
Pros of Toxiproxy
- Written in Go, offering better performance and cross-platform compatibility
- Provides a more extensive set of network fault injection capabilities
- Offers both a CLI and an HTTP API for easier integration into various workflows
Cons of Toxiproxy
- Primarily focused on network-level fault injection, lacking container-specific features
- Less suitable for Docker-centric environments compared to Pumba
- May require additional setup for use in containerized environments
Code Comparison
Toxiproxy (Go):
proxy := toxiproxy.NewProxy("mysql", "localhost:3306", "localhost:33306")
toxic := toxiproxy.NewLatencyToxic("latency", toxiproxy.Downstream, 1000)
proxy.AddToxic(toxic)
Pumba (Shell):
pumba netem --duration 10m delay --time 1000 re2:^mysql
Both tools aim to introduce network faults for testing purposes, but Toxiproxy offers a more programmatic approach with its Go API, while Pumba provides a simpler command-line interface tailored for Docker environments. Toxiproxy excels in fine-grained network fault injection, whereas Pumba offers broader container manipulation capabilities beyond just network simulation.
Simulating shitty network connections so you can build better systems.
Pros of Comcast
- Simpler setup and usage, focusing specifically on network condition simulation
- Lightweight and easy to install, with fewer dependencies
- Cross-platform support (Linux, macOS, and Windows)
Cons of Comcast
- Limited functionality compared to Pumba, focusing only on network chaos
- Less active development and community support
- Lacks container-specific features and Docker integration
Code Comparison
Comcast (network delay simulation):
comcast --device=eth0 --latency=250 --target-bw=1000 --default-bw=1000000 --packet-loss=10%
Pumba (network delay simulation):
pumba netem --interface eth0 delay --time 250 --jitter 30 --correlation 20 --distribution normal
Summary
Comcast is a simpler tool focused solely on network condition simulation, offering cross-platform support and easy setup. However, it lacks the broader chaos engineering capabilities and container-specific features provided by Pumba. Pumba offers a more comprehensive suite of chaos engineering tools, including network emulation, but with a focus on Docker environments. The choice between the two depends on the specific requirements of your testing environment and the breadth of chaos engineering scenarios you need to simulate.
Convert 
designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual CopilotREADME
Chaos testing tool for Docker, containerd, and Podman
Quick Start · User Guide · Network Chaos · Deployment · Contributing
Pumba is a chaos testing and network emulation tool for Docker, containerd, and Podman containers. Inspired by Netflix Chaos Monkey, Pumba brings chaos engineering to the container level â kill, stop, pause, and remove containers, inject network delays and packet loss, or stress-test container resources.
How It Works
graph LR
A[Pumba CLI] -->|Docker API / containerd API / Podman compat API| B[Container Runtime]
B -->|List & Filter| C[Target Containers]
A -->|kill / stop / pause / rm| C
A -->|netem / iptables| D[Helper Container / Direct Exec]
D -->|Shares network namespace| C
D -->|Runs tc / iptables| E[Network Chaos]
Supported runtimes
| Runtime | Socket (default) | netem / iptables / stress | Notes |
|---|---|---|---|
| Docker | /var/run/docker.sock | Works as root or with socket access | Default runtime. |
| containerd | /run/containerd/containerd.sock | Requires root (overlayfs mounts for sidecar) | Namespaces: k8s.io (Kubernetes), moby (Docker-managed), default (pure containerd). |
| Podman | /run/podman/podman.sock (rootful) | Requires rootful Podman (fails fast else) | Uses Podman's Docker-compat API; on macOS pumba runs inside podman machine (see below). |
Supported platforms
Pumba targets Linux containers â every chaos action depends on Linux primitives (netns, cgroups v2, iptables, tc qdiscs, container runtime sockets). Released binaries:
| OS | amd64 | arm64 | Notes |
|---|---|---|---|
| Linux | â | â | Primary target. Run pumba on the same kernel as the targeted containers. |
| macOS | â | â | Developer ergonomics only. Use it to drive a remote Docker/Podman/containerd VM (e.g. Colima, podman machine). |
| Windows | â | â | Not supported and not planned. See below. |
Windows is intentionally not built. The chaos primitives â Linux netns/cgroup writes, tc/iptables sidecar injection, POSIX signal forwarding (SIGCONT/SIGSTOP/SIGUSR1/SIGUSR2 used by the containerd runtime) â have no Windows equivalent. There is no plausible Windows use case even with Docker Desktop's WSL2 backend, so no Windows binary is published. PRs adding Windows support will not be accepted; please run pumba on Linux (native, container, or VM).
Features
| Category | Commands | Description |
|---|---|---|
| Container Chaos | kill, stop, pause, rm, restart | Disrupt container lifecycle |
| Execute | exec | Run commands inside containers |
| Network Delay | netem delay | Add latency to egress traffic |
| Packet Loss | netem loss, iptables loss | Drop packets (egress and ingress) |
| Network Effects | netem duplicate, corrupt, rate | Duplicate, corrupt, or rate-limit packets |
| Stress Testing | stress | CPU, memory, I/O stress via stress-ng (child cgroup or same-cgroup injection) |
| Targeting | names, regex (re2:), labels, --random | Flexible container selection |
| Scheduling | --interval | Recurring chaos at fixed intervals |
Quick Start
Install
Download the latest release for your platform, or use Docker:
# Binary
curl -sL https://github.com/alexei-led/pumba/releases/latest/download/pumba_linux_amd64 -o pumba
chmod +x pumba
# Docker (recommended)
docker pull ghcr.io/alexei-led/pumba:latest
First Chaos
# Kill a random container matching "test" every 30 seconds
pumba --interval=30s --random kill "re2:^test"
# Add 3 seconds network delay to mydb for 5 minutes
pumba netem --duration 5m delay --time 3000 mydb
# Drop 10% of incoming packets to myapp for 2 minutes
pumba iptables --duration 2m loss --probability 0.1 myapp
# Stress CPU of mycontainer for 60 seconds
pumba stress --duration 60s --stressors="--cpu 4 --timeout 60s" mycontainer
Containerd Runtime
# Kill a container by ID via containerd
pumba --runtime containerd --containerd-namespace k8s.io kill <container-id>
# Add network delay via containerd (requires tc in the container image)
pumba --runtime containerd --containerd-namespace moby \
netem --duration 5m delay --time 3000 <container-id>
Podman Runtime
Pumba talks to Podman via its Docker-compat socket. --podman-socket is optional â if empty, pumba probes $CONTAINER_HOST, $PODMAN_SOCK, podman machine inspect, /run/podman/podman.sock, and $XDG_RUNTIME_DIR/podman/podman.sock in order.
# Kill a container by name via Podman (rootful socket auto-detected)
sudo pumba --runtime podman kill mycontainer
# Add network delay via Podman (requires rootful socket)
sudo pumba --runtime podman netem --duration 5m delay --time 3000 mycontainer
# Stress CPU via Podman (default child-cgroup mode)
sudo pumba --runtime podman stress --duration 60s --stressors="--cpu 4 --timeout 60s" mycontainer
# Explicit socket override
pumba --runtime podman --podman-socket unix:///run/podman/podman.sock kill mycontainer
netem, iptables, and stress require rootful Podman â rootless fails fast with a clear message pointing at podman machine set --rootful (macOS) or the rootful systemd unit (Linux).
macOS development with Podman
Podman on macOS runs inside a Linux VM. Pumba must run on the same kernel as the target containers (host-side /proc/<pid>/cgroup read), so run the pumba binary inside the podman machine VM:
# one-time setup
brew install podman
podman machine init --rootful --cpus 4 --memory 4096 --now
podman machine ssh sudo dnf install -y bats # optional, for bats tests
# copy a linux/arm64 or linux/amd64 pumba binary into the VM
podman machine ssh sudo cp /path/to/pumba /usr/local/bin/
# run inside the VM
podman machine ssh sudo pumba --runtime podman --log-level debug ps
podman machine ssh sudo pumba --runtime podman netem --duration 10s delay --time 200 <container-id>
| Flag | Default | Description |
|---|---|---|
--runtime | docker | Container runtime (docker, containerd, or podman) |
--containerd-socket | /run/containerd/containerd.sock | containerd socket path |
--containerd-namespace | k8s.io | containerd namespace (k8s.io for Kubernetes, moby for Docker) |
--podman-socket | (auto-detected) | Podman socket URI (e.g. unix:///run/podman/podman.sock); empty triggers auto-detection |
Tip: For network chaos on containers without
tc/iptables, use--tc-imageto spawn a sidecar:pumba --runtime containerd netem --tc-image ghcr.io/alexei-led/pumba-alpine-nettools:latest \ --duration 5m delay --time 3000 <container-id>
Run with Docker
docker run -it --rm \
-v /var/run/docker.sock:/var/run/docker.sock \
ghcr.io/alexei-led/pumba --interval=10s --random kill "re2:^test"
Docker Images
| Registry | Image | Status |
|---|---|---|
| GitHub Container Registry | ghcr.io/alexei-led/pumba | â Primary |
| Docker Hub | alexeiled/pumba | â ï¸ Deprecated |
Images are built natively for linux/amd64 and linux/arm64 (no QEMU).
Documentation
| Document | Description |
|---|---|
| User Guide | Container chaos commands, targeting, scheduling, configuration |
| Network Chaos | netem, iptables, advanced scenarios, architecture diagrams |
| Stress Testing | CPU/memory/IO stress testing with stress-ng |
| Deployment | Docker, Kubernetes DaemonSets, OpenShift |
| Contributing | Build from source, run tests, project structure |
Demo
Community & Support
- Issues: GitHub Issues
- Blog: Pumba - Chaos Testing for Docker
License
Top Related Projects
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual Copilot