Stop the package manager from overwriting your custom config tweaks

Technical Briefing | 9/22/2026

You just spent an hour tuning a service config, only for a minor security patch to roll out, update the package, and wipe your changes. It’s a rite of passage, but it’s one you should only pay once. Most sysadmins learn this the hard way after a reboot leaves their service in a broken state because the package maintainer’s defaults took priority over their production-ready optimizations.

The trap of dpkg conffiles

Apt handles these situations by checking md5 sums of the existing files. If it doesn’t match what the package expects, you get the interactive prompt, but in non-interactive CI pipelines or automated installs, the system often defaults to the maintainer version. Instead of relying on manual intervention, you should use the package manager’s built-in mechanism to mark files as protected. If you are using Debian or Ubuntu, you can pin specific files to ensure they never get touched.

echo "/etc/my-service/config.conf" >> /etc/dpkg/dpkg.cfg.d/keep-my-configs

Why relying on backups is a sucker’s game

• The dpkg conffile database is what actually triggers those scary diff prompts during upgrades.
• RPM systems like DNF use .rpmnew and .rpmsave files, which effectively ignore your local changes until you merge them manually.
• Hard-coding your config in a separate directory or using drop-in folders like /etc/service.d/ is safer than editing the main conf file.

If you really want to sleep at night, don’t edit the packaged config files directly. Most modern services support an include-directory pattern. If you find a package that doesn’t, that is a strong hint to look for a different distribution method, like an overlay template or a configuration management tool like Ansible that forces your state back onto the file after the package manager finishes its business.