Agentic Homelab

Chapter 1 — Planning the homelab.

Maybe you've got an old computer you'd like to use for Plex. Or you want one place to keep the family photos, with a backup you can actually restore. You might just want the lights to turn on at the right time. Those are good places to start. You don't need to decide on every service you'll ever run before you try the first one.

What does help is knowing who will use it and what they'd miss if it stopped working. Having Plex down for an afternoon might be fine. Losing the internet during somebody else's work call probably isn't. Tell your AI assistant about those differences. Otherwise, it might suggest a technically reasonable change at a terrible time.

The AI assistant can look at your equipment, help you choose software, and work through problems with you. You might tell it, “I want to watch these movies on the living-room TV. Here's the computer I've got, and here's where the movies are now.” That's enough to begin investigating. You don't have to learn every setting before you can ask for help.

Before it changes anything, have it explain what it found. Does that computer have enough memory? Can it read the movie folder? Are there files on its disks that you haven't copied anywhere else? Some of those questions need your input. A folder called “old stuff” might contain school photos that matter to somebody else in the house. The AI can't decide whether they're worth keeping.

Once you've chosen a first project, test it the way people will use it. With Plex, play a movie on the TV. A dashboard saying the server is running doesn't tell you whether that TV is signed into the right account or whether Plex can open the file. Ask the person who normally uses it to try their account too.

If it doesn't work, the AI can help narrow down the problem. Ask what each check will tell you. If it's proposing changes to the network before checking whether the movie file exists, bring it back to that question. A useful diagnosis gives you a reason for the next step.

You can also give the AI permission to handle routine work without asking every time. Reading the logs for a particular service might be fine. Later, you might let it restart that service if it stops. That doesn't require giving it control of every disk and account on the machine. We'll set up a separate account for its work and check that the permissions do what we expect.

For a difficult decision, another model can review the plan. It might catch a missing step or disagree with the first model's reasoning. You can compare their explanations and decide what to do. Neither model gets to decide which family files you can lose or when it's okay to interrupt everyone else's internet connection.

We'll begin by keeping notes outside the conversation and making sure you can still connect to the server when something goes wrong. Then we'll check the computer, choose its operating system, and set up storage and backups. Once one service works, we can add monitoring and automate some of the maintenance.

The written field guide goes with this recording. Use it when you need the commands, configuration files, or current product instructions. Here, we'll work through why you might choose one setup over another and what to look for when you try it.

Chapter 2 — AI permissions and recordkeeping.

For this example, we're working from a Mac and connecting to a Linux server. Keep a project folder on the Mac with notes about the server, what's running on it, and what you've changed. Your AI assistant can update those notes as you go.

They don't need to be a transcript of every conversation. A useful entry might say, “Plex now reads movies from the NAS. We played a movie on the living-room TV, and it worked. The old copy is still on the USB drive. We still need to try restoring a backup.” Include the actual folder locations and which settings file changed. Next time, the AI can check those notes against the machine instead of starting over.

You should be able to read the notes without opening the AI app. Keep a backup on a separate drive or another computer too. If the Mac dies, you'll want the instructions for getting back into the server somewhere else. If that backup is encrypted, you'll also need its password. We'll cover where to keep that in the storage chapter.

Full conversations and logs can contain more than you meant to share: passwords, private filenames, family details, or text copied from a website. If you need to keep them, use encrypted storage outside the project folder the AI normally reads. For a second model's review, send the settings and error messages it needs, with passwords and unrelated personal details removed. Usually, you don't need to hand over the whole history.

The next question is how you and the AI get into the server. From the Mac, you'd normally use SSH. That lets you open a terminal on the Linux machine and run commands there. You'll need an account on that machine.

Keep an administrator account that you control, separate from the AI's account. Your account lets you install software and recover the system. Start the AI's account with access to the services and logs you're working on. Once you've allowed it to read Plex's logs, for example, it can keep doing that without asking each time.

The account permissions have to match what you've agreed to. If the AI can get unrestricted administrator access, a note saying “ask first” won't keep private files out of reach. Test the restriction with a file you don't care about. Give it the same permissions as your private files and have the AI try to open it. You should see “access denied.” Then make sure it can still do an allowed job, such as checking Plex's status.

Some work needs more access. The AI can prepare an installation command and explain it for you to run. If you later want it to repeat one action on its own, give it a command limited to that action. We'll use a specific example with Docker. You don't have to turn every status check into an approval request to keep disk erasure under your control.

You'll also want a way to connect if you break the normal network settings. One option is a direct Ethernet cable between spare ports on the Mac and server. You may need a network adapter. Each end gets a fixed address on a separate small network, so the connection doesn't depend on the router assigning addresses or looking up names.

The AI can check the addresses you're already using and work out a suitable range for that cable. Apply those settings to the spare ports and leave the normal connection alone. Keep the server's address and login instructions in your project folder, along with the steps for turning your usual connection back on.

Try the cable while you're sitting with both machines. Turn off the Mac's other network connection, then open a fresh SSH connection using your recovery account. Otherwise, you might still be going through Wi-Fi without realizing it. You want to know the cable works before you need it to fix something.

If you plan to leave jobs running on the Mac, restart it once and check that you can still open the project and connect to the server. Check its sleep settings too. A job scheduled for three in the morning needs the computer awake at three in the morning. Checks that must run all day may be better off on the server.

Long jobs also use time in different ways. Copying a large library might take hours without much AI activity. Reviewing an access rule could use many model requests while changing almost nothing on the machine. Have the AI report progress in terms you can use: how much has copied, whether people can still use the service, and whether it's waiting for you. If it reaches a usage limit, it should leave notes about what's finished and what remains.

When a change fails, save the error and the settings before trying another fix. Going back to the previous version may help, but an older program might not understand data changed by the newer one. The AI should explain what recovery involves. You can decide whether to restore the old version, leave the service stopped while you investigate, or try a different repair.

Chapter 3 — Server hardware and operating systems.

An old gaming computer can make a useful server. Before spending money on upgrades, see how it holds up when it's working hard. You may be asking it to stay on all the time, with disks and network connections it hasn't used much before.

Start with a memory test you boot from a USB drive. For the disks, check whether the manufacturer provides a diagnostic tool. The AI can look up the right tools for your hardware and explain how to run them. Save the results and read any errors. “Test completed” doesn't necessarily mean the test passed.

Keep an eye on temperatures while the tests run. If the computer overheats or shuts down, find out why before putting your files on it. Drive health reports can point to problems too, although a clean report doesn't guarantee a disk won't fail.

Try copying a test folder across the network and back. If the connection drops or the transfer stalls, you can investigate before copying a whole library. Compare the checksums of the original files and the copies. A checksum is a number calculated from a file's contents. Matching numbers give you a way to check that the contents arrived intact.

You'll also need to choose an operating system. Ubuntu Server is one option if you want to learn a general-purpose Linux setup. Its long-term-support releases get updates for several years. Ubuntu's release page shows when support ends for the version you're considering.

If shared storage is the main reason for the machine, look at TrueNAS too. It gives you a web interface for managing disks and shared folders, so you don't have to put all of that together yourself. You then use TrueNAS's tools and supported procedures to manage and update the system. Ubuntu leaves more of those choices to you.

Proxmox is worth considering if you want several virtual machines. Each acts like a separate computer with its own operating system. That can be useful when you want to experiment without changing the software in another VM. It also adds another system to recover if the machine fails. For a single Plex installation, you might decide that Ubuntu or TrueNAS is enough.

Before opening any installer, have the AI list the disks, their models and serial numbers, and what's already on them. Decide which files you're keeping and make separate copies on disks the installer won't erase. Open some photos, documents, and videos from those copies to make sure they work. If a copy fails, you still have the originals while you figure out why.

Don't identify a Linux disk by a short name such as “s d b” alone. Those names can change after a restart. Match the serial number in your notes with the one the machine reports. The AI can collect that information and build the table for you. If it can't tell two disks apart, check the labels on the drives themselves before choosing one to erase.

Keeping the operating system on its own small disk can make recovery easier. If that disk fails, you can reinstall Linux while leaving the photo and movie disks alone. You'll still need to identify the disks during the reinstall; having separate drives doesn't make the installer know your intentions.

Once the system is installed, try the administrator account and the AI account. Check that your recovery cable works with the Mac's other connection turned off. You're checking the actual machine now, so you can catch a missing driver, a blocked SSH connection, or a network setting that didn't survive installation.

Power is worth thinking through before people depend on the server. A UPS is a battery backup that can keep equipment running long enough for a short outage or an orderly shutdown. Include any network equipment or separate storage box the server depends on. Keeping the server on won't help much if its storage loses power immediately.

The manufacturer's runtime chart shows how long the battery should last for the amount of power you're using. Check the combined power use of what you plan to plug in. For automatic shutdown, the UPS also needs a way to tell the server when the battery is running low, often over USB or the network.

After setting that up, follow the manufacturer's shutdown test at a time when nobody needs the services. Tell the people who use them when they'll be down. Keep your recovery instructions nearby in case the server doesn't come back on its own.

Once the power is back, open a shared folder from the Mac. Create a file called “restart test,” save a change, and open it again. That checks whether you can actually use the file share after the restart. If an app depends on a separate storage box, it also needs to wait for that storage before it starts writing files. That's where we'll begin the next chapter.

Chapter 4 — Storage and backups.

Suppose your Linux server gets its files from a separate storage box, often called a NAS. Linux can attach that storage to a folder on the server. Attaching it there is called mounting it.

This example is about the Linux server's configuration, not just opening a shared folder in the Mac's Finder. A backup job on the server might write to a folder called “Family,” expecting it to be on the NAS. If the NAS wasn't mounted when the job started, that folder could still exist on the server's own system disk.

If the job can write there, it might fill the system disk while you think it's saving files to the NAS. When the NAS is mounted again, its files appear at that location. The files you accidentally saved underneath are still taking up space on the server, but you won't see them in that folder.

Just losing the network connection doesn't necessarily cause this. If the NAS remains mounted, the job might get stuck or report an error. The local-folder problem happens when the mount is missing. A job running in the background on a server may not have a pop-up to tell you something's wrong.

On Linux, the service manager, systemd, can make a job wait until the configured storage is mounted. The job can also check that the folder belongs to the right disk or NAS before it writes anything. Checking that the folder exists won't tell you that.

Have the AI show you what's mounted there. Try the check on a temporary test folder with its storage unmounted, so it's no longer attached to that folder. The job should stop and report the missing storage. You shouldn't find new files in the server's local folder. The NAS could still disappear after that check passes, so the job also needs to report an error if it can't finish writing.

Before setting up storage or copying your files over, check the list of disks again. If a disk has been replaced or its name has changed, have the AI compare the current information with your notes. Resolve which disk is which before writing to it.

You may hear people recommend ZFS for storage. It's one choice, and it helps to know what you're getting. ZFS can group disks into a pool and use checksums to check the data as it reads it. If the layout provides another good copy, ZFS can use that to repair damaged data. Without a good copy, it may detect the problem without being able to fix it.

A two-disk mirror is a straightforward example. Both disks hold the same data. Two four-terabyte disks give you about four terabytes to use, minus some space the filesystem needs for itself. One disk can fail and you've still got the other. Ask how you could add capacity later, since that depends on the disk layout and the software version.

ZFS can also run a scrub, which reads through stored data to check for damage, including files nobody has opened recently. Schedule those checks and include their results in your storage reports. You want to know whether each scrub finished and whether it found errors.

For a single Linux disk, you might choose ext4 or XFS with a separate backup system. Btrfs is another filesystem to consider if you want checksums and snapshots. TrueNAS uses ZFS and gives you tools to manage it. If you already have a NAS that does what you need, with backups you've successfully restored, you may have no reason to change it.

With ZFS, you can divide a pool into datasets. Each is an area of storage with its own settings, including permissions and space limits. A download app's temporary files could have their own dataset and a quota, so they can't use every last bit of space needed for family documents. Your AI can help choose a limit and show what happens when the app reaches it.

A mirror, a snapshot, and a backup protect against different problems. If you delete a folder on a mirror, that deletion affects both disks. A snapshot can give you an earlier version of the folder on the same storage system. Restore it to a different folder first so you can check it without overwriting anything else.

If the whole storage box is stolen, its snapshots may go with it. That's why you'll want a backup somewhere separate, with older versions of your files. A synced folder on another computer might repeat your deletion there, so check whether the sync app keeps history and how far back it goes.

Choose the backup schedule based on how much recent work you could stand to lose. If losing yesterday's photos would be a problem, backing up once a week won't be enough. You might make a different choice for movies you can replace. The AI can help calculate space and schedules once you've told it what matters.

Then try restoring a photo and a document to a new folder and open them. Make sure there's enough space for the restore before starting. With a service such as Plex, you'll also need its settings and database. Getting the movie files back is only part of recovering the service.

The backup password needs some planning too. Take restic as an example. It encrypts the backup, and you need a password to unlock it. If you're saving to cloud storage, you'll also need a credential for that destination, such as an access key. The access key gets you into the storage; the backup password lets you decrypt the files.

Save a recovery copy of the password in your password manager, and keep an offline copy somewhere away from the server. Check that you can get to one of those copies from another computer. Otherwise, you could lose the server and discover the only copy of the password was on it too.

For an automatic restic job, you can use its password-file option. Open a terminal yourself, outside the AI session, and use your administrator account to save the password in a file. Restrict that file so only the backup service and administrator can read it. Tell restic where it is, and it reads the password each time the job runs. Entering the password during the initial setup doesn't configure those later runs.

The destination access key needs a protected copy too. Follow the storage provider's instructions for giving its software that key. The AI can prepare the instructions without seeing the secret. Test the permissions with a made-up password first. After confirming that the AI account can't read the file, enter the real password yourself and run the backup as the backup service. That checks whether the job can read what it needs.

Some backup destinations support append-only access. That lets the routine job add backups without permission to erase the old ones. Check whether your particular setup supports it; it isn't something every provider offers. When it does, a separate maintenance account can handle deleting old backups. Read the backup tool's cleanup instructions so you preserve the history you still need.

After a restore, check who can open the files. Linux records ownership with user and group numbers. If the same number belongs to somebody else on a replacement server, that account might get access to the restored files. Keep a note of which numbers belong to which accounts. The AI can compare them across the machines that use your storage.

From the Mac or Windows computer people normally use, open the shared folder through SMB. Try a family document with an account that should have access, then with one that shouldn't. Repeat that check after a restart and after a restore. If you've set more specific permissions, called access-control lists, the backup needs to preserve those as well.

When you move a library, copy the files while keeping the originals. Have the computer compare file counts and checksums and report anything missing or different. In Plex, update the library folder and let it scan. Try a movie after removing Plex's access to the old folder, while leaving the original files on the old disk. That makes Plex use the new copy.

Check that the backup configuration includes the new location. Run it, restore the same movie into a separate test folder, and play the restored file. After those checks, you can decide whether you still need the old copy.

Chapter 5 — Installing Plex and other services.

Before adding another app, consider whether you want to maintain it yourself. Running Plex at home might give you the movie library you want. For something else, a hosted service might already do the job. Having a spare computer doesn't mean you have to move everything onto it.

If you choose Plex, you'll probably find installation instructions that use Docker. You download a packaged version of Plex called an image. It includes much of the software Plex needs. Docker starts that image in a container with the folders and network access you've configured. You can use the same image when you rebuild the server.

Look closely at the folders. Plex reads the movies, but it also creates settings and a database. Those need somewhere to live when you replace the container. One option is a bind mount, which connects a folder inside the container to a folder you've chosen on the server. Another is a volume, where Docker manages the storage separately from the container. Either can keep the data through a container replacement when it's set up correctly.

If the database is saved only inside the container, deleting and recreating that container can lose it. Before starting, have the AI show you where the database will be kept and how it will be backed up. A Compose file helps describe the setup. It's a text file that names the image and its settings, including the folder connections and network options. The AI can walk through it using your actual folder names.

Plex needs to read the movie library to play it. It doesn't need permission to rewrite the original movies. Its database and settings do need a writable location. Check Plex's instructions before putting that database on a network share. Databases rely on controls over when different processes can change their files, and some network shares don't handle that the way the database needs.

Copying a database while the app is changing it may also give you a backup that won't restore properly. Use the app's supported backup procedure, or stop the app while copying its data. Try restoring into a separate test setup and open the app there. With Plex, check that the library and settings appear as expected. Keep that test separate from the live installation and its data.

Docker permissions need some care. If an account can start any container it wants, it can often give that container access to the entire server. Start by having the AI prepare the Compose file and explain the installation command. You can review and run the administrator step yourself.

For later automation, put the approved Compose file and supporting settings in a folder only an administrator can change. The AI can get a fixed command that uses those exact files, without an option to substitute another configuration. It can still perform routine status checks with the permissions you've already given it.

Try the process with a simple web page before putting household files into it. Give it an empty data folder and keep it reachable only from the server. Check whether the page loads and whether it comes back after a restart. Then remove it and see which files remain. If the setup fails, save its status and errors before cleanup so the AI can help explain what happened.

This is also a place to try resource limits. Docker can cap a container's memory and CPU use. Disk space needs its own limit. A download folder can fill a disk even when the container barely uses the CPU. Have the AI show where temporary files go and what keeps that folder from growing indefinitely.

Once Plex is installed, start a movie on the TV you normally use and leave it playing. On the Mac, open Plex Web, choose Activity, then Dashboard, and expand the session under Now Playing. You'll see what Plex is doing with the video and audio streams.

Direct Play means the device can use the media as it is. Direct Stream usually means Plex is repackaging it without re-encoding the video. If playback buffers in those cases, a faster graphics card probably isn't the first thing to buy. Check the connection between the server and the device.

If it says Transcode, Plex is converting something. Look at whether it's converting video or only audio. Try the same scene with subtitles off and check the quality setting in the TV's Plex app. Some subtitle formats make Plex convert the video. Asking for a lower streaming quality can do that too.

When video conversion is involved, look at how hard the server's CPU and GPU are working. The AI can help interpret that alongside Plex's playback details. If Plex is using hardware acceleration, the expanded session shows the letters “h w.” Check Plex's requirements for your hardware and software before buying an upgrade.

Try one change at a time. A wired connection can help you check whether Wi-Fi is the problem. Playing the same movie on another device can help isolate an issue with the TV. If a change fixes it, repeat the original setup once to check that you've found the difference that matters.

Watching from outside the house also depends on your home internet's upload speed. A movie that plays locally may need a lower streaming quality when you're away. Try it from a phone using cellular data with Wi-Fi off, and watch that session in Plex again.

For web apps, you may want names you can remember rather than a different port number for each service. The port tells the server which program should receive a connection. A reverse proxy, such as Caddy, can send incoming web requests to the right app. That helps with routing, but you still need to decide who can get in.

For private access while you're away, a VPN can connect your phone or laptop back to the home network after you log in. If you want an app reachable without that VPN, decide who should have access and how the app will check their identity. Test from outside the house as well as inside it.

For a home-only app, you shouldn't be able to open its admin page from your phone with Wi-Fi and the VPN turned off. Try a login that should work, then one that should be refused. The AI can help you check both results.

Single sign-on lets one login service handle access to several apps. Before depending on it, test a separate local account for each essential app. You want a way in when the shared login service or internet connection is down.

Home Assistant has its own installation choices. Home Assistant OS handles some management tasks for you that you'd need to do yourself with a container. Look at the devices you want to connect and choose a supported setup that fits them.

Begin with something you can easily try, such as putting a lamp on a schedule. Turn the automation server off and press the switch. Does it still work? That depends on the device and how you've connected it. Before adding heating or door locks, find out how you'd use their own controls if the server or network went down.

Eventually, you may stop using an app. With a photo app, start by asking what you want to keep. Can you export the original pictures, albums, and captions? Open that export before uninstalling anything. Check where the app stores its database and whether another app uses any of the same folders.

Removing a container usually leaves its separate folders and volumes in place. Some Compose commands can remove volumes too. Have the AI explain the exact command before running it, and decide which data you're finished with before deleting it.

Remove access keys that were only for that app, and turn off its public route if you gave it one. Try the old address to make sure it no longer opens the app. Check the files you've kept and note where they are. That way, the next AI session can tell why the data is still there.

Chapter 6 — Monitoring, automation, and updates.

Once a service works, you probably don't want to check its dashboard every day. Start with a problem you'd want to hear about. Maybe the backup disk is filling up. A small program could check its free space every fifteen minutes and alert you when it gets low. You choose how much free space should trigger the warning.

That comparison doesn't need an AI model. A Linux timer can start the program on schedule. The program can save its last result so it knows whether the problem is new or whether it has already sent an alert.

The AI can help write it and test it with made-up measurements. Give it plenty of free space, then too little. Does it send an alert? If you give it plenty again, does it notice that the problem is gone? Check that it doesn't send the same warning every fifteen minutes.

Bring the AI back in when you want help understanding why something changed. If a backup suddenly got much bigger, it could compare the recent files and settings and suggest where to look. It doesn't need to repeat the same arithmetic on every run. And not every check needs a timer. A failed backup can report the problem as soon as the job ends.

Codex and Claude offer scheduling features too. A recurring task for a local project in Codex Desktop needs the computer and app running. It could review the week's backup reports and prepare a summary. Claude Code's slash-loop command repeats work in the current terminal session, so those checks stop when the session closes. Claude also offers scheduled cloud work, but those jobs need an authorized way to reach your files or services. They can't simply open a folder on your Mac.

Check where the task runs before depending on it. If monitoring must continue when your laptop is off, put the basic check on a computer that stays on. The AI can help write and review the program without being needed for every run.

An internet outage raises another question. How will the server tell you the connection is down if it can't send a message through that connection?

You can have it check in regularly with a monitoring service outside the house. Tell that service how often to expect a message and where to alert you if one doesn't arrive. It has its own internet connection, so it can still notify you when yours is down.

Test that by pausing the check-ins. You don't have to disconnect the whole house. Confirm that the alert reaches your phone, then turn the job back on and check for a recovery message. The outside monitor won't know whether the missing message was caused by a power failure, the router, or the internet provider. Once you can reach the server, its logs can help narrow that down.

Useful alerts tell you which service needs attention and where to find the details. You can keep routine successful checks in a report rather than sending a message every time. An optional app briefly failing during planned maintenance may belong in that summary too.

For automatic repairs, choose a specific action and limit how often it can run. If a program quits and you've approved restarting it, the service manager can make that attempt. A program can also stay running while failing to do its job. Docker marking a container unhealthy doesn't, by itself, restart it.

Plex might still be running while its movie storage is missing. Restarting Plex repeatedly won't reconnect the disk. A repair tool should check whether Plex can reach its storage before trying a restart. Save the original error and record what the tool tried. Afterward, repeat the check that found the problem. For playback trouble, that may still mean trying the movie on the TV; a process-status check can't prove the TV works.

If the retry limit is reached, stop and send the details to you. You can ask the AI to investigate further without letting it make bigger changes on its own. Try the pause control too. Pause the automation and cause the same test failure again. Does it stay paused, or does another scheduler launch it anyway? Every way you've given that job to start needs to respect the pause.

Updates are another place the AI can help. Have it read the release notes and explain changes to settings or stored data before installing anything. Update one component at a time so you can tell which change caused a problem.

For Plex, keep the old installer or container image and make a supported backup of its database. After the update, play the same movie on the same TV and check that the same accounts can still get in. A newer version may change the database format. If you go back to the old program, you may need the old database backup to go with it. Find that out from the update and recovery instructions before starting.

Firmware is the software built into devices such as routers and storage controllers. Recovering from a failed firmware update can be very different from reinstalling an app. Look up the manufacturer's procedure first so you know what you'd have to do.

You can practice quite a bit of recovery without taking services offline. Restore a document into a new folder and open it while everyone keeps using the file server. For a bigger test, use a spare computer or virtual machine. Follow your notes to install the software, then restore one service. Give the test machine its own address so it doesn't conflict with the live server.

If you want to disconnect the server's normal network connection and try the recovery cable, people may lose access. Pick a time with them first, and be there to reconnect it. The point is to find missing instructions and broken connections while you still have a working system to help you fix them.

A replacement machine may need you to reactivate an app's license or log in again. Include those steps in the recovery notes. Check that you can recover the password manager and any backup access keys without relying on the machine you've lost.

You may eventually need another server. Perhaps you've run out of capacity, or people can no longer wait while you fix the first one. Kubernetes can help decide where services run across several machines and restart them when they fail. k3s is a smaller Kubernetes distribution, but you still have to manage the network and storage for the group of machines, called a cluster.

It won't automatically keep two databases in agreement. If two copies of an app make separate changes to their data, moving between them can lose work. Follow the application's instructions for migration or replication before allowing both copies to accept changes.

Try a simple web page with no database as a first experiment. Stop its running copy and see whether the cluster starts another. Can you still reach the page at the same address? That lets you learn how service restarts work before taking on the data. Keep recovery instructions, backup credentials, and a way to reach the machines available even when the cluster is down.

If your services fit on one computer and a short outage is acceptable, you may be happy with Compose for a long time. There's plenty of useful maintenance to automate without moving everything into a cluster.

When you finish a session, have the AI update the project notes. What changed? What worked when you tried it? What's still unfinished? Next time, it can compare those notes with the running system and continue without asking you to explain the whole setup again.

You don't need to finish all of this at once. Start with one service you want to use, and practice restoring it before adding more. What you learn there will help you decide how much you want to run at home.

Thanks for listening to Agentic Homelab, and thanks to Lyrova, Inc.