125 lines
3.4 KiB
Markdown
125 lines
3.4 KiB
Markdown
---
|
|
title: Update Management
|
|
description: Practical update management for Linux hosts, containers, and self-hosted services
|
|
tags:
|
|
- updates
|
|
- patching
|
|
- self-hosting
|
|
category: self-hosting
|
|
created: 2026-03-14
|
|
updated: 2026-03-14
|
|
---
|
|
|
|
# Update Management
|
|
|
|
## Introduction
|
|
|
|
Update management keeps systems secure and supportable without turning every patch cycle into an outage. In self-hosted environments, the challenge is balancing security, uptime, and limited operator time.
|
|
|
|
## Purpose
|
|
|
|
This guide focuses on:
|
|
|
|
- Operating system updates
|
|
- Container and dependency updates
|
|
- Scheduling, staging, and rollback planning
|
|
|
|
## Architecture Overview
|
|
|
|
A practical update process has four layers:
|
|
|
|
- Inventory: know what you run
|
|
- Detection: know when updates are available
|
|
- Deployment: apply updates in a controlled order
|
|
- Validation: confirm services still work
|
|
|
|
## Step-by-Step Guide
|
|
|
|
### 1. Separate systems by risk
|
|
|
|
Create update rings such as:
|
|
|
|
- Ring 1: non-critical test systems
|
|
- Ring 2: internal services
|
|
- Ring 3: critical stateful services and edge entry points
|
|
|
|
### 2. Automate security updates where safe
|
|
|
|
For Linux hosts, automated security updates can reduce patch delay for low-risk packages. Review distribution guidance and keep reboots controlled.
|
|
|
|
### 3. Automate update discovery
|
|
|
|
Use tools that open reviewable pull requests or dashboards for:
|
|
|
|
- Container image updates
|
|
- Dependency updates
|
|
- Operating system patch reporting
|
|
|
|
### 4. Validate after rollout
|
|
|
|
Confirm:
|
|
|
|
- Service health
|
|
- Reverse proxy reachability
|
|
- Backup jobs
|
|
- Monitoring and alerting
|
|
|
|
## Configuration Example
|
|
|
|
Ubuntu unattended upgrades example:
|
|
|
|
```text
|
|
APT::Periodic::Update-Package-Lists "1";
|
|
APT::Periodic::Unattended-Upgrade "1";
|
|
```
|
|
|
|
Dependency update automation example:
|
|
|
|
```json
|
|
{
|
|
"extends": ["config:recommended"],
|
|
"schedule": ["before 5am on monday"],
|
|
"packageRules": [
|
|
{
|
|
"matchUpdateTypes": ["major"],
|
|
"automerge": false
|
|
}
|
|
]
|
|
}
|
|
```
|
|
|
|
## Troubleshooting Tips
|
|
|
|
### Updates are applied but regressions go unnoticed
|
|
|
|
- Add post-update health checks
|
|
- Review dashboards and key alerts after patch windows
|
|
- Keep rollback or restore steps documented for stateful services
|
|
|
|
### Too many update notifications create fatigue
|
|
|
|
- Group low-risk updates into maintenance windows
|
|
- Separate critical security issues from routine version bumps
|
|
- Use labels or dashboards to prioritize by service importance
|
|
|
|
### Containers stay outdated even though automation exists
|
|
|
|
- Verify image digests and registry visibility
|
|
- Confirm the deployment process actually recreates containers after image updates
|
|
- Prefer reviewed rebuild and redeploy workflows over blind runtime mutation for important services
|
|
|
|
## Best Practices
|
|
|
|
- Patch internet-exposed and admin-facing services first
|
|
- Stage risky or major updates through lower-risk environments
|
|
- Prefer reviewable dependency automation over silent uncontrolled updates
|
|
- Keep maintenance windows small and predictable
|
|
- Document rollback expectations before making large version jumps
|
|
|
|
## References
|
|
|
|
- [Ubuntu Community Help Wiki: Automatic Security Updates](https://help.ubuntu.com/community/AutomaticSecurityUpdates)
|
|
- [Debian Wiki: UnattendedUpgrades](https://wiki.debian.org/UnattendedUpgrades)
|
|
- [Renovate documentation](https://docs.renovatebot.com/)
|
|
- [GitHub Docs: Configuring Dependabot version updates](https://docs.github.com/code-security/dependabot/dependabot-version-updates/configuring-dependabot-version-updates)
|