Storage and self-maintenance: why the disk does not fill up

A suite that runs thousands of tests a day writes evidence all day: videos, traces, screenshots and reports. Nexus Studio keeps that bounded on its own. Every folder has a cap per test, all evidence together has one budget, and the disk keeps a free-space floor. This page explains what grows, what goes first, what is never deleted, and what 10,000 runs a day look like on disk.

By the Nexus Studio team, Verdict System LLC. October 9, 2026.

What grows, and why it stays bounded

Every run writes something. A pass keeps a screenshot and its metadata. A failure keeps a folder: report.md, metadata.json, raw-data.json, screenshot.png and, for a real failure, video.webm and trace.zip. API, chaos, Smart Monkey, load and visual regression runs keep folders of their own, and every run adds a row to History and scratch files to the run cache.

A cap per test is not enough on its own. Keeping 20 failure runs is little for one test and a full disk for 10,000 tests. So the engine bounds storage in two layers: a cap per test, and one budget over all evidence that does not grow with the number of tests.

Layer one: a cap per test

Each kind of evidence keeps a set number of runs, the newest ones. These are the defaults:

Every one of them is a line in the workspace's .env. Settings edits all of them except the three telemetry limits.

Layer two: one budget for all evidence, and a free-space floor

NEXUS_EVIDENCE_MAX_GB, 20 GB by default, bounds all evidence together: failures, passes, API, chaos, Smart Monkey, load and visual regression runs. It does not grow with the number of tests. With 100 tests or 10,000, the evidence stays under it.

NEXUS_MIN_FREE_GB, 10 GB by default, is the free space the disk keeps. When the disk drops under it, older evidence goes even while the total is still under the budget.

When either limit is crossed, the engine removes whole run folders, in this order:

1. Passing runs and visual regressions, oldest first.
2. Then failures, oldest first.
3. It stops as soon as the evidence is under the budget and the disk is above its floor.

If only the newest run of each test is left and the total is still over the budget, the engine says so after the run: raise the budget, or archive what you need and free older runs. The floor works through evidence only. When other files fill the disk, the engine frees its own evidence down to the newest run of each test, and the Studio keeps warning that the disk is low.

What is never deleted

• The newest run of each test and browser, and the newest Smart Monkey session and load run. The run that just finished is always the newest of its own.
• Archive. The copies you chose to keep with Archive… in the Evidence Locker sit beside the evidence folder, not inside it. Neither the caps nor the budget reach them.
• History. Removing a run folder does not remove the run's row. History keeps its own window, 50 runs per test and browser by default.
• The chain of custody. The ledger is append-only and never trimmed.

Sealed evidence is purged on the record

Sealing is opt-in. A sealed record hashes every file of its folder with SHA-256 and chains it to the record before it, so a sealed folder that vanished without a word would look exactly like tampering.

Before the budget removes a sealed folder, the engine appends a PURGE entry for it to the ledger, naming the disk budget as the one who removed it and when. The ledger still proves what the folder hashed to, and nexus verify reports the record as PURGED, not tampered. If the ledger cannot record the PURGE, the folder stays.

What runs automatically, and when

The engine maintains itself after every run, in every mode: a single test, a suite, a loop, a Watch schedule, Selenium, pytest and API runs.

• Free space is checked after every run.
• The evidence is weighed at most every 15 minutes, or at once when the disk is under its floor. That pass removes the oldest runs until both limits hold.
• Scratch files are swept. Per-run result files and the logs of the application under test go once they are older than 24 hours. Configuration-error logs keep the newest 14 files. Folders a killed run left in the Windows temp folder go after 24 hours too.
• Playwright's scratch output folder is emptied at the start and at the end of every run.
• Logs rotate at 10 MB.
• Telemetry scratch files go into a zip after each run, within the three limits above.

What you see in the Studio

Workspace › Disk shows:

• the evidence used against the budget;
• the free disk against the floor;
• when the last check ran, and what the last pass freed;
• Run maintenance now, which runs the same pass at once instead of after the next run.

When free space drops under the floor, the Studio shows a low-disk warning. Both limits are in Settings, under Evidence & Retention. The same panel lists every folder a run writes to, with its size and its limit: what each run keeps.

Docker and remote hosts

The engine can run suites in Docker on this machine or in a container on a Linux server over SSH. The Studio itself stays on Windows.

• Container logs are capped at three files of 10 MB per service, so a container that runs for months does not fill the host with its own output.
• The self-hosted GitHub runner registers once. A restart reuses its registration instead of registering again.
• The engine on that host is the same engine, with the same caps, budget and floor for the evidence it writes there.

A worked example: 10,000 runs a day

This is an estimate, not a measurement. Assume:

• 10,000 test runs a day;
• 5% fail, so 500 failures a day;
• about 3 MB per failure folder: video, trace, screenshot and data.

That is about 1.5 GB of failure evidence a day. Under the 20 GB default, roughly the last two weeks of failures stay on disk, and total evidence never exceeds 20 GB. Passes go first, so the space goes to the failures, the evidence you are most likely to need.

The 3 MB assumes both the video and the trace are kept. The BREACHED folder on the evidence page weighs 531.2 kB before its trace.

Tuning for big suites

• More history: raise NEXUS_EVIDENCE_MAX_GB. On a 1 TB disk, a budget of 200 GB keeps ten times the default, about four months of failures at 1.5 GB a day. The caps per test still apply: a test keeps at most its 20 failure runs unless you raise NEXUS_BUGREPORT_RETAIN too.
• Less per failure: turn the trace off with NEXUS_TRACE_ENABLED=false, or keep video for fewer verdicts with NEXUS_VIDEO_VERDICTS. The same budget then holds more days.
• Room for other programs: raise NEXUS_MIN_FREE_GB if the machine needs more free space than 10 GB.
• Tests that run many times a day: raise NEXUS_HISTORY_RETAIN, for example to 500, so History covers more than a few days.
• A failure you must keep: archive it from the Evidence Locker before it ages out.

Questions

Will it fill my disk if I run 10,000 tests a day?

Not with its evidence. Evidence stays under its budget, 20 GB by default, however many tests you run, and the engine removes older evidence to keep 10 GB of the disk free. More runs a day means the evidence reaches less far back, not that it takes more space. Files outside the evidence, such as Docker images or your own workspaces, are not part of the budget.

Does cleanup ever delete a failure I need?

It can, once the failure is old enough: past the budget, the oldest runs go, passes before failures, and the newest run of each test and browser always stays. To keep a failure for good, choose Archive… in the Evidence Locker. The copy sits outside the evidence folder, and neither the caps nor the budget touch it.

Will a sealed record read as tampered after cleanup?

No. The PURGE entry goes into the ledger first, and nexus verify reports the record as PURGED.

What happens when the disk is almost full?

Under the floor, 10 GB by default, the engine weighs the evidence at once instead of waiting for its 15-minute pass, removes older evidence even under the budget, and the Studio shows a low-disk warning. If other files take the space, it frees what it can and keeps warning.

Do I have to do anything?

No. It runs after every run. Run maintenance now, under Workspace › Disk, runs it at once.