Home · Volume 6 · Chapter 06

📖 Chapter 06 — Update Strategy

Keeping software current without breaking things. The discipline of patching.

v0.1 · draft Vol 6 · Ch 06
~10 min

Learning Objectives

Introduction

Software has bugs. Bugs get fixed. The fixes are released as updates. If you don't update, the bugs stay. Some of those bugs are security vulnerabilities. The choice is: update regularly and accept the small risk of breakage, or skip updates and accept the larger risk of compromise.

This chapter is the discipline of updating. Not "update everything immediately" (too risky), not "never update" (too dangerous), but a strategy that balances security and stability.

The default: update, but carefully

The right default for a home lab: update regularly, with a plan. The plan:

  1. Read the release notes for the update. What changed? Any breaking changes? Any known issues?
  2. Take a snapshot of the relevant data before the update.
  3. Apply the update.
  4. Verify the service still works.
  5. If something's broken, roll back to the snapshot.

The cost: 10-15 minutes per update. The benefit: security and stability over time.

What to update, and when

For a home NAS, the update categories:

Critical security updates: apply within days

For security vulnerabilities that are actively exploited in the wild, apply the update as soon as possible. Read the release notes, take a snapshot, update, verify.

Regular security updates: apply within a month

For security updates that aren't actively exploited, apply within a month. Read the release notes; if nothing breaks in your setup, update.

Feature updates: apply within a quarter

For updates that add features or fix non-security bugs, apply within a quarter. Take your time; read the release notes; consider waiting for a point release if it's a major version bump.

Major version upgrades: plan carefully

For major version upgrades (TrueNAS 24 → 25, Immich v1 → v2, etc.), plan carefully. Major upgrades often have breaking changes; some require manual migration steps; some are not supported in certain configurations.

The pattern: read the upgrade guide, test in a non-production setup if possible, schedule a maintenance window for the actual upgrade, have a rollback plan.

The TrueNAS update cycle

For the TrueNAS base system:

The discipline: enable auto-update checks (so you know when updates are available), but don't enable auto-apply. Apply updates when you have time to verify the system afterward.

The app update cycle

For each app in the TrueNAS Apps catalog:

For each app, the update is one-click in the TrueNAS UI. The app restarts; the data is preserved.

The "before you update" snapshot

For any non-trivial update, take a snapshot first. The snapshot is your rollback path.

For TrueNAS, the snapshot is a ZFS snapshot of the relevant dataset. For an app, the snapshot is a ZFS snapshot of the app's data.

The discipline: snapshot before update. Verify the snapshot exists. Then apply the update. Then verify the service works. Then (a few days later, after you're confident), delete the snapshot.

The rollback

When an update breaks things:

  1. Stop the app (or the service that's broken).
  2. Restore the snapshot.
  3. Restart the app.
  4. Verify the service works again.

For most apps, the rollback is straightforward: revert to the snapshot, the app is back to the previous version with the previous data. The downtime is minutes.

For some apps, the rollback is more complex: the app's database schema might have been migrated, and the rollback needs to undo the migration. For these, the rollback might not be seamless; the previous data might need to be re-imported.

The "staging environment" pattern

For major updates, the pattern: test in a staging environment first. A second instance of the app, running on a different port, with a copy of the data, where you can test the update without affecting the production setup.

For most home labs, the staging environment is overkill. The risk of a major update breaking a single-family app is small; the cost of maintaining a staging environment is real.

The exception: if you have critical data in the app (the family photos, the password database), the staging environment is worth it. Test the update on a copy of the data before applying to the real data.

The "automated updates" anti-pattern

The temptation: enable auto-update for everything. "It just updates itself; I don't have to think about it." The risk: an update breaks the system at 3 AM when you're not watching.

The conversation's recommendation: don't enable auto-updates for the OS, the apps, or the critical services. Apply updates manually, on your schedule, with a snapshot, with verification.

For non-critical services (a development tool, a test instance), auto-updates are fine. For anything the family uses, manual updates are the right answer.

The "I'm behind on updates" recovery

If you've been putting off updates for a while, the recovery:

  1. Don't try to apply them all at once. Apply them one at a time, in order.
  2. Read the release notes for each. Some updates require other updates first (e.g., a TrueNAS app update that requires a specific TrueNAS version).
  3. Take a snapshot before each update.
  4. Verify after each update.

Updating one app at a time makes it easier to identify the cause if something breaks. The discipline: catch up gradually, not all at once.

The "what about firmware updates" question

For the hardware (the NAS motherboard, the drives, the network card), firmware updates are also important. The discipline:

The principle: only update firmware if you have a reason. Firmware updates can brick hardware; the benefit is rarely worth the risk for working hardware.

The "end-of-life" awareness

Software has lifecycles. When a piece of software reaches end-of-life (EOL), it stops receiving security updates. The options:

For home labs, the right answer is usually: upgrade to the next major version. Major upgrades are work, but they're less work than recovering from a compromise.

Engineering Note

Updates are a discipline, not an event. The system isn't "up to date" once and forever. New updates are released constantly. The discipline: a monthly update session, with snapshots, with verification. The 30-60 minutes a month is the price of a secure and stable system over years.

Summary

Update regularly, with a plan. Read release notes. Snapshot before updating. Apply the update. Verify the service works. Roll back if it breaks. Critical security updates within days; regular security updates within a month; feature updates within a quarter; major upgrades planned carefully. Don't enable auto-updates for critical services. Catch up gradually if you're behind. The 30-60 minutes a month is the price of a secure, stable system over years.

Checklist

Looking Ahead

Chapter 07 is the runbook. The documentation that turns operations into a habit. The single source of truth for the home NAS. The chapter that turns "I think I know how this works" into "I have a document that says exactly how this works, and I update it as the system changes."

Ch 06 · v0.1 · drafted from the original ChatGPT conversation, July 2026