I Just Needed Linux Here: Introducing avar v0.1.0

Sometimes I am working in a macOS project and need one Linux-specific thing. It might be a package that behaves differently on Linux, a test suite that needs to match CI more closely, or a shell tool whose cleanest installation path assumes a Linux system.

The task in my head is simple: I need Linux here, around the directory I am already standing in.

Existing approaches often ask me to switch mental models. I may need Docker commands, images, bind mounts, and flags; Dev Container configuration committed to the repository; a named VM with manual file and port setup; or a remote machine that pulls me away from the local editing loop. These are sound tools. Containers and Dev Containers are valuable when a team needs an exact environment described in code. Managed VMs offer deep control, and remote machines serve work that needs resources or access beyond a laptop.

But many ordinary development tasks do not begin with, “I need to operate infrastructure.” They begin with, “I need Linux in this project.” Therein was the friction I wanted to remove.

The avar mental model

Today I am releasing avar v0.1.0. It is an open-source macOS CLI, and the command is called avr.

Its mental model is simply:

current directory + selected operating environment

From a project on my Mac, I can run:

cd my-project
avr

That opens an interactive Linux shell in the current directory. If I only need to run one command, I can do this instead:

avr npm test

The command runs in Linux and exits with the command’s status. I do not need to name a virtual machine, configure a mount, or create a per-project file first.

avar orchestrates the whole experience. It chooses and tracks the environment, shares the current directory, applies useful defaults, and owns the lifecycle. For its macOS backend, it integrates with Lima, which handles the lower-level virtualisation, file sharing, and port forwarding. Lima is an implementation detail beneath the workflow, not the product model a developer must learn.

This is still a real virtual machine, so it uses CPU, memory, and disk. Yea, I would not call it weightless. But the default native-architecture environment uses Apple’s built-in Virtualization framework and VirtioFS file sharing. It does not ask me to install and manually size a separate hypervisor such as VirtualBox. avar selects the native architecture, starts with Ubuntu, and chooses bounded CPU and memory defaults from the Mac it is running on. I can change the distribution or architecture when the work requires it, but I do not have to design a virtual machine before I can run a Linux command.

What persists, and what stays local

The distinction between the Mac and the Linux environment matters.

My project files remain the same files on the Mac. When I edit a file in my usual editor, Linux sees the change. When a Linux command updates a project file, the change appears on the Mac. avar is not copying the repository into a separate workspace and asking me to reconcile two versions later.

The Linux environment itself is persistent. If I install ripgrep, a compiler, or system libraries inside it, those packages remain available in later sessions. Stopping the environment releases its active resources, but it does not erase what I installed.

Ports follow the same practical model. If a development server listens inside the guest, avar makes it reachable on localhost from macOS.

I can also change the environment I select. avar supports Ubuntu, Debian, and Fedora, along with arm64 and amd64 architectures. Projects use a shared environment by default for convenience. When one project needs dependencies that should not mingle with another, I can turn on project isolation and give it a dedicated environment.

The parts I wanted to make ordinary

A repository needs no initial avar configuration. My terminal begins in the project, my editor keeps working with the local files, and the Linux process comes to that context. That is the whole matter.

The lifecycle is explicit. avr status shows the environments avar manages, including their state and forwarded ports. avr stop releases resources without erasing installed packages. avr reset recreates an environment from a clean operating system, and avr destroy removes it. In both cases, the project files on the Mac are left alone.

There is also avr code, which opens the project in VS Code through Remote-SSH. Remote-SSH means VS Code keeps its interface on the Mac while its terminal, extensions, and language tooling run in the Linux environment. For work that benefits from deeper guest integration, it is there.

Installation is one command:

brew install --cask olamide226/tap/avar

The Homebrew cask installs Lima as a dependency.

Where avar is not the answer

avar v0.1.0 is macOS-only. Windows support is in the pipeline, because I will be using avar on a Windows machine too. The direction is to integrate with WSL 2 while preserving the same directory-centred experience, without making people copy projects into WSL or hand-manage the machinery around it. That work is not in this release, and I am making no date promise for it.

avar is also not a hostile-code security boundary. The project directory is shared into the Linux environment and remains writable, so code running there should be treated as code with access to those files.

The first provision is slower than later uses because avar must download an operating-system image and create the environment. Persistence helps thereafter, but it does not make that first creation disappear.

avar does not replace reproducible team build definitions. If every developer and CI job needs an exact environment declared in source control, a Dev Container, Nix definition, CI image, or container may be the right answer. avar optimises for entering Linux from the directory already beneath my feet, not for describing an identical build environment for every machine.

Snapshots have a present limitation too. Lima snapshots work with QEMU-emulated environments, not the native Apple Virtualization path avar uses for an Apple Silicon environment. In practice, a native Apple Silicon environment cannot use Lima snapshots, while an emulated amd64 environment can. avr reset remains available across both paths.

Sharing deserves an honest choice. One persistent environment across projects is convenient and saves repeated setup, but packages installed for one project can affect another. When projects need conflicting system dependencies, project isolation is the wiser option.

Finally, direct release downloads are currently unsigned and unnotarised. macOS Gatekeeper will stop those binaries until the quarantine attribute is cleared. The Homebrew cask handles that step and installs Lima, which is why Homebrew is the recommended installation route.

v0.1.0 is available

avar v0.1.0 is available now under the Apache 2.0 licence:

brew install --cask olamide226/tap/avar

The source, documentation, and issue tracker are on GitHub.

If you develop on macOS and regularly need Linux tooling while staying in your normal project directory, I would value your feedback. Tell me where the mental model holds, where it bends, and where it breaks. For a v0.1.0, that truth is more useful than applause.