Somewhere in the middle of a PCI DSS remediation sprint, I found myself staring at an Apache config and doing the thing I'd explicitly told myself not to do: editing a file that Plesk was going to regenerate the next time anything touched the domain.
Ten minutes later, it had. Of course it had.
That tiny loop — where you hand-edit a config, feel good about yourself, and then watch Plesk silently overwrite your work the next time a subscription changes — is the whole story of working inside Plesk. And when you're on a compliance deadline, it's also the thing most likely to burn you.
Here's what the remediation work looked like, and why "stay Plesk-native" stopped being a preference and started being a rule.
The temptation to go around the panel
Plesk is opinionated. It owns Apache/nginx configs, firewall rules, cron entries, and a lot of things that sysadmins coming from bare Ubuntu instinctively reach for. When a scan report hands you a long list of findings and a ticking clock, the fastest-looking path is to open the relevant config in vim and fix it.
Don't. Or at least, don't without first checking whether Plesk exposes the same knob somewhere in its UI, its CLI (plesk bin), or its includes mechanism.
Why? Because Plesk's job is to be the source of truth for server configuration. The moment you go around it, your fix has a half-life measured in however long it takes for someone to edit a hosting plan, renew a certificate, or run a subscription update. You won't even know it got reverted until the next scan.
MariaDB upgrades, the Plesk way
One of the clearer wins was getting MariaDB off an end-of-life version. The naive play is to run OS-level upgrade commands and move on. On a Plesk server, that's how you end up with a working database and a panel that can't talk to it.
Plesk ships its own tooling for database upgrades, and using it means the panel updates its internal references as the version shifts. That matters for backup and restore flows, for the stats collectors, and for any subscription using the managed MySQL connector.
Slower? A little. Boring? Absolutely. But the post-upgrade smoke test is a lot shorter when you haven't fought the panel.
Cipher suites and security headers without the arms race
Cipher suite hardening was the finding that looked simplest and wasn't. The temptation is to drop a tight SSL block into /etc/apache2/mods-enabled/ssl.conf and call it done. That file is managed. It will change back.
Plesk has first-class surfaces for TLS configuration at the server-wide level, and for per-domain directives it respects its vhost.conf and vhost_ssl.conf includes. Write your custom directives there, run plesk sbin httpdmng --reconfigure-all, and the changes stick through regeneration because Plesk is explicitly looking for them.
Security headers — HSTS, X-Content-Type-Options, Referrer-Policy, the usual set — went in the same way. Per-domain includes, reconfigured through Plesk, verified with a header check afterward. No hand-edits to the generated configs. No surprise reversion on the next panel action.
The quieter traps: logrotate and swap
Two findings didn't fit neatly into "harden this thing" and those were the ones that ate the most time.
Logrotate. Plesk maintains its own logrotate configs for domain logs, and the hardening requirements wanted specific rotation and compression behavior that conflicted with what Plesk ships. The fix wasn't to edit Plesk's files — those get overwritten — but to use Plesk's per-domain log rotation settings where they existed, and to add a supplementary logrotate file for the OS-level logs Plesk doesn't manage. Two scopes, two files, no overlap.
Swap. One server had a swap configuration the scanner flagged, and the root cause turned out to be less about security posture and more about undersized memory for the current workload. The compliance fix and the operations fix were the same fix. Worth remembering that sometimes a scan finding is pointing at a real underlying problem through the compliance language.
The takeaway
PCI DSS remediation on Plesk is less a technical challenge than a discipline challenge. The technical moves are well-documented. The discipline — resisting the urge to hand-edit your way to a fast green checkmark, and instead spending the extra twenty minutes to find the Plesk-native path — is what keeps your work from quietly unraveling a week later.
If there's one rule worth taping to the monitor: before you edit a config file on a Plesk box, check whether Plesk has an opinion about that file. It almost always does.