Not sure if this an intentional change or not. When upgrading to OrbStack 2.0.1 I've found that the virtual machines local IP addresses all change to new ones. I haven't seen this behaviour in the past. Figured I would share that here as others may run into the problem or in case it is a bug?

that's intentional

Good to know, thanks for confirming 👍

I noticed that whenever OrbStack is opened (regardless of whether the VMs are running), opening VS Code causes high power usage (electron-nodejs (bundle.js)), and all my VS Code extensions stop working. But when I run orb stop, the issue goes away. Why does this happen?

Is there a roadmap for OrbStack which outlines the kinds of features we could expect in the future?

some quirk in golang causes dns to default to ipv6, at least in the digital ocean cli tool (doctl). thankfully grok knows how to make ipv6 work in orb VMs 😉 Something about RA and then I had to edit resolve and add an ipv6 dns nameserver. All good now and VM can do ipv6

not anymore

Why though?

As a customer, I was interested in knowing what are the plans for OrbStack in the future so I was hoping for something like a roadmap

Here's a fun one: https://www.cve.org/CVERecord?id=CVE-2025-9074

Are people depending on Docker for isolation though, especially on local development environments?

Should people be? Extremely valid question. Are they? Absolutely I see it all over the place.

Hi. Need some help on enabling word/text wrapping in logs? I saw that this feature has been introduced in version 1.20, a similar (or same) issue was raised on github

Are Docker volumes stored on the shared filesystem with OrbStack? I'm trying to understand where I should put things like mysql database data directory. Should I place it on the shared VirtioFS filesystem or a Docker volume (which, I assume, runs on the guest filesystem)? Everything seems to be working either way but I'm not sure if OrbStack was designed for storing databases on the shared FS

Is it expected that OrbStack can lead to kernel_task writing more data to disk? I'm running OrbStack 2.0.1 on macOS 15.6 with ~15 concurrent containers. After about 6-8 hours of uptime, OrbStack Helper sits at approx. 20 GB written to disk, whereas kernel_task reaches into 80 GB or more. My Mac is not using swap, memory pressure is green and the CPU die temperatures are very low (40-50 C).

For a comparison, using Lima doesn't produce so much IO in kernel_task. In my use case, the most writes come from a mysql container and in both Lima and OrbStack I'm using the same database setup. With OrbStack, I'm noticing almost twice as much writes to disk.

In both setups, I'm storing the database data in a Docker volume.

@Danny When I moved my mysql databases from a Docker volume back to a VirtioFS bind mount, I noticed that my disk IO dropped back to normal levels; I'm seeing about three times less disk writes per second. Writes out/sec in Activity Monitor is also 2-3 times lower when mysql data sits on the shared filesystem. Is this normal?

I have a feeling that mysql is fsync heavy and this produces different results in the filesystem which is used by Docker volumes

Debugging with fs_usage shows that there are many write operations performed to OrbStack's sparse data file (data.img) when I use Docker volumes. Bind mounting mysql data does not produce nearly as much I/O. Do sparse data files come with a cost of higher I/O? Does this sparse data file write activity represent actual physical writes to the disk?

...I should take my words back https://cdn.discordapp.com/attachments/1106380156030959648/1413131716410740767/2025-09-04_19.55.40.png?ex=68bad0f7&is=68b97f77&hm=fe63c0c0f6be6745b26ae08708f36a22dd2749dc714d98ee0f2ff26f3159c941&

is there any way to preemptively disable IPv6 for OrbStack Machines (Linux guests)? my employer has done some new meddling that nukes TLS over IPv6, and it prevents me from adding new Machines if they have a distro where IPv6 is enabled by default (e.g., NixOS, openSUSE Tumbleweed)

I was able to fix it inside my existing guest by disabling IPv6, but I can't add new ones, it seems

no

you can try doing it with cloud-init

never checked but it's possible. i wouldn't worry about SSD wear being a problem in the lifetime of these machines

Nevertheless, such a difference in writes is concerning. If you also run other write-heavy programs, you might end up writing hundreds of GB per day

NixOS guests don''t support cloud-init, and I'm currently unable to create a new NixOS guest on my work computer due to this issue

I was (maybe unfairly) surprised that configuring my host machine's network connection so that IPv6 was link-local only (it seems actually disabling it is not so easy?) didn't impact OrbStack's behavior maybe that would be a reasonable way to address pathological behavior like that of this TLS decrypting proxy my work imposes (and maybe has misconfigured?) without adding another toggle to OrbStack

hello