Skip to content

Instantly share code, notes, and snippets.

@vishalsachdev

vishalsachdev/2026-01-11-multipass-agentic-flywheel.md

Created January 11, 2026 22:08
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save vishalsachdev/c737ce1a0951f98951d2915fa432dee7 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save vishalsachdev/c737ce1a0951f98951d2915fa432dee7 to your computer and use it in GitHub Desktop.
Download ZIP
Multipass on macOS: My Agentic Flywheel Ubuntu VM Setup
Raw
2026-01-11-multipass-agentic-flywheel.md
title date publication notes
Multipass on macOS: My Agentic Flywheel Ubuntu VM Setup
2026-01-11
The Hybrid Builder
AI-written; collaboration recap

Multipass on macOS: My Agentic Flywheel Ubuntu VM Setup

I didn’t start last night by saying “I need a VM.”

I started by saying: I want to try the Agentic Coding Flywheel Setup (ACFS)—but instead of renting a VPS, I wanted to repurpose a machine I already own: an M2 Max Mac with 94GB of memory.

That’s a slightly perverse choice, because ACFS is designed to take a fresh Ubuntu VPS and turn it into a professional agentic dev environment. A Mac is not that. But as a hybrid builder, “not ideal” is often the most interesting place to run an experiment.

So the goal became: replicate the flywheel experience locally, on real hardware I control, and see what breaks.

This article documents what I ended up standardizing on:

  • Multipass as the Linux substrate: an Ubuntu VM on macOS (my VM is named agentic, running Ubuntu 24.04 LTS).
  • ACFS as the flywheel: the installer-driven stack I wanted to evaluate.

It’s explicitly AI-written, and it’s also explicitly a collaboration story: I’m steering the goals and constraints, and my assistant is helping me extract signal from chaos and turn it into a reproducible build.

Along the way, I kept bumping into a familiar pattern—what I’ve been calling a compound engineering loop: use it before you improve it, then systematize the working path. (If you want the meta framing, it’s the same loop I described in “Compound Engineering: Use It Before You Improve It”.)

My agent stack (three places)

I’m already running agents locally, and that’s part of what made this experiment possible.

Here’s what I have right now:

  • On my laptop: Claude Code, Codex CLI, Gemini CLI
  • On the M2 Max (native macOS): Claude Code, Codex CLI, Gemini CLI
  • On the M2 Max (Ubuntu via Multipass): Claude Code, Codex CLI, Gemini CLI
  • Bonus (on the M2 Max): OpenCode, for good measure

Why replicate across environments? Because different tools “want” different assumptions:

  • Some want a real Linux box.
  • Some are happiest natively on macOS.
  • Some are fine anywhere as long as the shell + runtimes are sane.

ACFS is opinionated about Ubuntu, so the Ubuntu VM became the cleanest place to run it without constantly translating platform quirks.

The problem I was actually solving

I didn’t wake up thinking “I want Multipass.”

I woke up thinking:

  • I want to try ACFS without renting infrastructure.
  • I want a Linux environment on my Mac that feels like “SSH into a server.”
  • I want to run agentic installs / bootstrap scripts repeatedly.
  • I want the environment to persist between sessions.
  • I want fewer “what daemon is running?” mysteries.

The thing I was building toward was a local “flywheel”: a setup where the environment is stable enough that each iteration builds on the last, instead of resetting my attention back to infrastructure.

Phase 1 (initial attempt): Docker Desktop + the Linux install script

The first instinct was the standard Docker route.

I tried:

  • The Linux convenience script: get.docker.com (useful on Linux, not the macOS answer)
  • Docker Desktop via Homebrew cask

That got me far enough to do quick checks like:

  • docker ps
  • docker run -it ubuntu:latest /bin/bash

…but the deeper I got, the more I was building “a Linux-ish workspace” by layering assumptions inside a container.

That’s fine when you’re deploying containers. It’s less fine when you’re trying to live in the environment for hours and evolve a toolchain.

Phase 2: Colima (Docker daemon without the Desktop)

Next I pivoted to Colima:

  • brew install colima
  • brew install docker
  • colima start

This is a legitimately good setup when your core workflow is containers. It’s CLI-first and lighter-weight than Docker Desktop.

I used it to run a long-lived container:

docker run -d --name agentic-flywheel ubuntu:latest tail -f /dev/null

Then I exec’d in and started bootstrapping:

docker exec -it agentic-flywheel bash
apt-get update
apt-get install -y git curl sudo

I even got far enough to clone and run an installer inside the container.

But I also hit the typical “container reality” friction:

  • You’re always one missing capability away from wishing it was a VM.
  • You’re always deciding whether state belongs in the container, a bind mount, or your host.
  • When something gets weird, you’re debugging contexts/configs.

This is the point where the workflow tells you what the correct abstraction is.

For me: I didn’t want a container. I wanted a box.

Phase 3 (final): Multipass Ubuntu VM named agentic

The final pivot was Multipass.

On macOS:

brew install --cask multipass

Then I ended up with a VM called agentic running Ubuntu 24.04 LTS.

You can verify the state with:

multipass list

And enter it with:

multipass shell agentic

That’s the moment it clicked.

Inside the VM, the world is boring again:

  • apt-get behaves like it should
  • paths and users behave like they should
  • scripts that were written with “Ubuntu server” assumptions stop fighting you

This setup feels like the “AI memory” work I’ve been doing elsewhere: the goal is not just to solve the immediate task, but to build a substrate that accumulates progress instead of losing it. (That theme shows up strongly in “Teaching Claude Code to Remember For You” and “The AI Memory Problem: When Your Team’s Coding Assistants Don’t Talk to Each Other”.)

The flywheel workflow (inside the VM)

The “flywheel” I was experimenting with is Agentic Coding Flywheel Setup (ACFS) by Dicklesworthstone.

ACFS’s core promise is simple: take a fresh Ubuntu machine (typically a VPS) and bootstrap it into a fully loaded agentic dev environment.

Two details I love as a builder:

  • Idempotent installer: if it’s interrupted, you re-run it and it resumes.
  • Pinning support: for reproducibility, you can pin to a tagged release or a specific commit.

Option A: Quick install (vibe mode)

Inside multipass shell agentic, you can run the same one-liner ACFS uses for VPS installs:

curl -fsSL "https://raw.githubusercontent.com/Dicklesworthstone/agentic_coding_flywheel_setup/main/install.sh?$(date +%s)" | bash -s -- --yes --mode vibe

Option B: Reproducible install (recommended once it works)

After you’ve validated the flow once, pin it:

ACFS_REF=v0.1.0 \
  curl -fsSL "https://raw.githubusercontent.com/Dicklesworthstone/agentic_coding_flywheel_setup/v0.1.0/install.sh" \
  | bash -s -- --yes --mode vibe

(Replace v0.1.0 with whatever release you want to standardize on.)

The meta-pattern here is the same thing I keep rediscovering: use the fastest path to get it working, then lock it down so your environment becomes a compounding asset.

What I learned (the non-obvious bits)

1) “Docker vs VM” is not ideological—it’s about where your state should live

If your state is:

  • images and containers → Docker-first
  • packages, users, services, dotfiles, scripts, and a durable workspace → VM-first

I was clearly in the second category.

2) The fastest path is to let the friction teach you

This wasn’t a “Multipass is better” story.

It was:

  • try Docker Desktop → notice friction
  • try Colima → notice different friction
  • choose Multipass because it matched the mental model: a real Linux environment that persists

That’s compound engineering in practice: I don’t optimize first. I run the loop until it reveals what wants to be standardized.

3) Collaboration is the multiplier

A subtle part of why this went faster is that I wasn’t doing it alone.

The assistant helped me:

  • reconstruct what I actually did (from shell history)
  • separate “final setup” from “failed experiments”
  • turn a messy night into a coherent checklist

That’s the meta-skill layer: building systems that make future work cheaper.

The checklist (what I’d tell a friend to do)

On macOS:

brew install --cask multipass
multipass list
multipass shell agentic

Inside Ubuntu:

sudo apt-get update
sudo apt-get install -y git curl
# then run ACFS installer (see above)

Day-to-day:

multipass stop agentic
multipass start agentic

What’s next (hardening this into a “real” builder workflow)

The setup is “mostly working,” which is builder-speak for “it’s good enough to use, and now the real feedback begins.”

The next upgrades I’m planning:

  • A single bootstrap script that sets up the VM the way I like it (packages, dirs, aliases)
  • A repo-local README that documents the golden path + failure modes
  • Optional: Docker inside the VM if the flywheel needs it (keeping macOS clean)

And if you’re reading this as a hybrid builder: the point isn’t Multipass.

The point is learning to treat infrastructure choices as iteration artifacts—you don’t guess the perfect stack. You run fast loops until the stack reveals itself.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment