About
proofload.sh is a hands-on cloud and DevOps blog. Guides you can copy-paste and actually run, architecture worked out in the open, and benchmarks that put real systems under real load.
The name is a promise. In engineering, a proof load is the deliberate overload you put a component through to certify it won't fail in the field. The .sh is where the work happens: the shell, the commands, the thing you run. Everything here has been run. If I recommend a setup, I've deployed it. If I compare two databases, I've loaded both until something broke.
What you'll find
- Guides are step-by-step cloud and DevOps walkthroughs, covering deployments, reverse proxies, mail that lands in the inbox, CI/CD, and containers. They're written from a real deployment and meant to be copied and run, with the OS and versions stated before the first command.
- Cloud and DevOps posts work through architecture, principles, and the tradeoffs nobody puts in the docs. Every position traces back to something I built or operated, and where the opposite choice is the correct one, I say when.
- Benchmarks put databases, servers, and providers under load, with the full methodology and the numbers vendors round off. Results carry p50, p95, p99, and p99.9 latency next to throughput, and the scripts go in a public repo so you can rerun the whole thing.
What you won't find
No marketing adjectives, no untested advice, and no benchmark with the winner picked before the load generator started. Every guide lists its versions and commands. Every benchmark ships its setup. A pretty average hiding an ugly tail is a failure, and it gets shown as one.
No money changes hands with the vendors I test. If a post ever involves a sponsorship, an affiliate link, or free credit, it's disclosed at the top and kept well away from the results. When I get something wrong, the correction gets published as a correction rather than edited in quietly.
Who's writing this
I'm Aleksandar, an engineer who'd rather run the test than argue about it. If something here saves you a bad migration, an oversized bill, or a 2 a.m. incident, it did its job.
If you find a flaw in one of my methods, that's the best email I can get. New posts go to subscribers first. Subscribe.