Submitting your results
The community results gallery is a public collection of real BenchKit runs across different hosts, hardware, and PHP configurations. Adding yours is how the next person finds a machine like the one they are considering.
Submitting is optional. BenchKit never sends anything anywhere on its own, and a run only leaves your machine when you press the button.
How to submit a run
Finish a run
Run a benchmark and wait for it to complete.
Press Submit result
Fill in where it ran, which provider and plan you used, and what you pay. BenchKit has already detected the machine details. What you fill in is the part only you know.
Review what will be published
BenchKit shows you the exact document before anything leaves your browser, and then opens a pre-filled GitHub issue.
Post the issue
A bot validates your submission, opens a pull request, and closes the issue with a link to it. Your run appears in the gallery once a maintainer merges.
Why it goes through GitHub
We did not want to maintain a server to receive results, and a GitHub issue turned out to be a better answer than one anyway. Your submission is credited to your GitHub account without BenchKit needing accounts or logins, and every result lands as a pull request anyone can read, question, or comment on. A form would have collected the same numbers and none of the conversation.
What gets published
The published document is an allow-list. A field appears in the gallery because somebody decided it should, rather than because nobody thought to remove it.
Published, because it explains the numbers: your hardware, PHP version and variation, whether the application was serving in worker mode, the performance-related php.ini settings, the FPM pool size, the database engine, which stages ran, the load settings, which load mode produced the run — plus, for an external load test, the generator's round trip and oha version — and the host, plan, and cost you entered.
Never published:
| Withheld | Why |
|---|---|
| Console logs | They contain your public IP |
APP_URL and internal hostnames | They describe your network |
| The raw network block from YABS | On home hardware it identifies your ISP and city |
| The external generator's IP and hostname | The machine driving the load is one you control — often a laptop |
| Filesystem paths, such as the preload path | A path can carry a project or company name |
Whether preloading is enabled is published, because it explains performance. The path is not.
How to read the gallery
The gallery holds community-submitted numbers from hardware their submitters control. No single run is independently proven. The gallery shows a distribution rather than a leaderboard, because a ranking across different hardware, settings, and image variations would be meaningless.
Self-tested and externally-driven runs are two different measurements, so the gallery keeps them apart. Self-tests are accepted — they are honest floors, and the right instrument for same-machine comparisons — but they are labeled, shown with a warning, and listed in their own partition; the two populations never share a column. A run where the load generator itself was the bottleneck is rejected outright: its throughput describes the network path between two machines, not the server, and a number that measures the wrong thing is worse than a missing row.
The bot seals a run's measurements when it accepts the submission, and the site recomputes that checksum on every build. Nobody can edit a number after the fact without the check failing. The checksum catches truncation and tampering in transit. It cannot prove the original measurement was made honestly — stripping the load-mode label from a run before submitting, for instance, only demotes it into the warned self-test partition — which is why runs from the BenchKit team are marked, and why you should filter to one image variation and one provider before drawing a conclusion.
If you spot something in the gallery that should not be public, please open an issue.