
safe auto updates that patch without breaking production
unattended-upgradesthe comments were right, and that's a good thing
i posted about auto-updates and the replies were basically "cool, now watch docker eat itself at 3am." fair. full unattended upgrades on everything is how you turn a tuesday into an incident report. but the answer isn't "never auto-update," it's "auto-update the stuff that matters and leave the fragile stuff alone." here's how to actually do that on debian/ubuntu without gambling with production.
step one, security patches only, not the whole buffet
the default unattended-upgrades config on a lot of systems pulls from every enabled repo. that means feature updates, random version bumps, whatever your distro decided to push that week. you don't want that on autopilot. you want the origins locked to security repos only.
open the config and check your allowed origins:
sudo nano /etc/apt/apt.conf.d/50unattended-upgrades
look for the Unattended-Upgrade::Allowed-Origins block and make sure only the security suite is active, something like:
Unattended-Upgrade::Allowed-Origins {
"${distro_id}:${distro_codename}-security";
};
comment out or remove lines pulling from -updates or -backports unless you specifically want those on autopilot too. this is the single biggest lever, it's the difference between "cve got patched overnight" and "some package i've never heard of got upgraded and now nothing starts."
step two, blacklist the packages that break when they change
docker, your database engine, kubernetes components, anything with a daemon that doesn't gracefully restart, these should never get silently bumped. add them to the blacklist in the same config file:
Unattended-Upgrade::Package-Blacklist {
"docker-ce";
"postgresql*";
"mysql*";
"containerd*";
};
wildcards work, so you can catch versioned package names without listing every single one. the logic here is simple, if a package restart could take down a running service or corrupt state mid-transaction, you patch it on your own schedule, not apt's.
step three, livepatch the kernel instead of rebooting blind
kernel security patches are the ones people avoid the most because they usually mean a reboot, and reboots on production boxes are scary. livepatching fixes that by patching the running kernel in memory without a restart. on ubuntu it's built in:
sudo apt install canonical-livepatch
sudo canonical-livepatch enable YOUR_TOKEN
you get a free token by registering with ubuntu one. check status anytime with:
canonical-livepatch status --verbose
this doesn't replace real reboots forever, some patches still require one eventually, but it buys you time to schedule that reboot instead of being forced into it at a bad hour.
step four, when a reboot IS needed, control the window
some updates still flag a reboot as required. instead of letting that happen whenever apt feels like it, or never happening because everyone's afraid to touch it, set an explicit maintenance window:
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";
4am, low traffic, predictable. now reboots happen on your terms, in a window you chose, instead of randomly whenever the cron job runs.
step five, email yourself every single time something changes
silent automation is how small problems become invisible until they're big problems. turn on notifications:
Unattended-Upgrade::Mail "you@yourdomain.com";
Unattended-Upgrade::MailOnlyOnError "false";
setting MailOnlyOnError to false means you get a log of everything that happened, not just failures. yes it's more email. that's the point, you want a paper trail so when something acts weird two days later you can check "oh, this got patched on tuesday" instead of guessing.
the takeaway
auto-updates aren't the enemy, blind auto-updates are. the fix isn't turning automation off, it's scoping it down to just security patches, protecting the packages that can't tolerate surprise restarts, using livepatch to kill kernel CVEs without downtime, controlling exactly when reboots happen, and making sure every change lands in your inbox. go check your own /etc/apt/apt.conf.d/50unattended-upgrades today, most servers running this have never had these lines touched since install. five minutes now beats a 3am page later.