proofload.sh is a hands-on cloud and DevOps blog, and it runs on one rule: if I can't run it, I don't publish it.

The name is the 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 actually run. If I recommend a setup here, I've deployed it. If I compare two databases, I've loaded both until something broke.

What's here

Guides come out of a real deployment rather than out of documentation. Deployments, reverse proxies, mail that lands in the inbox instead of spam, CI/CD, containers. Commands appear in the order I ran them, the OS and version numbers are stated before the first one, and anything destructive or billable gets flagged above the command rather than after it. Each guide ends with a way to verify it worked, because "it should work now" is not a verification step.

Cloud and DevOps posts cover architecture and the tradeoffs that don't make it into vendor docs. Every position traces back to something I built or operated. Where the opposite choice is the correct one, I say when.

Benchmarks put databases, servers, and providers under load. Exact hardware, versions, config, dataset, and load setup get published, and the scripts go in a public repo. Results report p50, p95, p99, and p99.9 latency next to throughput. Warm-up is discarded, runs are repeated, variance is reported. A pretty average hiding an ugly tail is a failure, and I show it as one. Cost sits next to the numbers where it matters, since performance per dollar flips plenty of conclusions.

If there's no way for you to rerun it, it's an anecdote, not a benchmark, and it doesn't get posted as one.

What's not here

No vendor adjectives. Nothing on this site is blazing-fast or enterprise-grade, because those words replace a measurement instead of being one. No advice I haven't run on a machine I was responsible for. No comparison with a winner picked before the load generator started.

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. Quietly editing a post after the fact is how you end up with an archive nobody can trust.

Who's writing this

I'm Aleksandar, an engineer who would 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.

First up is the stack this site is running on: two Ghost blogs on one VPS behind Nginx, in Docker, with certbot handling the renewals. After that, SPF, DKIM, and DMARC set up so Gmail stops eating your application's mail.

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.