Why atomic

Change the tool.
Not the ground beneath it.

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

A stable host is a smaller blast radius.

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

Normal systems break
in familiar ways.

01

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.

02

The one-off repository

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.

03

The urgent host fix

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

Put each dependency
at the right level.

Immutable does not mean unable to install software. It means selecting the smallest boundary that fits the job.

01

Brew

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.

02

System extension

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.

03

Podman + Distrobox

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.

04

Docker

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.

05

Incus

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

Experiment freely.
Keep the host explainable.

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.