Finishing and Hardening Project Atlas v1

Project Atlas v1 is the infrastructure server behind my home Cyber Operations Center. It started as a used Dell Latitude E7250 and evolved into a primarily headless Ubuntu Server host for core COC services.

The physical restoration is complete. The system has 16 GB of DDR3L memory, its original Samsung 256 GB M.2 2242 SATA SSD, supplemental cooling, local maintenance input and display access, a replacement battery and a replacement bottom cover. The internal hardware has also been cleaned, inspected and maintained.

Keeping the original SSD was an engineering decision

I originally evaluated a WD Blue SA510 1 TB replacement. It had the correct SATA interface, but it used the 2280 module length. Atlas has a 2242 mounting position, so the drive was physically too long and was never installed.

That mismatch was a useful reminder that “M.2” does not describe one universal form factor. Interface, keying and physical length all matter. After I could not find a suitable M.2 2242 SATA replacement, I kept the original operational Samsung SSD rather than forcing an unsafe mounting workaround.

Accepting the network boundary

The integrated Ethernet interface is not part of the working Atlas v1 configuration. I considered an external adapter, but decided it will not be added in this version. Atlas v1 intentionally remains on Wi-Fi, and the lack of wired networking is documented as an accepted limitation rather than left as an ambiguous unfinished task.

That boundary matters because Atlas v2 is already reserved for the later 2U rack replacement. Adding future-platform requirements to the laptop build would make it harder to define when v1 is actually finished.

Reconciling the repository with the real system

A system audit showed that the repository had drifted behind the running host. Atlas is currently on Ubuntu Server 24.04.4 LTS with 16 GB of memory and the retained Samsung system SSD. At the time of the audit, it had been up for 20 days.

The audit also confirmed that SSH, Docker, WireGuard, Caddy, Prometheus, Node Exporter, Grafana and Wazuh components were active. I used those facts as inventory evidence without moving detailed service configuration into the hardware repository.

The updated repository separates three different kinds of truth: facts confirmed by the live audit, physical work I have completed, and operational tests backed by sanitized evidence. That prevents “installed” from quietly becoming “fully validated” in the documentation.

A three-week trip changed the requirement

In September, I had a practical reason to push the reliability work further. I was preparing to be away from home for approximately three weeks to support a new site and train managers and team leads. While I was away, I would not be physically available to press a power button, restart Docker, recover DNS or troubleshoot a routine reboot.

That turned Atlas resilience from a nice homelab improvement into an operational requirement. Instead of adding more features immediately before leaving, I focused on making the infrastructure I already had recover by itself.

Designing for unattended recovery

The first improvement was power recovery. I enabled Dell BIOS Wake on AC and then tested it physically: Atlas was shut down, AC power was removed, AC was restored, and I deliberately did not press the power button. The system powered itself back on and returned to an administrable state.

The laptop battery also became useful infrastructure rather than just a laptop component. I used it as a short-duration built-in UPS and added a small systemd watchdog that checks AC and battery state every minute. If AC power is absent and the battery reaches 35 percent or below, Atlas performs a clean shutdown instead of running the battery completely flat.

I validated the shutdown decision logic safely at representative battery levels rather than intentionally draining the battery just to prove the threshold.

Proving the services actually come back

Configuration alone was not enough. I performed normal reboot and restored-AC recovery tests and checked the system after it came back.

SSH, Docker, networking, Tailscale, WireGuard and the power watchdog returned automatically. The production Docker containers—including PostgreSQL for Daedalus, n8n, cAdvisor, Pi-hole and Dockge—use restart policies that bring them back after the host restarts. Pi-hole specifically returned healthy after reboot.

The final validation showed the operating system in a clean running state with zero failed systemd units.

Automatic recovery does not mean automatic change

I also reviewed the update policy. Ubuntu security maintenance is allowed to run automatically, but potentially disruptive changes remain deliberate. I am not blindly auto-updating application containers, major database versions, operating-system releases, firmware or BIOS, and the server is not configured to reboot itself automatically after updates.

During cleanup I also removed an obsolete Docker hello-world test and disabled an IPMI monitoring path that could never work on this Latitude hardware. The unsupported OpenIPMI startup service had been creating a false failed-service state, so it was masked rather than leaving meaningless noise in the system.

The lesson

This was a useful reminder that reliability engineering is not about adding the most automation possible. It is about deciding what should recover automatically and what should remain under deliberate change control.

The principle I am carrying forward for Atlas and the rest of the COC is simple: recovery is automatic, security maintenance is automatic where safe, and potentially disruptive change is deliberate.

Just as importantly, the work followed a simplicity-first approach. I reused the battery already in the laptop, native BIOS behavior, systemd, Docker restart policies and remote-access tooling that was already installed. I only added a small watchdog where there was an actual gap.

What remains

The physical build is complete and the pre-travel unattended-operation milestone has passed. Remaining closeout items are narrower validation tasks such as SSD health evidence, temperature baselines, extended reliability data and a few remaining local-console and power-management checks.

Explore Project Atlas on GitHub ↗