Load test a Docker container

The fastest way to test a container is to run it the way production runs it. Stresix creates a server, pulls your image, runs it, waits until it answers, then ramps simulated users from a second server in the same datacenter.

Stresix run preview chart
A Stresix run preview: virtual users, requests per second, and p95 latency over ten minutes.

How a run starts

You give Stresix a Docker image or a repository. An image is pulled onto the target server and started with your port. A repository is built first, from its Dockerfile if it has one and with Nixpacks if not, in an isolated container with memory and CPU limits, and then run the same way. The PORT environment variable is set to the port you choose.

Waiting for your app

Before any load is sent, the load server checks that your app answers, waiting up to five minutes for it to boot. If it never answers, the run stops with a specific reason (for example, that nothing answered on the ports it tried, or that it only returned server errors) and your credit is refunded.

What is and is not on the same server

Your app runs alone on its own server; the load comes from a separate one. Both sit on a private network in one datacenter, so the measurement reflects your server, not the internet between your users and you.

Time limit

Every run has a fixed window. At the end the test stops, your results are saved and both servers are deleted.

What runs where
# What Stresix runs on the target server (simplified)
docker pull your-image:tag
docker run --network host --env PORT=<your port> your-image:tag

# Then, from a second server on the same private network:
#   users ramp from 0 to N over 75% of the window, then hold
#   each user sends the requests you listed (GET paths, or full requests)

Frequently asked questions

Can I test a private Docker image?

Not directly today. Use a public image, or connect GitHub and test the repository, which Stresix builds for you.

Does Stresix build repositories automatically?

Yes. If the repository has a docker-compose file, the whole stack (app, database, cache) runs together on the test server. Otherwise it uses your Dockerfile if there is one, and Nixpacks otherwise. If the build cannot find a start command, it tells you what to add.

Can I test an app that needs a database?

Yes. Put the app and its database in a docker-compose file in the repository. Stresix builds the services that have a build section, pulls the rest (postgres, redis, mysql), runs them together on one private test server, sends the load to the service that publishes a port, and measures every service separately. Small config files mounted from the repo (an init.sql, an nginx.conf) are included; host paths and privileged settings are dropped.

Does it provide a database?

If your repository has a docker-compose file, yes: the database in it runs next to your app on the test server, fresh for every run. Otherwise your app reaches its database at the addresses you give it in environment variables, so point it at a test database. Values are encrypted while stored and deleted when the run ends.

What if my app takes a while to start?

It has up to five minutes. If it never answers, the run fails with the reason instead of measuring nothing.

Which port does it use?

The one you set when you configure the test. It also tries a few common ports (80, 3000, 5000, 8000, 8080) in case the app listens elsewhere.

Related guides

Stop guessing your specs. Start knowing them.

Point Stresix at a repo or Docker image and get a number you can deploy on, in one run. Your first run is free, no card.

Start a free load test