PROJECT ATLAS · AUGUST 2026
Finishing the Physical Build of Project Atlas v1
How an older Dell Latitude became the Ubuntu Server backbone for my home Cyber Operations Center—and why finishing the documentation mattered as much as finishing the hardware.
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 now 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 a 6.8.0-137-generic kernel, 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 now separates three different kinds of truth: facts confirmed by the live audit, physical work I have completed, and operational tests that still require sanitized evidence. That prevents “installed” from quietly becoming “fully validated” in the documentation.
What remains
The physical build, cleaning and maintenance are complete. The remaining closeout work is operational validation: current SSD health, temperatures under load, Wi-Fi continuity, local-console operation, server-duty power behavior and extended reliability evidence.
The largest lesson from this phase was that a project boundary is a technical control. Keeping the original compatible SSD, accepting Wi-Fi for v1 and leaving the rack replacement to Atlas v2 made the current platform clearer, safer and easier to document honestly.
← Back to the engineering journal