How We Test

A line that says "tested" should mean something you can check. This page explains what we actually do when an article on DevOpsCompass says a command was tested, what our lab can and cannot show, and how to read the "Last verified" date at the end of each guide.

Our lab

Hands-on guides are tested on one server that we run ourselves: a 4-core ARM64 Linux machine with Docker. It is not a production system. For each topic we write a small script that creates a fresh, throwaway environment, runs the commands from the article, and saves the raw output to a log. When the run is finished the container is removed, so one test cannot quietly affect the next.

Most tests use the official base images, such as ubuntu:26.04. When a topic depends on the init system, for example DNS with systemd-resolved or the SSH socket unit, we boot systemd inside a privileged container so the real services run. When a topic depends on versions, we repeat the same check across releases. Our guide to the OpenSSH post-quantum warning, for instance, connects to servers on Ubuntu 20.04, 22.04, 24.04 and 26.04 and on Debian 12 to see which ones trigger it.

What happens for each hands-on guide

  1. We start from a real question. We collect the questions people ask in search suggestions, GitHub issues and community forums, and we look for the ones that have no good answer yet.
  2. We read the primary sources. Release notes, changelogs, man pages and official documentation come first, and each claim goes into a fact ledger with its source and the date we checked it.
  3. We reproduce the problem. Where we can, we trigger the actual error before trying a fix, so the article shows the message you will see on your own screen.
  4. We run the fix and check the result. The commands in the article are the ones that ran, and the screenshots of terminal output come from those runs. When a change can lock you out or break something, we also look at how to undo it.
  5. We write down what failed and what we skipped. A guide should tell you where the evidence ends, so limits go in the article rather than being left out.
  6. The editor reviews it. Articles may be drafted with AI assistance, and Adam ALI reviews every one before publication, as described in our editorial policy.

Examples of what testing has found

  • In our Docker on Ubuntu 26.04 guide, a port blocked by ufw stayed reachable as soon as a container published it. That is why the guide binds ports to 127.0.0.1.
  • In our Rust coreutils guide, we ran about 200 small cases against both the Rust and the GNU commands, and timeout returned a different exit code in one of them, which matters for scripts that check for 124.
  • In our SSH port guide, editing sshd_config alone left SSH on port 22, because the socket unit also has to be reloaded and restarted.

What our lab cannot show

  • Other hardware. Our server is ARM64. Unless an article says otherwise, x86-64 behaviour was not tested. Packages and images can differ between architectures.
  • Containers are not full machines. Kernel-level behaviour, boot, disks and some network settings can differ on a real server or a virtual machine. Articles say so when it matters.
  • Managed cloud services. We do not test paid cloud products unless the article says we did. Those steps come from official documentation.
  • Performance. We do not publish our own benchmarks. A single small server is not a fair measure of speed.
  • Local AI models. We do not download large models, and we have no GPU in the lab. Speed and hardware figures in those articles come from official pages or from user reports that we quote and link.

Which articles are tested

Guides in the DevOps, Docker, Linux and Security sections are hands-on unless they say otherwise. Articles in Local AI and AI News are documentation and news roundups. They separate official facts, what users report, our own take and what we did not test. At most they include a cheap check such as validating a Compose file, and that check is labelled.

How to read the dates

"Last verified" at the end of an article is the date of our most recent check, with the versions involved where they matter. "Last updated" at the top shows the latest revision of the article. Software changes quickly, so if your output differs from ours, compare your version with the one in the article first.

If something does not work for you

Please tell us. Send the command, the output and your version to contact@devopscompass.com or use the contact page. We recheck the report and correct the article, and the "Last updated" date will show the change.