Case study / Developer environments
Make the setup repeatable.
Give engineers their time back.
At Volt, I built Ansible automation that reduced technical setup from approximately one week to approximately 20 minutes. It worked well, was used repeatedly, and remained in use throughout my time there.
01 / The repeated problem
One setup problem.
Two engineers interrupted.
Volt’s polyglot system required compatible language tooling, PostgreSQL, Redis, Docker, AWS tooling, and dependencies. Getting a workstation ready could take approximately a week.
When something failed, the next step was often another developer: “How did you get this working?” or “What does node --version give you?” The problem consumed two people’s attention, and the answer could remain in that conversation for the next engineer to rediscover.
Older utility repositories made the dependency on individual machines especially visible. An ad-hoc customer request could end up with whichever developer still had the project working locally. Tribal knowledge had become part of the engineering system.
02 / What I built
Put the setup knowledge into automation.
I used Ansible to configure developer workstations. Starting with a new Mac and a small number of initial preferences, a developer could run the setup instead of reconstructing the environment manually.
Getting the tools installed was only the beginning. Toolchain versions and architecture compatibility had to line up before application setup could work.
- Prepare the runtime and database. Configure toolchains, initialize PostgreSQL, create the required users, and build and enable the PLV8 extension.
- Prepare the applications. Check out repositories, install application dependencies, and run application setup.
- Make the environment usable. Restore development data and configure and start the supporting PostgreSQL, Redis, and nginx services.
Conceptual setup flow
- New Mac and initial preferences
- Run the Ansible setup
- Technically configured development environment
03 / Observed result
~1 week → ~20 minutes
Technical setup only. GitHub, AWS, and other account or permission provisioning excluded.
An automation project that kept working.
This was observed repeatedly across the team’s similar MacBooks, rather than being an exceptional best case. The implementation remained in use throughout my time at Volt.
It was one of my most successful projects. The useful result was straightforward: engineers no longer had to perform the same manual technical setup before they could work on the system.
04 / Maintenance & lessons
Successful automation still needs care.
As this particular Ansible implementation grew, I encountered complexity around procedural configuration and idempotency: making changes reliable across existing machine states and repeated runs took care. That maintenance challenge existed alongside an implementation that worked very well in practice.
I also wanted consistency without controlling irrelevant choices. Runtime versions and dependencies mattered to the system. Whether a developer preferred Vim or Emacs did not. The platform should own what must be consistent and preserve autonomy elsewhere.
05 / Beyond workstation setup
The workstation and the project are different scopes.
I used nix-darwin and Home Manager for my personal workstation configuration at Volt and loved it. Separately, I built Nix project environments in the monorepo that the whole engineering team used.
That work addressed moving between projects, loading configuration, running services, and producing Linux builds. The repeatedly observed setup timing here belongs to the Ansible workstation automation.