Open-Source Testing · alexei-led

pumba

Pumba is a chaos engineering tool that injects controlled failures into containerized environments (Docker, containerd, Podman) to test system resilience. It can kill, stop, pause containers, simulate network problems, and stress-test resources—helping teams find weaknesses before production outages.

Talk to DEV.co Discuss Implementation

Source: GitHub — github.com/alexei-led/pumba

3.1k

GitHub stars

215

Forks

Primary language

Apache-2.0

License (OSI-approved)

Key facts

Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.

Field	Value
Repository	alexei-led/pumba
Owner	alexei-led
Primary language	Go
License	Apache-2.0 — OSI-approved
Stars	3.1k
Forks	215
Open issues	16
Latest release	1.1.7 (2026-05-05)
Last updated	2026-07-03
Source	https://github.com/alexei-led/pumba

What pumba is

Pumba uses container runtime APIs (Docker socket, containerd gRPC, Podman compat API) to target and disrupt containers, and leverages Linux kernel primitives (network namespaces, cgroups v2, tc/iptables, stress-ng) to inject chaos at the network and resource layers. It runs as a CLI tool on Linux, with macOS support for remote driver scenarios.

Quickstart

Get the pumba source

Clone the repository and explore it locally.

terminalbash

1git clone https://github.com/alexei-led/pumba.git2cd pumba3# follow the project's README for install & configuration

Need it deployed, integrated, or customized instead? DEV.co ships production installs.

Best use cases

Kubernetes cluster resilience testing

Verify that workloads survive container kills, network delays, and packet loss in staging/test clusters before promoting to production.

Multi-container local development

Inject faults into Docker Compose or containerd setups to catch integration issues and improve error handling during development.

Site reliability engineering validation

Automate routine chaos runs (kill, pause, stress) on a schedule to catch undeclared dependencies and validate failover mechanisms.

Implementation considerations

Requires runtime socket access (Docker: `/var/run/docker.sock`, containerd: `/run/containerd/containerd.sock`, Podman: requires rootful). Ensure socket permissions are correct and containers have necessary binaries (tc, iptables, stress-ng) for network and stress chaos.
Network chaos (netem, iptables) injects a sidecar helper container or executes directly in the target namespace—verify the target image includes necessary Linux utilities and the runtime supports privileged execution or namespace sharing.
Stress testing uses cgroups v2 and stress-ng; check kernel version (v5.8+) and cgroup configuration. Child-cgroup injection is default; same-cgroup injection requires matching process privileges.
Targeting is regex-based (re2:), label-based, or random; test your filters carefully in dry-run or low-risk environments first to avoid unintended container disruption.
Scheduling via `--interval` enables recurring chaos. Plan intervals to avoid cascading failures in dependent services; start with longer intervals and reduce after validation.

When to avoid it — and what to weigh

Windows container environments — Windows is explicitly not supported and will not be. Chaos primitives (netns, cgroups, tc, iptables, POSIX signals) are Linux-only with no planned Windows implementation.
Rootless Podman workflows — netem, iptables, and stress require rootful Podman. Rootless mode fails fast, requiring either escalation to rootful or architectural redesign.
Non-Linux container runtimes — Pumba targets Linux containers only. macOS deployment requires remote access to a Linux VM (e.g., Colima, podman machine) or Docker Desktop with WSL2.
Production live-fire chaos without extensive testing first — Chaos tools can impact availability. Validate targeting, filtering, and interval logic thoroughly in staging before deploying to production.

License & commercial use

Apache License 2.0 (Apache-2.0). Permissive OSI-approved license allowing commercial use, modification, and redistribution under the same terms. Requires preservation of copyright and license notices.

Apache-2.0 is a permissive open-source license suitable for commercial deployment. You may use, modify, and redistribute Pumba in proprietary products provided you include Apache-2.0 license text and copyright notices. No warranty or liability guarantees are provided; review the LICENSE file for full terms. Consider the maintainer's support model (community-driven GitHub project) when planning production support.

DEV.co evaluation signals

Editorial assessment — not user reviews. Directional, with an explicit confidence level.

Signal	Assessment
Maintenance	Active
Documentation	Adequate
License clarity	Clear
Deployment complexity	Moderate
DEV.co fit	Good
Assessment confidence	High

Security considerations

Pumba requires privileged or near-privileged access to container runtime sockets and must execute privileged operations (network namespace writes, cgroup manipulation, tc/iptables commands). Ensure the Pumba process/container is restricted to trusted users and networks; socket bind-mounts grant broad container control. Audit targeting logic to prevent accidental disruption of production workloads. No security audit details or vulnerability disclosure policy are documented; review the GitHub issues for known concerns.

Alternatives to consider

Chaos Mesh

Kubernetes-native chaos engine with CRD-based configuration, multi-namespace support, and built-in UI. Better suited for Kubernetes environments; requires Helm/Operator deployment.

Gremlin

Commercial SaaS chaos platform with guided scenarios, blast-radius controls, and managed workflows. Easier for teams without DevOps expertise; requires external account and licensing.

Litmus

Open-source Kubernetes chaos engine with declarative experiments, metrics integration, and GitOps workflows. Similar to Chaos Mesh; strong for Kubernetes; weaker for non-K8s container chaos.

Software development agency

Build on pumba with DEV.co software developers

Start with the quick-start guide, deploy a release binary or Docker image, and run your first chaos scenario in staging. Join the community to share learnings and contribute improvements.

Talk to DEV.co

Related open-source tools

Surfaced by semantic similarity across the DEV.co open-source index.

stern testing-distributed-systems podinfo

Related on DEV.co

Explore the category and the services that help you build with it.

Open-Source Testing DevOps Cloud deployment API development Talk to DEV.co

pumba FAQ

Can I run Pumba on Windows to target Windows containers?

No. Pumba explicitly does not support Windows and never will. It relies on Linux kernel primitives (netns, cgroups, tc, iptables, POSIX signals) with no Windows equivalent. Run Pumba on Linux (native, container, or VM) to target Linux containers.

Do I need to modify my container images to use Pumba?

Not for basic chaos (kill, stop, pause, restart). For network chaos (netem, iptables) and stress testing, target containers should include tc, iptables, and stress-ng binaries, or Pumba can inject a helper sidecar. Check your image contents and runtime configuration.

How do I prevent Pumba from accidentally disrupting production?

Use precise targeting (regex, labels, or explicit names), dry-run/test filters in staging first, set reasonable `--interval` values, and restrict socket access to trusted processes/users. Start with non-destructive actions (exec, ps) and increase destructiveness gradually.

Does Pumba work with Kubernetes?

Pumba is a CLI tool, not a Kubernetes-native operator. You can run it as a sidecar, external job, or container in a cluster to target workloads, but it lacks CRD support, scheduled experiments, and Kubernetes-aware filtering. For Kubernetes chaos, consider Chaos Mesh, Litmus, or Gremlin.

Custom software development services

Need help beyond evaluating pumba? DEV.co is a software development agency offering software development services and web development for teams of every size. Our software developers and web developers build custom software, web applications, APIs, and open-source testing integrations — and maintain them long-term.

Ready to chaos-test your containers?

Start with the quick-start guide, deploy a release binary or Docker image, and run your first chaos scenario in staging. Join the community to share learnings and contribute improvements.

Talk to DEV.co Schedule a Consultation