The convenient library install
A project asks for one newer library. A system-wide package or a copied file changes an ABI beneath another tool. The original project works; the next update or unrelated application does not.
Why atomic
Atomic systems keep the operating system as a coherent, replaceable unit. That makes ordinary work less fragile: software choices have a boundary, updates have a known shape, and recovery does not begin with archaeology.
The protection is architectural
The base image is updated as one tested deployment rather than as a long history of package transactions. Your configuration and data persist separately. If an update is wrong, the prior deployment remains a clear path back.
What it avoids
A project asks for one newer library. A system-wide package or a copied file changes an ABI beneath another tool. The original project works; the next update or unrelated application does not.
A third-party repository solves an immediate need, then quietly owns dependency decisions for the whole machine. Months later, a routine upgrade becomes a puzzle of pins and held packages.
A service needs a runtime, a container engine, or a build stack. Installing it directly makes the host responsible for every library, daemon, and configuration that arrives alongside it.
Practical exits, not dead ends
Immutable does not mean unable to install software. It means selecting the smallest boundary that fits the job.
Personal, local tooling
Use Homebrew for command-line tools and applications that belong to your own working environment. It keeps that choice in user-space rather than rewriting the image.
A capability close to the host
Use a Frostyard sysext when the tool needs to integrate with the operating system: development tools, VPNs, editors, Docker, Podman, or Incus.
Development userspaces
Use containers when a project needs its own distribution, language toolchain, or library set. The project gets its environment; the host stays legible.
Application workloads
Use Docker when an application already ships as a container workflow. The Docker extension adds that runtime without making it part of the base image.
System containers and VMs
Use Incus when the workload needs a fuller machine boundary: long-lived system containers, virtual machines, or a test environment with its own operating system.
A more useful default
Frostyard images offer a durable operating system below your work, with sysexts for system capability and Brew, containers, and VMs for everything that should stay independent. Dependencies can grow without becoming permanent sediment.