In custom development, there is a task that rarely appears in estimates yet reliably consumes time: setting up the development environment. A new team member's first day ends just wrestling with Node version mismatches or library build errors. A project handed over from a client "doesn't run even when following the README." Right before release, someone discovers that "it worked on my PC, but crashed in production." All of these are invisible costs born from the subtle differences across each developer's personal machine.
The foundation for fundamentally eliminating this environmental divergence took a major leap forward in 2026. Microsoft announced "WSL containers" to run Linux containers on Windows at Build 2026, Apple released "Container machine" 1.0 integrating Linux containers into macOS at WWDC26, and Canonical launched "Workshop" to build sandboxed development environments with a single command. In other words, we have entered an era where whether using Windows, macOS, or Linux, you can run Linux containers in an OS-native manner. Supporting teams with mixed operating systems in custom development, we see this as the ideal moment to transform environment setup from personal craftsmanship into systemic automation.
Why environment setup stumbles every time in client work
Environmental divergence is particularly severe in custom development because the people and machines involved rotate with every project. With in-house products, environments gradually align, but in client work, every project starts from disparate assumptions with new projects, new members, and client-side engineers.
The root cause of divergence lies in version differences across language runtimes, databases, and tools installed directly on individual machines. One person has Node 22, another Node 20. Someone's machine happens to have a required library already installed so it works, but it fails on a clean environment. This disparity births the mantra chanted on dev floors for decades: "works on my machine." The terror of code working locally but crashing in production is directly tied to the risks of reckless dependency management, a topic we also cover in Custom Development Environments in the Era of "npm install is Arbitrary Code Execution" (GH Media).
What native OS container integration means in 2026
Historically, Docker made it possible to unify environments using containers. However, especially on Windows and macOS, running through a virtual machine added overhead and configuration was reasonably complex, making teams hesitant to mandate it for everyone. The industry moves in 2026 are significant because they brought this capability much closer to standard OS features.
| Environment | Movements in 2026 | Implications for custom development |
|---|---|---|
| Windows | Native container operations via WSL containers | Easy to standardize even in Windows-centric client environments |
| macOS | OS integration via Container machine 1.0 | Runs smoothly in teams with many Mac engineers |
| Ubuntu | Single-command isolated environments via Workshop | Standardization for servers and AI agent workloads |
With operating systems adopting containers in a near-standard manner, the friction of using containers itself has dropped. Distributing the exact same environment through identical steps to team members on any OS—this benefit is all the greater in client development environments where diverse PCs intermingle.
Turning development environments into a single command
The goal state is simple: clone the repository, run a single established command, and the identical development environment spins up on anyone's PC. Language versions, databases, and required tools are written as code in container definitions (Dockerfile or devcontainer configurations) and included in the repository.
# 例: リポジトリを取得して環境を起動するだけ
git clone <repo>
cd <repo>
docker compose up # DB やキャッシュも含めて一括で立ち上がる
# 以降は全員がまったく同じバージョン・同じ構成で開発するThe core is to manage the environment definition itself as code and eliminate manual intervention by individuals. When given a manual saying "install by hand as described here," someone will inevitably make a mistake. If it is code rather than documentation, mistakes cannot happen. This is the development environment version of managing production infrastructure via configuration files (IaC), sharing principles with Client Adoption of IaC Standardization and Migration (GH Media). For concerns about containers slowing down CI builds, we also consider countermeasures such as Client Implementation of Docker Build Acceleration (GH Media).
How we standardize this in client work
In our custom development, rather than adopting this mechanism simply "because it's convenient," we design it to deliver impact across three key phases: handover, onboarding, and delivery.
During handovers, we first containerize existing projects received from clients, locking down a single "working environment." This alone dramatically reduces the initial handover loss of "it doesn't work, cause unknown." For onboarding, we prepare a state where new members can start development on their first day with a single command, shrinking days spent on setup close to zero. In one on-site client development support project where two to three days were lost to setup every time team members rotated, organizing container definitions shortened that to virtually the same day.
And finally, delivery. We never deliver code in a state where "it only runs on our company's specific machines." If delivered alongside environment definitions, the identical environment can be reproduced even if client personnel change or maintenance moves to another company. This serves as quality assurance for custom development while reflecting the integrity of not locking clients into a specific vendor. For perspectives on establishing whole-team engineering foundations, How to Proceed with Platform Engineering Adoption (GH Media) is also a helpful reference.
Common pitfalls to avoid
First, thinking you containerized while leaving parts dependent on local machines. If steps for retrieving environment variables or credentials remain manual, "it doesn't work" will inevitably recur. Second, creating bloated containers that slow down startup. If the developer experience is poor, nobody will use it, so keep images lean and prioritize fast startup and build times from the beginning. Third, ignoring differences between operating systems. Because file handling and performance characteristics differ across WSL, macOS, and Linux, verification tailored to the OSs used across your team is essential.
Summary — Moving environments from people to code
"Works on my machine" is not individual carelessness; it is a systemic flaw that leaves environments to manual labor. With Windows, macOS, and Linux all embracing containers in 2026, the barrier to distributing development environments as code and reproducing identical states on anyone's PC has clearly dropped. In custom development, integrating this foundation into handovers, onboarding, and delivery allows us to decouple the invisible cost of environment setup from billable project hours.
If you are experiencing issues where onboarding takes too long or handed-over projects fail to run, please feel free to reach out via our contact form. We can start by containerizing your existing projects.
Sources
- Announcement of "WSL containers" for Creating and Running Linux Containers on Windows (Publickey)
- Apple Releases "Container machine" 1.0 Integrating Linux Containers into macOS (Publickey)
- Ubuntu Introduces "Workshop," a New Feature to Build Dev Environments with a Single Command (Publickey)
- Custom Development Environments in the Era of "npm install is Arbitrary Code Execution" (GH Media)
- Client Adoption of IaC Standardization and Migration (GH Media)
- Client Implementation of Docker Build Acceleration (GH Media)
- How to Proceed with Platform Engineering Adoption (GH Media)
