AUTOMATION / BY BREE
One Ansible baseline across VMs, containers and Raspberry Pi
A cross-platform milestone, a Bash dependency, and a more deliberate approach to installing tools.
One of Pathfinder’s early milestones was getting the same engineering baseline working across x86 virtual machines, LXC containers and an ARM64 Raspberry Pi.
My early September 2026 captain’s log records that milestone in the common Ansible role. It also records the part that made the exercise useful: a test machine exposed a dependency between Starship and Bash.
A shared starting point
The purpose of a baseline is to give managed machines a consistent foundation before adding their workload-specific configuration.
I want familiar tools and predictable setup, with differences made explicit where the machines need them. A virtual machine, a container and a Pi are useful places to test that idea because their environments are not identical.
Getting a playbook to finish on one machine is a starting point. Running it across different targets tests more of the assumptions behind it.
The dependency that changed the approach
During development, the Starship and Bash dependency prompted a redesign of how Starship was installed. It became the first externally managed, version-pinned tool in the baseline.
That meant treating the tool as something with an explicit version and an installation path that understood the target architecture. The resulting pattern was intended to provide a starting point for later tools such as Terraform and Helm; those were future uses, not part of this milestone.
The useful result was more than having a prompt installed. I had a clearer pattern for the next tool that needed similar treatment.
The second run matters
Pathfinder’s automation standard includes proving that a second run converges cleanly. That is what I want from idempotent automation: I can apply the desired configuration again without creating a fresh set of changes simply because I reran it.
The September log describes the installation pattern as architecture-aware and idempotent. For future changes, that remains something to verify on the relevant targets, rather than assuming that an earlier success covers every new version or platform.
I also need to check the tool itself. A successful automation run and a working user environment are related, but they are not the same check.
Keep the lesson reusable
My takeaway from this milestone is to make dependencies visible, choose tool versions deliberately, and test across the environments I intend to support.
There is no need for a clever abstraction before I understand the differences. Readable tasks, clear ownership and a repeatable installation are a useful place to start.