What you need
- Docker with Docker Compose version 2. Docker Engine on Linux or Docker Desktop both work. Podman works too: set
DOCKER_COMPOSE="podman compose"before you start. - For the one-command install: curl or wget. The installer checks only for Docker, Compose and one of these tools. It doesn’t check memory, disk or free ports, so check those yourself.
- To build from the code: Git, GNU Make and Bash. On Windows, use Git Bash or WSL.
- Free ports: 3000 for the web app, 8000 for the API, 5433 for PostgreSQL, 6379 for the job queue and 9000 for file storage. Only one copy of TestLookup can run on a machine.
- For a shared team server: any Linux machine with Docker. The project’s guides use Debian 12 as their example.
- For the command-line tool: Python 3.11 or later. The live reporters need Python 3.9 or later, Node.js 18 or later, Go 1.21 or Java 11. None of these are on package registries yet; your TestLookup server offers the command-line tool for download.
The getting started guide on GitHub has the same checklist.
How big a server you need
To try TestLookup, about 8 GB of free memory is enough for the core services. For a team, the project’s sizing guide gives three profiles. “Results per day” counts individual test results.
| Profile | Test results per day | Where it runs | CPU | Memory | Disk for one year |
|---|---|---|---|---|---|
| Small | up to 50,000 | one machine, Docker Compose | 4 vCPU | 8 GB | 100 GB SSD |
| Medium | up to 500,000 | one large machine or a small Kubernetes cluster | 8 vCPU | 16 GB | 500 GB SSD |
| Large | 1 million or more | Kubernetes | 16 or more vCPU (estimate) | 32 GB or more (estimate) | 1 TB or more NVMe (estimate) |
These profiles come from the shipped settings and estimates. Nobody has load-tested them yet. A few more planning numbers:
- Disk: plan for about 3 KB per test result (an estimate). At 50,000 results a day that is about 150 MB a day, or about 55 GB a year.
- Free space: keep at least twice the size of your PostgreSQL data free, for upgrades and backups.
- Downloads: the first start downloads a few GB of images. The offline bundle for sites without internet is about 3 GB and needs about 8 GB free to build.
The sizing guide on GitHub explains each figure.
Extra for local AI
TestLookup works without an AI model. If you add one on your own machine, plan for about 4 more vCPU, 8 GB more memory and 10 GB more disk. A graphics card with at least 8 GB of memory helps a lot. Without one, AI analysis still works but takes tens of seconds each time.
| Model | What it’s for | Download | Memory |
|---|---|---|---|
| qwen2.5:7b-instruct | the default analysis model | about 4.7 GB | about 8 GB |
| nomic-embed-text:v1.5 | the default model for similar-failure search | about 275 MB | about 1 GB |
| qwen2.5:14b-instruct-q5_K_M | a larger model, about twice as slow | about 11 GB | about 16 GB |
| qwen2.5:32b-instruct | the largest option; only sensible with a graphics card | about 20 GB | 32 GB or more |
The guides differ a little: some list the default model at about 5 GB and 6 to 8 GB of memory. The make dev-llm command downloads the default, the 14B model and the search model, about 16 GB in total. The offline model pack guide lists every model.
On Kubernetes or OpenShift
TestLookup ships ready-made setups for standard Kubernetes clusters, Amazon EKS, Google GKE, Azure AKS, OpenShift (including an offline setup with Artifactory) and single-node K3s. The deployment guide compares them.
- Your databases: on Kubernetes you provide PostgreSQL, MongoDB, Valkey or Redis, and S3-compatible storage. PostgreSQL must allow at least 400 connections. Redis Cluster mode isn’t supported.
- Resources: the standard setup asks for about 2.6 CPU and 8.3 GiB of memory to start. At its limits it can use up to about 20 CPU and 54 GiB. That includes the local AI model server, which alone may use up to 32 GiB of memory and 50 GiB of storage. These figures add up the shipped settings and don’t include your databases.
- Scaling: the API runs 2 to 8 copies. Each kind of worker starts with 1 copy and can grow to 3 to 6 copies, depending on its job. The scheduler and the MCP server always run one copy.
Limits TestLookup applies
TestLookup applies these limits to protect itself. They are settings, not promises of capacity, and an administrator can change most of them in the configuration.
- Uploads: up to 50 MiB per file, and up to 50,000 test results in one upload or one batch.
- Zip files: up to 200 MB unpacked, 5,000 files, and 50 MB for any one file inside.
- Sending rate, per project: up to 200 uploads or batches a minute, and 20,000 single live events a minute. Above that, TestLookup asks the sender to wait and try again.
- Live reporters: each batch holds 1 to 1,000 events.
- Live views: up to 500 open live views per project and 5,000 in total, for each API process.
- When the job queue is busy: once its memory is 75% full, TestLookup asks senders to wait. The shipped Docker Compose setup gives the queue 512 MB of memory.
- Upload status: kept for 24 hours.
- Report exports: reports with up to 200,000 tests are made straight away; bigger ones are made in the background.
- Very busy live projects: a project that sends at least 1,000 test events a minute for 3 minutes keeps only every second detailed test row. This is on by default, and run totals stay exact.
What has been measured
The project has a few one-off measurements, made on test machines whose size isn’t always recorded. Treat them as rough signs, not guarantees.
- Reading one 50 MB JUnit file with about 1.3 million test results used up to 1.3 GB of memory.
- On Kubernetes, one worker that reads test reports handled about 23 runs a second during a burst of 80 runs when it had 4 CPU cores, and about 5 runs a second with 1 core.
- On a test system with 1 million test cases and one API copy, chart data took up to about a quarter of a second for one person. It held that speed for about 4 people loading heavy charts at the same time.
- Keyword search reached about 17 searches a second, below the project’s own target of 20.
What hasn’t been measured yet
The project hasn’t published these figures, and this website won’t guess them:
- the largest number of people who can use TestLookup at the same time;
- how many uploads or requests a second one machine can handle steadily;
- the largest number of projects, runs or tests one installation can hold;
- how long it takes from an upload to a finished run.
It also doesn’t list supported browsers (its own browser tests use Chrome), supported Kubernetes or OpenShift versions, or whether the images run on Arm machines such as Apple Silicon. The maintainers’ advice is to measure with your own data before you rely on any capacity figure. The Docker Compose file shows the memory and CPU limits each service gets.