Managing a Fleet of Personal Machines Without Losing Your Mind

There’s a specific kind of person reading this post. You have several computers. Maybe a desktop, a couple of laptops, a few Raspberry Pis, a NAS, some repurposed thinkpads running various things. You got each one for a reason that made sense at the time. And now you spend a non-trivial amount of your free time applying updates, fixing things that broke, and occasionally wondering whether any of this is actually worth it.

This post is for that person. It covers how to structure a multi-machine environment so each machine earns its place, how to reduce the maintenance overhead from “hobby-consuming” to “manageable background task,” and — perhaps most usefully — how to think honestly about when a machine should be sold, donated, or recycled rather than kept running out of inertia.

The Core Problem: Machines Without Roles Become Maintenance Debt

The pattern is predictable. You acquire a machine for a specific purpose. The purpose gets fulfilled, deprioritized, or superseded. But the machine keeps running — or sits in a corner “just in case” — accruing updates, security patches, storage, electricity, and mental overhead without producing meaningful value.

The root cause is almost never having too many machines. It’s having machines without clear roles. A homelab with fifteen machines each doing something specific and irreplaceable is more manageable than five machines with overlapping, vague purposes, because clear roles answer the questions that drive maintenance overhead:

• Does this machine need to be running right now?
• What breaks if it goes down?
• How often does it actually need attention?
• Would consolidating its workload onto another machine free up more than it costs?

Before anything else, write down every machine you own and, next to each one, write its role in one sentence. Not “general purpose” — a specific sentence about what it does that nothing else does. If you can’t write that sentence, the machine doesn’t have a role yet. That’s the first problem to solve.

Part 1: Giving Every Machine a Clear Job

The “One Primary Purpose” Rule

A machine with one clearly defined primary purpose is dramatically easier to maintain than a machine that does many things. The primary purpose determines:

• What software needs to stay current (versus what can be ignored)
• What monitoring matters (disk space on a NAS, CPU on a compile server, uptime on a media server)
• What the acceptable downtime is (a DNS server that goes down affects everything; a game server that goes down affects one evening)
• Whether the machine can be turned off when not needed

Useful primary roles for personal machines:

• Daily driver — the machine you actually use for your main work. Should be your best maintained, most reliable system.
• Media server — Plex, Jellyfin, or Emby. Runs continuously, needs reliable storage and network, benefits from low-power hardware.
• NAS / file server — Primary storage. Possibly the most critical machine in the fleet. Everything should back up to or from this.
• Development / build machine — A more powerful machine you SSH into for heavy compilation or development environments. Can be off when not needed.
• Homelab Kubernetes / Docker host — Running your self-hosted services. Needs decent uptime and resources.
• Network services — DNS (Pi-hole / AdGuard Home), DHCP, reverse proxy (Traefik / Nginx). Needs very high uptime. Usually low-power.
• Router / firewall — pfSense, OPNsense, or similar. Critical infrastructure. Should be dedicated hardware.
• VPN gateway — WireGuard or Tailscale subnet router. Can often be combined with network services.
• Backup target — Dedicated machine (or partition on NAS) whose entire job is receiving backups. Separate from the NAS so a single failure doesn’t take both.
• Test / experiment machine — The machine you break things on. Intentionally disposable. Can be a VM host, a spare laptop, or a mini PC.

Secondary purposes are fine. A NAS that also runs a few Docker containers is reasonable. A media server that handles network DNS is fine. But when everything is secondary and nothing is primary, the machine has no identity and maintenance becomes reactive rather than planned.

Power and Always-On Decisions

Not every machine needs to run 24/7. This is a decision most people never consciously make — machines stay on indefinitely because turning them off feels like a risk and turning them back on requires effort.

A useful framework: a machine should be always-on only if the cost of it being off (a broken service, missing data, inconvenience) outweighs the cost of it running (electricity, heat, fan noise, wear).

Always-on candidates:

• NAS / file server (things back up to it on schedule)
• Network services (DNS, DHCP — the whole network suffers if these go down)
• Media server (if people watch at unpredictable times)
• Home automation hub (if it controls anything important)
• Any machine running services other people depend on

On-demand candidates:

• Development / build machine (SSH in when you need it, shut it down when you’re done)
• Game servers (start it when playing, stop it when done)
• Experiment / test machine (on when actively being used, off otherwise)
• Desktop workstation (if you prefer to shut down at end of day)
• Backup target (can be on a schedule — wake on LAN before backup window, shut down after)

Wake-on-LAN (WoL) is the enabler here. A machine that can be remotely woken with a single command costs nothing to run when off, and turns on in 30–60 seconds when you need it. Most desktop motherboards and many laptops support WoL over the local network; Tailscale’s “magic wake-on-LAN” feature enables WoL over a Tailnet, so you can wake a home machine from anywhere.

1
2
3
4
5
6
7
8

# Wake a machine by MAC address (requires wakeonlan package)
wakeonlan AA:BB:CC:DD:EE:FF

# Or with etherwake
etherwake -i eth0 AA:BB:CC:DD:EE:FF

# Tailscale wake-on-LAN (from any node in your tailnet)
tailscale wake AA:BB:CC:DD:EE:FF

Part 2: Reducing Maintenance Overhead

The goal isn’t zero maintenance — that’s not realistic for any fleet. The goal is maintenance that’s predictable, automatable, and proportional to the value the machine provides.

Homogenize Where You Can

The single biggest lever for reducing maintenance overhead is running the same operating system and package ecosystem everywhere possible. If half your machines run Ubuntu, two run Fedora, one runs Arch, and your NAS runs TrueNAS, you have four different update mechanisms, four different package managers, four different paths through every CVE response, and four sets of mental models to maintain.

This doesn’t mean forcing every machine onto one OS — there are legitimate reasons for diversity (TrueNAS for a NAS is genuinely better than generic Linux, Raspberry Pi OS for Pi projects, etc.). But where there’s a choice, defaulting to one distribution saves significant cognitive overhead.

A common and sensible choice for a homelab:

• Debian or Ubuntu LTS for servers and always-on machines (stability, long support windows, massive package library)
• Your preferred distro for your daily driver (whatever makes you productive)
• Specialized OS only where there’s a clear reason (TrueNAS Scale for NAS, Talos for Kubernetes nodes, pfSense/OPNsense for routers)

If you currently have significant OS diversity and are spending maintenance time on it, the question isn’t “which OS is best” — it’s “which OS is best for maintaining multiple machines simultaneously,” and the answer is usually the one your automation targets.

Ansible for Everything

If you’re managing more than two machines and you’re not using some form of configuration management, you’re doing more work than you need to. Ansible is the right tool for most personal homelabs: it’s agentless (runs over SSH), uses readable YAML, has a massive module library, and doesn’t require a server.

The setup:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

# Install Ansible
pip install ansible
# or
sudo apt install ansible

# Create an inventory file
cat > ~/homelab/inventory.ini << 'EOF'
[servers]
nas.local ansible_user=admin
media.local ansible_user=jmoon
dev.local ansible_user=jmoon

[network]
pihole.local ansible_user=pi
router.local ansible_user=admin

[all:vars]
ansible_ssh_private_key_file=~/.ssh/homelab_key
EOF

A simple update playbook that handles the majority of your routine maintenance:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

# update-all.yaml
---
- name: Update all Debian/Ubuntu machines
  hosts: all
  become: true
  serial: 1  # update one at a time to avoid simultaneous reboots
  tasks:
    - name: Update package cache
      apt:
        update_cache: yes
        cache_valid_time: 3600
      when: ansible_os_family == "Debian"

    - name: Upgrade all packages
      apt:
        upgrade: dist
        autoremove: yes
        autoclean: yes
      when: ansible_os_family == "Debian"
      register: apt_result

    - name: Check if reboot required
      stat:
        path: /var/run/reboot-required
      register: reboot_required

    - name: Reboot if required
      reboot:
        reboot_timeout: 300
        msg: "Reboot triggered by system update"
      when: reboot_required.stat.exists

    - name: Update Docker containers (if Docker is running)
      block:
        - name: Pull latest images
          shell: |
            docker compose pull
          args:
            chdir: /opt/docker
          ignore_errors: true

        - name: Restart updated containers
          shell: |
            docker compose up -d --remove-orphans
          args:
            chdir: /opt/docker
          ignore_errors: true
      when: ansible_facts.services['docker'] is defined

Run it:

1

ansible-playbook -i inventory.ini update-all.yaml

This applies updates across your entire fleet sequentially, handles reboots, and updates Docker containers — in a single command, from your laptop, without SSHing into anything manually.

More useful playbooks to build:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

# check-disk-space.yaml — quick health check
---
- name: Check disk usage across fleet
  hosts: all
  tasks:
    - name: Get disk usage
      shell: df -h / | tail -1 | awk '{print $5, $6}'
      register: disk_usage

    - name: Display disk usage
      debug:
        msg: "{{ inventory_hostname }}: {{ disk_usage.stdout }}"

    - name: Alert if disk usage over 80%
      debug:
        msg: "WARNING: {{ inventory_hostname }} disk usage is high!"
      when: disk_usage.stdout | regex_search('^([89][0-9]|100)%')

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

# install-common-tools.yaml — keep baseline tools consistent
---
- name: Ensure common tools are installed
  hosts: servers
  become: true
  tasks:
    - name: Install baseline packages
      apt:
        name:
          - htop
          - ncdu
          - curl
          - wget
          - git
          - vim
          - tmux
          - fail2ban
          - unattended-upgrades
          - logrotate
        state: present

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# ssh-keys.yaml — deploy your public key to all machines
---
- name: Ensure SSH key is authorized on all machines
  hosts: all
  tasks:
    - name: Add SSH public key
      authorized_key:
        user: "{{ ansible_user }}"
        key: "{{ lookup('file', '~/.ssh/homelab_key.pub') }}"
        state: present

Automatic Security Updates

For machines where you care about security but don’t want to manually apply patches constantly, unattended-upgrades (Debian/Ubuntu) handles security-only updates automatically:

1
2

sudo apt install unattended-upgrades apt-listchanges
sudo dpkg-reconfigure -plow unattended-upgrades

Configure it to auto-reboot during a low-impact window:

# /etc/apt/apt.conf.d/50unattended-upgrades
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "03:00";
Unattended-Upgrade::Remove-Unused-Dependencies "true";
Unattended-Upgrade::Mail "you@example.com";

This is the right policy for always-on infrastructure machines (network services, NAS, media server): security patches apply automatically, reboots happen at 3am, and you get an email summary. Full system upgrades (major version bumps, non-security packages) remain manual and deliberate.

Docker Compose + Watchtower for Service Updates

For machines running services in Docker Compose, Watchtower eliminates most of the manual container update overhead:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

# Add to your docker-compose.yaml
services:
  watchtower:
    image: containrrr/watchtower
    container_name: watchtower
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      - WATCHTOWER_CLEANUP=true
      - WATCHTOWER_SCHEDULE=0 0 3 * * *    # 3am daily
      - WATCHTOWER_NOTIFICATIONS=email
      - WATCHTOWER_NOTIFICATION_EMAIL_FROM=watchtower@home.local
      - WATCHTOWER_NOTIFICATION_EMAIL_TO=you@example.com
      - WATCHTOWER_NOTIFICATION_EMAIL_SERVER=smtp.example.com
    restart: unless-stopped

Watchtower checks for updated images nightly, pulls them, and restarts affected containers. You get an email when something updates. For production workloads this would be too aggressive; for a homelab it’s exactly right — current containers without manual work.

If you have services where you want to control updates more carefully (pinned versions, staged rollouts), exclude them from Watchtower with a label:

1
2
3
4
5

services:
  critical-service:
    image: my-app:1.4.2
    labels:
      - "com.centurylinklabs.watchtower.enable=false"

Scheduled Maintenance Windows vs. Reactive Maintenance

Most homelab maintenance happens reactively — something breaks, you fix it. This is high-stress and time-consuming because it demands attention whenever it demands attention, including at 9pm on a Thursday.

The alternative: a maintenance window. One slot per week (or per month, for stable machines) where you expect to spend time on infrastructure. During that window: apply pending updates, check logs for anomalies, review disk space, address deferred issues.

Outside that window: nothing gets your attention unless it’s genuinely broken in a way that affects your daily life.

This reframe changes maintenance from an ambient anxiety (“there are probably updates I should apply”) to a contained task (“maintenance is Sunday morning after coffee”). The anxiety reduction alone is worth the structure.

What makes this work: basic monitoring that catches real problems before they become crises. You don’t need a complex monitoring stack. You need:

• Disk usage alerts when any machine exceeds 80% — everything else is recoverable, running out of disk is not
• Service health checks for your critical services (Pi-hole, media server, NAS)
• Automated backups with verification so you know your backup is current

For a lightweight monitoring setup across a homelab, a cron job that runs a basic health check script and emails you anomalies is often sufficient. Uptime Kuma or a simple Prometheus + Grafana stack for anything more sophisticated.

SSH Config Makes Everything Faster

A well-maintained ~/.ssh/config file eliminates the mental overhead of remembering hostnames, usernames, and key paths for every machine:

# ~/.ssh/config

Host nas
    HostName 192.168.1.10
    User admin
    IdentityFile ~/.ssh/homelab_key
    ServerAliveInterval 60

Host media
    HostName 192.168.1.11
    User jmoon
    IdentityFile ~/.ssh/homelab_key

Host pihole
    HostName 192.168.1.5
    User pi
    IdentityFile ~/.ssh/homelab_key

Host dev
    HostName 192.168.1.20
    User jmoon
    IdentityFile ~/.ssh/homelab_key
    # Wake on LAN before connecting
    ProxyCommand bash -c 'wakeonlan AA:BB:CC:DD:EE:FF; sleep 30; nc %h %p'

Host *.local
    User jmoon
    IdentityFile ~/.ssh/homelab_key
    StrictHostKeyChecking no
    UserKnownHostsFile /dev/null

Now ssh nas connects without thinking. ssh dev wakes the machine and waits for it to boot. Tab completion works.

Part 3: When a Machine Stops Earning Its Place

This is the section most homelab guides don’t write. It’s easy to justify keeping every machine. It’s harder — and more valuable — to be honest about which ones should go.

The Costs of Keeping a Machine

Every machine you keep has carrying costs, even if you never turn it on:

Electricity: A machine that draws 50W and runs 24/7 costs roughly $52/year at $0.12/kWh. Multiple machines at modest draw add up. A mini PC at 10W is $10/year. A full tower at 150W is $157/year. Multiply across your fleet and the electricity cost of “I might need this someday” becomes concrete.

Physical space: A machine that occupies rack space, desk space, or shelf space is blocking something else. If your homelab space is constrained, the physical footprint of an unused machine has real opportunity cost.

Heat and noise: Machines produce heat and noise even at idle. In a small apartment or home office, this affects comfort. Heat increases cooling costs. Noise affects sleep and concentration.

Maintenance overhead: Even a machine you rarely touch needs OS updates when it runs, has drives that age and will eventually fail, and exists as a surface for security vulnerabilities if it’s network-connected.

Mental overhead: The tax of knowing a machine exists and is running — even if you’re not actively using it — is real. Every item on the unfinished list (“I should really set that machine up properly”) occupies background mental space.

Opportunity cost: A machine sitting in a corner is hardware that someone else could be using. If it has market value, it could be money in your pocket for hardware you’d actually use.

The Framework: Honest Questions

Ask these questions about each machine honestly:

1. What does this machine do that nothing else does?

If the answer is “nothing” — if its workloads could move to an existing machine without significant downtime or effort — the machine is redundant. Redundancy is only valuable if you need the uptime guarantee; for most homelab workloads, you don’t.

2. How often do I actually use or depend on this machine?

Be honest. Not “I might use it.” How many times in the last month did something depend on this machine actually running? If the answer is zero or once, the machine is providing very little value.

3. What would break if I turned it off tomorrow?

If nothing meaningful breaks, the machine probably shouldn’t be running. If you’re not sure what would break, that’s a sign the machine’s role has been forgotten or superseded.

4. When did I last log into this machine intentionally?

A machine you haven’t touched in 60+ days is either running unattended (fine, if it has a clear always-on role) or slowly becoming outdated and unmanaged. If it’s the latter, it’s accumulating maintenance debt that will eventually demand attention at an inconvenient time.

5. Is the hardware still capable of doing its job well?

A machine that technically works but is so slow that using it is frustrating, or too old to run current software without significant workarounds, may be costing more in time than it’s saving in money.

6. If I didn’t own this machine, would I buy it today to do what it’s currently doing?

This reframing cuts through sunk-cost thinking. You paid $300 for that server six years ago. If you didn’t have it, would you buy it today (for whatever it’s currently worth used) to do what it’s currently doing? If the answer is no, the machine’s value to you has declined below its cost.

When to Consolidate

Before selling hardware, consider whether consolidation is the right move. Modern virtualization and containerization mean a single capable machine can run what used to require three machines.

Proxmox VE is the homelab standard for this. A machine with 32GB RAM and a modest CPU can run:

• A VM for your NAS (TrueNAS with passthrough to the physical drives)
• A VM for network services (Pi-hole, Unbound, DHCP)
• A VM or LXC for your media server
• A VM or LXC for your self-hosted services
• VMs for development environments

The consolidation math: one machine with passthrough to physical drives, a UPS, and good RAM is often more reliable, cheaper to run, more maintainable, and physically smaller than four separate machines doing the same work.

The tradeoff: a single point of failure. If Proxmox goes down, everything goes down. For most homelabs this is acceptable — you’re the only user and you can tolerate downtime. For anything that genuinely can’t go down (home automation that controls heating, security cameras), keep it on dedicated hardware.

When to Sell

A machine should be sold when:

• Its role has been superseded. You bought a NAS, then moved everything to a Proxmox VM on better hardware. The old NAS has no remaining role.
• The hardware can’t run current software adequately. 4GB RAM machines struggle with modern Docker workloads. 32-bit CPUs can no longer run most current Linux distributions. If you’re fighting the hardware to do basic tasks, the machine is costing time.
• The electricity cost exceeds the value. A power-hungry old desktop drawing 200W to run a service that a $70 Raspberry Pi 5 could handle costs more per year in electricity than a new Pi. Buy the Pi, sell the desktop.
• It hasn’t been powered on in 6+ months. If it hasn’t been on in six months, honestly assess whether it will be. If not, sell it while it still has value.
• It would be replaced immediately if it died. If the machine died tomorrow and you’d immediately buy a replacement (probably better hardware), you already know it’s doing something useful. But if it died and you’d shrug, that tells you something.

Where to sell:

• eBay for most hardware — broadest audience, good prices for anything recognizable
• r/homelabsales — community of buyers who actually know what they’re looking at; good for server hardware, network gear, unusual equipment
• Facebook Marketplace / Craigslist for local pickup — good for large/heavy items where shipping is expensive
• OfferUp / Swappa for laptops and consumer hardware

Setting a fair price: Look at completed eBay listings (not active listings — completed sales show what the market actually paid). Price at the median of recent completed sales. Account for your listing platform’s fees (eBay takes ~13%, PayPal adds ~3%).

If it won’t sell: A machine with minimal resale value might still have value to someone. Local hackerspaces, school robotics clubs, nonprofits, and community makerspaces often accept hardware donations. The machine gets used rather than landfilled, and you get the space back.

When to Recycle

Not everything is sellable. Hardware that’s:

• Too old to run current software (pre-2012 era PCs in most cases)
• Damaged or unreliable
• Too slow to be useful for any workload a buyer would care about
• Lower value than the time cost of selling it

Should be recycled through proper e-waste channels rather than thrown in the trash. E-waste contains lead, mercury, cadmium, and other materials that are harmful in landfill.

Finding e-waste recyclers:

• Best Buy accepts consumer electronics for recycling in the US, no purchase required
• Staples has a similar program
• earth911.com — searchable database of recyclers by material and location
• Local municipalities often have periodic e-waste collection events, sometimes free
• Manufacturer take-back programs — Dell, HP, Apple, and others have recycling programs for their products

Before recycling, always:

1. Wipe drives. shred -n 3 /dev/sdX or dd if=/dev/urandom of=/dev/sdX bs=4M for mechanical drives. For SSDs, the manufacturer’s secure erase utility (e.g., hdparm --security-erase or BIOS secure erase) is more reliable than shred due to wear leveling.

2. Remove and keep SSDs and RAM if they’re usable. An SSD from a machine you’re recycling might fit in another machine or be worth selling separately.

3. Check if it can be factory-reset before recycling. For devices like old Macs or Chromebooks, a factory reset makes the device much more useful to whoever processes it.

The Sunk Cost Trap

The hardest part of letting go of hardware is the sunk cost fallacy — the feeling that you paid real money for this machine, so keeping it is somehow recovering that investment.

It isn’t. The money is gone regardless of whether you keep the machine or sell it. The question is whether keeping the machine costs you more (electricity, space, maintenance time, mental overhead) than whatever you’d get for it.

The correct mental model: the machine’s past cost is irrelevant. Its current value is what it would sell for today. Its carrying cost is what it costs you per year to keep it. If carrying cost > current value / expected remaining useful years, and it’s not providing value you couldn’t get more cheaply another way, it should go.

A $300 server you bought five years ago that’s worth $80 today costs $60/year in electricity. That’s a 75% annual carrying cost. If it’s doing something a $70 Raspberry Pi could do, the math strongly favors selling the server and buying the Pi.

Part 4: A Practical Audit Process

Do this once a year (or right now, if you haven’t):

Step 1: Inventory

List every computing device you own. Include machines that are off, in storage, “being used for something later,” and everything that you know is connected to your network but can’t quite remember why.

For each machine, record:

• Hostname / name
• Hardware (rough specs: CPU generation, RAM, storage)
• OS
• Primary role (one sentence)
• Always-on or on-demand
• Approximate electricity draw (check the specs or use a Kill-A-Watt meter)
• Last time you actively used or needed it
• Estimated current resale value

Step 2: Categorize

Sort each machine into one of four buckets:

Keep — essential: Has a clear role, used regularly or provides a critical service, couldn’t be easily consolidated, earning its electricity cost.

Keep — consolidate to: This machine is staying, and some other machines’ workloads should move here.

Review — candidate for consolidation or sale: Unclear role, low usage, redundant, or hardware that could be replaced by something cheaper to run. Needs a decision.

Sell / recycle: Not being used, no credible future use, hardware past its useful life, or already superseded.

Step 3: Act on the “Review” Category

For each machine in the “Review” bucket:

• Can its workloads move to a “Keep — essential” machine with reasonable effort? If yes, plan the migration.
• Is the hardware worth selling? If yes, list it.
• Is the hardware not worth selling but recyclable? Schedule the e-waste drop-off.

Step 4: Reduce the “Essential” List

After consolidating what you can, look at the remaining “essential” machines with fresh eyes. Are all of them truly irreplaceable? Could any two be combined? Is the separation that felt important still important?

For most homelabs, a sustainable fleet ends up being:

• 1 daily driver (laptop or desktop)
• 1 server machine (Proxmox or similar, doing most of the server work)
• 1 NAS (or storage built into the server with drive passthrough)
• 1 small always-on device for network services (Pi-hole, WireGuard/Tailscale)
• Maybe 1 specialized machine for a role that can’t be virtualized

Five machines, clear roles, manageable maintenance. Anything beyond that needs a strong justification.

The Underlying Principle

Hardware accumulates because getting it is easy and fun. Letting it go requires admitting that a purchase or a project didn’t pan out, or that your priorities have changed.

The homelabbers who seem to enjoy their setups most aren’t the ones with the most hardware — they’re the ones who’ve converged on setups they actively use and maintain, where everything has a reason to be there.

A smaller, well-organized fleet that you understand completely is more satisfying and more useful than a sprawling collection of machines running services you’ve forgotten about. It’s also more secure, cheaper to run, and far less likely to produce the 10pm emergency where something critical broke because a machine you weren’t watching ran out of disk space.

The question to ask about any machine isn’t “could this be useful?” — almost any machine could be useful in some scenario. The question is “is this machine, specifically, worth what it costs me to keep it?” When the answer is honestly no, letting it go isn’t admitting defeat. It’s good systems thinking applied to your own infrastructure.