When One Container Becomes an Environment
apple/container can run one application in one lightweight Linux VM, but it can also use the same foundation for a persistent Linux environment or a local Kubernetes cluster. This chapter explains what changes when the unit of work is no longer a short-lived process: which state becomes durable, why an init system matters, how the Mac is integrated, and how Kubernetes nodes reuse the ordinary container runtime. The result is a practical choice among an application container, a container machine, and an experimental local cluster.
The distinction is not mainly about adding more commands. It is about changing the lifecycle contract. An application container is organized around an image’s process and can be removed when that process ends. A container machine is organized around a Linux environment whose filesystem and services should survive stop and start. A Kubernetes cluster is organized around node images and an orchestration layer that schedules workloads. All three can be built on OCI images and VM-backed execution, but they ask the runtime to preserve different things.
A container machine changes the unit of work
The ordinary container run model treats an image as the package for an application. The image’s configured process starts as the workload, and the container’s useful lifetime is usually tied to that process. This is a good fit for a web server, a test command, or a build step: the reader wants a reproducible process environment, controlled resources, and a clear stop condition.
A container machine treats the image as the starting point for a Linux environment. The project’s documentation says that a machine boots the image’s init system, can register long-running services, and keeps its filesystem across stop and start. Instead of asking “what command should this image run once?”, the machine asks “what Linux system should be available when I enter it?” That is why an image containing /sbin/init or a prepared system such as systemd matters. A shell, database service, compiler, and background daemon can coexist under the environment’s process supervisor.
This change makes the feature useful for development. A repository can stay in the Mac user’s home directory while the machine mounts that home directory into Linux. The user can edit with a Mac-native editor and build or test with Linux tools against the same files. A machine can also be created for a particular distribution, allowing the developer to test an application in Alpine, Ubuntu, Debian, or another prepared environment without turning each command into a new disposable guest.
The home mount is an explicit integration with a high practical value and a high trust consequence. It avoids copying repositories and dotfiles back and forth, but it means the Linux environment can see the selected Mac directory. The machine configuration allows the home mount to be read-write, read-only, or absent. A read-only environment can be useful when Linux tools only need to inspect the repository; a read-write environment is more convenient when compilers, package managers, or build tools must write artifacts. Neither choice is a universal security setting. It defines how much of the host filesystem the persistent environment is allowed to share.
Persistence is implemented as a stored machine resource, not as a promise that every ordinary container automatically becomes durable. When a machine is created, the selected OCI image filesystem is copied into a machine bundle. The machine service records its configuration and boot settings.