Show HN: Local-First Linux MicroVMs for macOS

(shuru.run)

88 points | by harshdoesdev 5 hours ago ago

29 comments

  • Xlab an hour ago

    I will steal this to make a local-first version of https://microterm.dev for macOS :)

    My idea is to have unified environment across all targets, so the only thing that changes is speed and amount of RAM.

  • runako 23 minutes ago

    How does this compare to Apple container[1]?

    I am excited by the innovation happening in the space!

    1 - https://github.com/apple/container

    • harshdoesdev 19 minutes ago

      apple container is more of a docker-style workflow, OCI images, registries, etc. shuru is just micro VMs with checkpointing, much simpler scope.

  • BrandiATMuhkuh 24 minutes ago

    Very cool. Was looking for something like this for a new project of mine. (I'm working on a project that is like a marriage of retool+OpenClaw. It's used by SME to quickly build inhouse apps)

  • praveenhm 12 minutes ago

    How does it compare to Lume. It uses Apple's native Virtualization Framework to run macOS and Linux VMs at near-native speed on Apple Silicon.

    • harshdoesdev 6 minutes ago

      lume is a much more full featured VM manager, macOS and Linux VMs, API server, prebuilt images, python SDK etc. shuru is intentionally minimal.

  • josephg 3 hours ago

    What does local first mean in this context? Does it just mean local? Like, the software runs locally?

    • harshdoesdev 3 hours ago

      yeah, it just means everything runs on your machine. there are services like E2B, sprites.dev and others that give you sandboxes in the cloud. shuru runs VMs locally using Apple's Virtualization.framework, so nothing leaves your Mac.

    • userbinator an hour ago

      Unfortunately yes. It's just another stupid marketing buzzword these days.

      • Xlab an hour ago

        it's the other way around, everything is in the cloud now (upload your files to us, we are privacy respecting, bla bla)

        So it's good that the product actually highlights it is dealing with local hardware only.

  • 7777777phil 3 hours ago

    The agent stack is splitting into specialized layers and sandboxing is clearly becoming its own thing. Shuru, E2B, Modal, Firecracker wrappers.

    Earlier this month I wrote about how these layers have very different defensibility profiles and why going monolithic is the wrong call: https://philippdubach.com/posts/dont-go-monolithic-the-agent...

    EDIT: Spelling

  • rishabhaiover 2 hours ago

    I've noticed claude forks parallel agents on an assigned task. How would they communicate in isolated sandboxes like these? Would it be cleaner and more effective for a harness to orchestrate swarms of agents in a single clean linux environment like OrbStack?

    • harshdoesdev 2 hours ago

      haven't thought about multi-agent communication yet. each sandbox is fully isolated which is the point. checkpoints help a bit here though, you can branch multiple agents from the same checkpoint so they all start from the same state.

      • rishabhaiover 2 hours ago

        I think I made a cursory and incorrect assumption. Given this is backed by Apple's Virtualization, it has POSIX compliance and forks/execs are allowed within the sandbox which can support agent parallelization within a sandbox I believe.

        Looks like a great project at surface!

  • xrd 3 hours ago

    What is the benefit of this over lima, for example?

    • harshdoesdev 3 hours ago

      Lima can do a lot of what shuru does if you set it up for it. the difference is mostly in defaults and how much you have to configure upfront. with shuru you get ephemeral VMs, no networking, and a clean rootfs on every run without touching a config file. shuru run and you're in. Checkpoints and branching are built into the CLI rather than being an experimental feature you have to figure out. Lima is a much bigger and more mature project though. Shuru is something I am building partly to learn and partly because I wanted something with saner defaults for this specific use case.

      • enneff 2 hours ago

        Thanks for doing this. I had basically the same experience with Lima. It is very nice but the defaults are not what I want, and I don't like having to wonder whether I turned off the stuff that I don't want enabled. Better that everything is disabled by default and I selectively turn things on (like networking) as I need them.

        I'm gonna give shuru a try. My main concern is being based on Alpine (seemingly the only option?) I may not be able to easily pull in the dependencies for the projects I'm working on, but I'll see how it goes.

        • harshdoesdev 2 hours ago

          glad to hear it, that's exactly the thinking behind it. alpine is the only option right now yeah. what kind of dependencies are you running into issues with? would help me figure out what to prioritize next.

          • halostatue 14 minutes ago

            Disclaimer: I haven't tried this yet.

            I would want the equivalent of the trixie-slim Docker image (Debian 13, no documentation). It's ~46 Mb instead of ~4Mb as a Docker image, but gives a reasonably familiar interface.

            (This is largely based on some odd experiences with Elixir on Alpine, which is where I am doing most of my work these days.)

          • enneff an hour ago

            I haven't yet - just generally I have found it a bit of a hassle to figure out which packages to install whenever I use a different distro. I'll let you know how it goes!

  • tobyhinloopen 2 hours ago

    Neat! I was looking for something like this

  • Krisso 3 hours ago

    Why was using straigt containers not enough?

    • harshdoesdev 3 hours ago

      containers work fine for a lot of this. shuru is just what felt more natural to me. less config overhead and i wanted to learn by building it.

  • conradev 3 hours ago

    Use OrbStack. It’s faster than Virtualization.framework because it has its own hypervisor.

    • noname120 3 hours ago

      Not true, OrbStack uses Virtualization.framework: https://news.ycombinator.com/item?id=36189550

    • JoshTriplett 2 hours ago

      OrbStack has some invasive elements inside it trying to provide filesystem integration, and the filesystem they use is not POSIX compliant and causes breakage with some build systems and other software.

    • harshdoesdev 3 hours ago

      OrbStack is great but it is solving a different problem. it's a full Docker Desktop replacement. shuru is just a thin layer over Virtualization.framework for spinning up throwaway sandboxes.