Local AI Agent Builds a Home Media Server, Then Debugs Its Own Mess

The interesting part of this experiment isn't the installation. Plenty of tools can script a Docker stack. What matters here is whether an agent can notice that a container is running but the application inside it is broken, then find the cause and fix it. That's the part of home server work that usually eats the evening, and it's where this test got most useful.

The hardware is an Olares One, which is built for local AI. It has an Intel Core Ultra 9 processor, 96GB of RAM and an RTX 5090 mobile GPU with 24GB of VRAM. Olares supplied the unit for this test. The agent doesn't run on the server it manages. It runs on the Olares One and reaches across the network to a much smaller machine.

The Target Machine and the Agent

The server is a GMKtec NucBox G5 mini PC with an Intel N97 processor, 12GB of RAM and a 512GB internal SSD. A separate 480GB USB SSD holds the application data and media. The author installed Ubuntu Server 26.04 LTS on a fresh system, enabled SSH, and stopped there. No Docker, no containers, no config files. The idea was to start from a clean slate and see how far the agent could take it.

Olares OS handles app and model management on the Olares One. The author installed a Qwen3.6 35B language model and served it through Olares Router, which does the local inference.

Olares offers several agent options, including Lares, OpenClaw and Hermes. The author chose Hermes, and the distinction matters. The model and the agent are different things. Qwen3.6 generates text. Hermes is the agent framework that gives the model tools: it can run a command, read the output, and decide what to do next. Without that loop, the model can only suggest commands for you to run.

Here's the loop in practice. Hermes asks the local model what to do, the model picks a command, Hermes sends it over SSH to the Ubuntu box, reads the result, and the cycle repeats until the task is done or the agent gives up. Inference happens on the Olares One in real time. Installation still needs internet access to pull packages and container images, but the reasoning doesn't go to a cloud API.

That has a cost angle worth noting. An autonomous agent can make hundreds of model calls on a complicated task, which can add up to hundreds of thousands of tokens. On a usage-priced cloud API, that bill grows with every retry. On a local model, the marginal cost of another call is zero. The trade-off is that you're limited by the hardware you own, and you have to accept slower or less capable models than the top cloud offerings.

Access, Permissions and a Necessary Warning

Before anything gets installed, the agent needs to log in. The author generated an SSH key, added the public key to the server's authorised keys, and set up a hostname alias so Hermes could connect without a password prompt. To let the agent install packages and change configuration without stopping for a password, passwordless sudo was enabled for its user.

That amounts to full administrative control of the machine, and the author says so plainly. They wouldn't do this on a production server holding important files or services, particularly without restrictions and safeguards. This was a disposable test box with nothing on it worth losing. If you try something similar, treat the agent's account as root and build the server so a mistake is cheap to undo.

The first task was a read-only check. Hermes was asked to report the OS version, CPU, memory, storage and whether Docker was present, and to change nothing. It ran five commands over SSH and returned accurate results. That confirmed the connection worked and that the agent was executing commands, not just describing them.

The Main Build Brief

The main prompt was long, and it was deliberately loose on method. The author asked for Docker Engine and Docker Compose, then four applications: Jellyfin for streaming video, Immich for photos, Nextcloud for personal cloud file storage, and Homarr as a dashboard linking everything together. The brief also covered persistent storage, restart policies, supporting databases, Intel hardware acceleration for Jellyfin where the hardware supported it, and browser access across the local network.

The constraints were the part a careful engineer would check first. The agent could not format or repartition drives, delete existing data, or expose anything to the public internet. It couldn't disable SSH or make changes that might lock it out. Untrusted install scripts had to be inspected before running. Passwords and API keys were not to be printed in responses. Anything potentially destructive required asking first.

Notably, the author didn't supply Compose files, container choices or directory layouts. They wanted to see whether the agent could design that itself. The task also explicitly told it to execute the work, not hand back a script for the author to run.

First Pass: Everything's Running, Except It Isn't

The initial deployment took about 15 minutes. Hermes installed Docker, deployed the four applications, and reported that all four were running, with local network addresses for each.

Testing told a different story. Jellyfin worked and let the author create an admin account. Its library was empty, as expected, since no media had been added yet. Homarr loaded, but as an empty dashboard with no links. Those two were fine.

Nextcloud showed a completely blank page with no error message. Immich loaded its interface and then threw an HTTP 500 error. So two of the four applications were unusable despite the agent's report.

This is the classic Docker trap. A container reporting "running" only means the process started. It says nothing about whether the application inside has initialised, connected to its database, or is serving valid responses. Hermes's first verification checked the container state, and that wasn't enough to catch application-level failures. A human would have caught this by opening the browser, which is what the author did.

Second Pass: Debugging Against Real Symptoms

This is where the test got interesting. The author went back to Hermes, described exactly what they saw in the browser, and asked for a proper investigation. For Immich, that meant container logs, database connectivity, environment variables, migrations, networking and storage permissions. For Nextcloud, it meant Docker logs, web-server and PHP errors, Nextcloud's own application logs, database connectivity, file permissions, and the use of its command-line admin tools where appropriate.

The author also asked for the Homarr dashboard to be finished, with shortcuts to Jellyfin, Immich and Nextcloud, suitable icons, status monitoring, and Docker container status where supported. The brief asked the agent to check Homarr's documented API or MCP tooling for the installed version rather than guessing endpoints. It also said not to touch Homarr's internal database without a supported alternative and explicit approval. Any API key needed had to be requested, not improvised.

The final acceptance checks were specific: Jellyfin still working, Immich and Nextcloud responding without server errors, Homarr shortcuts functional, containers and dependencies healthy, and a list of anything still needing browser-based work.

Hermes took about another 15 minutes. It inspected containers and configuration, made changes, and got both Nextcloud and Immich responding properly. The Homarr dashboard ended up with links to all the applications in one place.

Some work stayed manual. The author still created administrator accounts through each application's web interface. But they didn't have to hand-edit Compose files or read through logs to find the fault. For me, that's the headline result. Deploying containers is a solved problem with scripts. Diagnosing why a deployed app returns a blank page is the part that usually requires someone who knows where the logs live.

Importing Media: Videos, Documents and a Mount Problem

With the apps working, the author plugged in a USB flash drive holding video files, 43 photographs and a set of generic test documents. The drive was in three folders for movies, photos and documents. The brief didn't give the device name or the application storage paths. Hermes had to work those out from what it had already configured.

The import brief had hard rules. Source files had to stay unchanged. Copies only, no moving or deleting. No reformatting. Keep original filenames, avoid duplicates, and verify counts against the original inventory. Documents had to go through Nextcloud's proper indexing, not be dropped into internal storage directories.

Videos. Hermes identified three video files, copied them into an organised Jellyfin media directory, and the author could play them back through the web interface.

Documents. The documents went into a Nextcloud folder and appeared in the web interface where expected.

Photographs. This is where the import stalled. Hermes copied all 43 photos onto the server, but none appeared in Immich. The reason is worth understanding. Immich doesn't scan the whole host filesystem. For an external library, the photos must sit in a path the Immich container can see. The container has to mount that directory, and then Immich has to be pointed at it and index it. The author checked the container and found the photo directory wasn't mounted. The files were on the host, but Immich had no route to them.

The fix was a read-only bind mount. The author asked Hermes to add the photo directory to the existing Compose configuration as a read-only volume, keep the existing data mount and databases intact, recreate only the affected container, and then verify that the mount appeared in the container inspection, that all 43 photos were readable from inside, and that Immich stayed healthy. The volume line was in this form:

/mnt/media/photos:/external-photos:ro

Read-only is the right default for a source directory you don't want the application modifying. The fix took about five minutes. The author still had to finish the external library setup in Immich's web interface, since creating and scanning the library was handled through the app's own authentication. The brief had asked Hermes to try creating it through a supported authenticated API, and to hand that step back if it couldn't. So the photo pipeline wasn't fully hands-off, but the mount troubleshooting was.

Hardware acceleration for Jellyfin was part of the original brief, but the test doesn't establish whether it was working by the end, so treat that as unverified.

Dashboard Background, Made Locally

The Olares One can also run image models. The author installed Flow Studio on Olares, which generates images and video through locally running models. For a dashboard background, they wanted something subtle: dark, with blue and green lighting, and nothing busy enough to compete with application names and icons. Several options were generated, all on the device rather than through a cloud image service. The chosen image went into Homarr, and the colour scheme was adjusted to suit it.

It's a cosmetic step, but it's a fair demonstration of what the same box does beyond chat. The music at the end of the video was also generated locally, using ACE-Step 1.5.

How Much Time Did It Save?

The author built essentially the same server manually for an earlier project, and it took around four hours from start to finish. This run's agent-driven work broke down like this:

Those 44 minutes don't include installing Ubuntu, setting up Hermes on the Olares One, or configuring SSH. They also don't include the browser setup screens or the checking that the author did. Even so, against the three-to-four-hour manual baseline, the agent handled the installation, Docker configuration and troubleshooting, which are the parts where the author usually spends most of their time, in a fraction of the time. The author was also free to do other things during most of the run.

What Worked, What Didn't, and Where the Line Sits

It's worth being precise about the alternative. Conventional automation can already do most of this. You could write Compose files covering every app, storage mounts, networking and supporting databases, plus scripts to install Docker and create directories. If you're building identical servers repeatedly, that's the better route, because it's repeatable and reviewable. For a one-off build, though, the agent meant the author didn't have to prepare any configuration in advance. They described the goal in plain language, gave the agent access, and let it choose the commands.

The same applied to fixes. The author didn't need to know which file to edit or which log to read. They described the symptom, and the agent did the diagnosis.

The limits are real, though. The first verification was too shallow and reported success on a broken stack. Diagnosis and correction still depended on a human noticing the failure in a browser. Account creation, the Immich library setup and some onboarding screens remained manual. And the agent's authority was total, because that was the setup. A production box with real data would need scoped credentials, backups, and a rule that destructive operations get confirmed first. The brief's "ask before destructive changes" line only protects you if the agent actually follows it, so that needs testing too.

There's also a quieter lesson. A local model keeps the reasoning on your hardware and removes per-token billing, but you're bounded by what that hardware can run. The Qwen3.6 35B model on a 24GB-VRAM mobile GPU is a different proposition from a frontier cloud model, and the author didn't claim otherwise.

Where This Points Next

My read is that the most useful thing here wasn't the 44-minute build. It was the feedback loop. The agent could run commands, read logs, compare results against a symptom described in plain English, and change a Compose file. That's the same loop a sysadmin runs, and it's where a local agent starts to earn its keep.

The Olares One is expensive, and I wouldn't buy one only to run a few containers. If you want to run larger models locally, experiment with autonomous agents, and avoid per-call inference bills, the case is clearer. And the author's closing question is the right one to ask yourself: would you give a locally running agent root on a machine you care about? For a disposable box, this test says yes, with eyes open. For anything holding data you can't replace, the answer should wait until scoped permissions and backups are in place.