avar

Run your current directory in Linux.
cd ~/code/my-project
avr # interactive Linux shell, same directory
avr npm test # run one command in Linux
avr --arch amd64 # the same project on x86_64
avr --distro fedora # the same project on Fedora
That is the whole mental model: the current directory plus the operating
environment you pick. No machine to name, no mounts to configure, no
devcontainer.json, no Docker flags, no SSH setup.
Inside Linux you get the same absolute path you were standing in, your files live
and writable in both directions, real passwordless sudo, packages that persist
between sessions, and any port you listen on reachable at localhost on macOS.
Install
Homebrew is the recommended route: the cask installs Lima as a dependency and
clears the quarantine attribute that would otherwise stop the first run.
brew tap olamide226/tap
brew install --cask avar
Or download the archive for your Mac from the
releases page and put avr
somewhere on your PATH.
No release is published yet. Both routes above are how v0.1.0 will be
installed, not something you can run today. Until the first release, build from
source: make build puts avr in ./bin.
Sixty seconds to a Linux shell
cd ~/code/my-project
avr
That is the whole setup. The first invocation creates the environment; there is
nothing to configure before it and nothing to clean up after it.
What to expect:
- The first run of a new environment downloads an OS image and provisions a
virtual machine. This is the slow one — minutes, mostly download — and it
happens once per distribution and architecture, not once per project.
- The first visit to a new project directory shares that directory into the
environment, which needs a one-time restart of about ten seconds. Returning to
the project later costs nothing.
- Starting a stopped environment takes roughly ten to fifteen seconds
(11.2 s and 12.7 s measured on an M-series Mac, Lima 2.2.0).
- Every invocation after that attaches to the running environment in about
400 ms, against the ~500 ms budget avar holds itself to.
Then:
avr uname -a # confirm you are in Linux
avr sudo apt install ripgrep # packages persist between sessions
avr npm run dev # ports you listen on are reachable at localhost on macOS
avr status # what exists, and what it is costing you
avr stop # give the memory back
Environments stop themselves after two hours with no live session, so forgetting
avr stop costs nothing.
Commands
avr reads a command line as avr [flags] [--] [COMMAND [ARGS...]]. Flags come
first. The first token that is not one of avar's own flags decides the rest: an
avar subcommand if it names one, otherwise the start of a command to run in
Linux — whose own flags avar never reads.
| Command |
What it does |
avr |
Interactive Linux shell in the current directory |
avr <command> [args...] |
Run one command in Linux and exit with its status |
avr -- <command> |
Force the guest reading, so avr -- status runs the guest's status rather than avar's |
avr status |
Every environment avar manages: state, resources, live sessions, forwarded ports |
avr stop |
Stop the environment for the current directory |
avr stop --all |
Stop every environment avar manages |
avr reset |
Return the current environment to a clean OS, after confirmation. Project files are never touched |
avr reset --yes |
The same, without the prompt |
avr destroy |
Remove the current environment and everything in it, after confirmation. Project files are never touched |
avr destroy --yes |
Remove the current environment without a confirmation prompt |
avr destroy --all |
Remove every environment avar manages |
avr destroy --orphaned |
Remove isolated environments whose project directory has been deleted |
avr snapshot |
List the snapshots held for the current environment |
avr snapshot <name> |
Capture a snapshot of the current environment |
avr restore <name> |
Restore the current environment to a snapshot |
avr isolate |
Report whether this project defaults to its own environment |
avr isolate on |
Give this project its own environment from now on |
avr isolate off |
Return this project to the shared environment and offer to delete its machine (--yes to delete unattended) |
avr code |
Open the current project in VS Code, running in the Linux environment over Remote-SSH |
avr version, avr help |
Also spelled --version and --help |
Use avr help <command> or avr <command> --help for the exact arguments and
flags supported by an individual management command. Help never starts, stops,
resets, snapshots, or destroys an environment.
Snapshots do not work in every environment — see Limitations.
Choosing an environment
Environment-selection flags come before the guest command or management command
they select. They affect avr, one-shot guest commands, stop, snapshot,
restore, reset, destroy (without --all or --orphaned), and code.
avr status, avr stop --all, and the global destroy scopes operate across
environments instead. avr isolate changes the current project's remembered
default rather than selecting an environment.
| Flag |
Meaning |
--arch arm64|amd64 |
Guest CPU architecture. The non-host one is emulated |
--distro ubuntu|debian|fedora[:version] |
Distribution, optionally pinned to a version. Defaults: Ubuntu 24.04, Debian 13, Fedora 43 |
--isolate |
Use an environment dedicated to this project |
--shared |
Use the environment shared by every project, just this once |
--env NAME or --env NAME=value |
Forward or set one variable in the guest. Repeatable |
--env-file PATH |
Forward a file of KEY=value lines |
--ssh-agent |
Lend the guest your SSH agent for this invocation only |
--env, --env-file, and --ssh-agent apply only to an interactive shell or
one-shot guest command. Management commands do not start a guest session, so
they do not forward environment values or an SSH agent.
Nothing crosses into the guest that you did not ask for: no host environment
beyond a small terminal allowlist, no home directory, no credentials, no agent.
~/.avr/config.toml accepts forward_env = ["AWS_PROFILE", …] for a standing
grant, and idle_timeout to change when idle environments stop themselves.
Each distinct environment gets its own machine, and projects share it unless you
ask otherwise. avr and avr --distro fedora in the same directory are two
environments over the same files.
Requirements
- macOS 13 or later, Apple Silicon or Intel.
- Lima, which the Homebrew cask installs as a dependency.
If you installed
avr some other way and Lima is missing, avar offers to
install it with Homebrew on first run and waits for you to say yes.
Nothing else: avr is a single self-contained Go binary.
How it works
avar is a thin, opinionated layer over Lima (Apache-2.0,
CNCF incubating), which supplies the virtual machines, VirtioFS file sharing, and
automatic port forwarding. avar's contribution is the mental model: it maps your
current directory and a chosen environment onto a machine, a mount, and a working
directory, so that you never have to name any of the three.
Limitations
These are real and current, not caveats about a beta.
Snapshots need an emulated environment. Lima's snapshot support is a QEMU
feature. avar runs host-native environments under Apple's Virtualization
framework (vz) deliberately, for VirtioFS speed and Rosetta, and limactl snapshot answers unimplemented there. So on an Apple Silicon Mac the everyday
environment is exactly the one that cannot be snapshotted; avr snapshot says so
rather than appearing to work. An emulated environment (avr --arch amd64) can
be snapshotted, and avr reset works everywhere.
Sixteen project directories per environment. macOS caps how many
directory-share devices one virtual machine may have. Measured against Lima
2.2.0: nineteen project mounts start, twenty do not, and the failure is a bare
"Internal Virtualization error" during boot with no way back. avar caps the set
at sixteen, leaving headroom for the Rosetta share. Past that the least recently
used project is unshared and you are told which; it stays a registered project
and comes back on the next visit, paying the same one-time restart a first visit
pays. The project you are entering is never the one dropped.
Released binaries are unsigned and unnotarised. The Homebrew cask strips the
quarantine attribute after install, so that route is unaffected. A tarball
downloaded directly from the releases page will be stopped by Gatekeeper until
you clear it yourself.
macOS is the supported platform. macOS 13+, Apple Silicon or Intel. That is
the whole list. Linux hosts, cloud and remote environments, and GUI applications
are out of scope.
Roadmap
Nothing in this section exists. Each item is specified or sketched; none of it is
implemented, and there are no dates.
- Windows hosts via WSL 2 — Requirement 18, Phase 4 of the plan. Work has
not started: there is no WSL provider in the codebase, and
avr does not run
on Windows at all. It is a design on paper behind avar's provider boundary,
nothing more.
- Post-MVP work: a Linux-native workspace mode,
.avr.toml and avr init,
avr ports and avr open, more editors, and a second backend behind the
provider interface.
Development
make build # compile ./bin/avr
make test # unit and integration tests
make lint # gofmt -s and go vet
make e2e # real-Lima end-to-end tests (needs macOS and limactl)
avar is built spec-first. The requirements, design, and phased plan live in
.kiro/specs/avar-cli/ and are the source of truth;
docs/lessons.md records the mistakes that changed how the
project is worked on. CONTRIBUTING.md explains how to
propose a change, and CLAUDE.md is the working agreement every
change is held to.
License
Apache-2.0. See LICENSE.