How VPS Medic repairs a server without breaking it: the safety ladder explained

Every admin has a story about a "fix" script that reinstalled a package, reset a config, or deleted a log that was still open, and turned a ten-minute outage into an evening. That is the reputation any automatic repair tool starts with, and it is deserved. VPS Medic was built by someone who has spent years cleaning up after that pattern on CyberPanel servers, so the engine's first job is not to fix things. It is to not make them worse.

One ladder for every problem

Whatever the symptom, the engine climbs the same five rungs, in order, and the app shows you which rung it is on.

1. Observe. Read-only commands only: systemctl states, journalctl, application logs, disk and inode usage, memory, config tests, binary integrity. Nothing on the server changes during this phase, and you can run it as often as you like.
2. Diagnose. The evidence is matched against the known causes for that symptom, listed from most common to least. "lsws failed" alone does not pick a fix; "lsws failed + port 80 held by apache2" does. Where the evidence matches nothing, the engine stops here and reports.
3. Fix, lightest first. Repairs are graded. Level 1: start, enable, fix a permission, clear a cache. Level 2: edit or restore a config file, reinstall a single package, repair pip, always after a snapshot of what will be touched. Level 3: reinstall a component or rebuild a Python environment, only after you confirm and only with a backup.
4. Verify. After each step the engine checks that the symptom is gone and that the effect you care about is back: the unit is active, the port is listening, every site answers over HTTP. A command exiting with 0 is not a verification.
5. Roll back. If a step fails verification, the engine climbs one rung. If a step makes anything that was healthy stop, it restores the snapshot and halts.

Hard limits the playbooks cannot override

Each repair is a playbook, and playbooks are data: they can be updated and added to without changing the app. That makes it important that the dangerous things are refused by the engine itself, not left to each playbook's good manners.

• Nothing under /home, in MariaDB's data directory, or in the OpenLiteSpeed and CyberPanel configuration directories is ever deleted. At most it is backed up or moved aside.
• Active log files are truncated, never removed.
• The running kernel is never a cleanup candidate.
• No level-2 or level-3 step runs while the root filesystem is nearly full. A safe disk cleanup runs first, because a full disk is where corrupt binaries and modules come from.
• No reinstall ever happens as a "fallback" without a diagnosed cause. If the engine cannot name the cause, it does not reinstall; it reports.
• Nothing is marked fixed until a verify step passes.

What the fallback actually looks like

When every rung has been tried and the problem remains, you do not get "Error: fix failed". You get a diagnosis report: the service that is down, the evidence collected in the observe phase, the causes that were tested and why each was ruled out, the fixes that were attempted with their verification results, and the manual steps a senior admin would take next. You can copy it, save it, or send it to VPS Medic support in one tap. Reports that reveal a new cause become new playbooks, which every license holder receives in the next engine update.

Why it is built this way

On a VPS that hosts other people's websites, the cost of a wrong fix is far higher than the cost of a slower right one. Reading the journal takes two seconds. Reinstalling the wrong package takes an hour to undo and sometimes cannot be undone at all. The engine spends those two seconds every time so that the one-tap experience in the app is one you can trust at 2 a.m., with root, on a server that is already in trouble.