docs(vm-isolation): a recommendation, not a menu - #118
Conversation
Two options were on the table -- Desktop spawns a VM per service, or
document 'run Desktop itself in a VM' -- differing by roughly two orders
of magnitude in cost. The measurements point at neither.
DO NOT BUILD A VM ORCHESTRATOR. On macOS and Windows the boundary already
exists: Docker Desktop runs containers inside a Linux VM (LinuxKit under
Virtualization.framework; WSL2 on Windows), and this page already records
that Salad ships its own WSL2 distribution. On the two platforms where
anyone actually runs Desktop, every third-party binary is ALREADY in a
virtual machine. A second layer rebuilds, expensively, what the platform
gives away.
That reframes the feature. The gap is not isolation -- it is that nothing
tells the user which boundary they are behind, and the answer differs per
platform in a way nobody could guess. Linux is the one row where
containers share the user's kernel, and it is the only place a VM adds
something that is not already there.
So, in order: say which boundary is in force (internal/runtime already
distinguishes the providers, so this is a sentence on top of existing
code); document the VM path for Linux rather than automating it; and only
automate if someone asks, at which point it is Linux-only -- far smaller
than the cross-platform VM manager originally imagined.
What that avoids: per-platform hypervisor backends, guest image
lifecycle, VM networking that must preserve each service's egress IP
(providers cap per IP, CashPilot-5qc), GPU passthrough, and a UI for all
of it.
One claim is flagged as NOT measured this session -- that Docker Desktop
on macOS uses a LinuxKit VM. It is the documented architecture and
matches the measured Windows behaviour, but every other claim on this
page was verified on hardware and this one was not. Client: Docker Engine - Community
Version: 29.7.1
Context: colima
Debug Mode: false
Plugins:
scout: Docker Scout (Docker Inc.)
Version: v1.22.0
Path: /Users/sergio/.docker/cli-plugins/docker-scout
Server: on a
Mac settles it in one line.
Refs: CashPilot-Desktop-bam
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughThe research document compares service isolation across macOS, Windows, and Linux. It recommends documenting existing isolation boundaries, deferring Linux-only automation, and verifying the macOS Docker Desktop claim. ChangesVM isolation research
Estimated code review effort: 1 (Trivial) | ~3 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/vm-isolation-research.md`:
- Around line 115-118: Update the discussion of “Desktop spawns a VM per
service” and “run Desktop itself inside a VM” to remove the unsupported
two-orders-of-magnitude cost claim, or add documented resource/cost measurements
that substantiate it; preserve the conclusion that the measurements support
neither option.
- Around line 160-166: Update the Linux VM recommendation in the documented
option section to qualify the GPU-cost statement: replace the claim that it
costs nothing in GPU earnings with wording that Linux VM GPU impact is
unmeasured unless supported by Linux-specific measurements. Do not extend the
macOS Metal or Windows WSL2 results to Linux.
- Around line 125-128: Update the macOS Docker Desktop verification section and
its “not measured” footnote to state that docker info was not run on Mac
hardware, and require selecting or validating the local Docker Desktop context
with docker context show before checking docker info --format '{{.OSType}}'.
Ensure the Linux OSTType conclusion is only based on the local context, not a
remote Linux context.
- Around line 130-133: Revise the VM-boundary claims in the referenced
discussion, including lines 152–158, to apply only to Docker-backed container
workloads rather than every earning binary. Preserve the per-provider dashboard
statement, and explicitly represent mixed or unknown runtime boundaries when
services use different or unsupported execution modes, including native
Mysterium and hybrid deployments.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 4f53563f-292b-40fc-8fd1-b1b0fa1423c3
📒 Files selected for processing (1)
docs/vm-isolation-research.md
| Docker Desktop does not run containers on the host. It runs them inside a Linux | ||
| VM: a LinuxKit guest under Virtualization.framework on macOS, and a WSL2 guest on | ||
| Windows. The section above already records the Windows half of this, and notes | ||
| that Salad ships its own WSL2 distribution. |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
docker context show
docker info --format 'OSType={{.OSType}} KernelVersion={{.KernelVersion}}'Repository: GeiserX/CashPilot-Desktop
Length of output: 247
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== repo files matching vm-isolation-research.md =="
git ls-files | rg '(^|/)vm-isolation-research\.md$' || true
file="$(git ls-files | rg '(^|/)vm-isolation-research\.md$' | head -n 1 || true)"
if [ -n "${file:-}" ]; then
echo "== file: $file =="
wc -l "$file"
echo "== lines 110-135 =="
sed -n '110,135p' "$file" | nl -ba -v110
echo "== lines 170-195 =="
sed -n '170,195p' "$file" | nl -ba -v170
fi
echo "== broader docker context/command references =="
rg -n "docker (context|info)|OSType|KernelVersion|LinuxKit|Docker Desktop" . -g '!*node_modules*' -g '!*dist*' -g '!*build*' || trueRepository: GeiserX/CashPilot-Desktop
Length of output: 381
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== relevant doc sections =="
awk 'NR>=110 && NR<=190 { printf "%5d %s\n", NR, $0 }' docs/vm-isolation-research.md
echo
echo "== broader docker command/context references =="
rg -n "docker (context|info)|OSType|KernelVersion|LinuxKit|Docker Desktop|LinuxKit" docs/vm-isolation-research.md || trueRepository: GeiserX/CashPilot-Desktop
Length of output: 5230
🌐 Web query:
Docker context shows current context docker context show docker info current context OSType
💡 Result:
To manage and inspect your current Docker environment, you can use several commands depending on the specific information you need [1][2][3]. Current Docker Context The primary command to display the name of your currently active Docker context is: docker context show [1] If you encounter an error or if this command is unavailable in your version of the Docker CLI, you can alternatively use: docker version --format='{{.Client.Context}}' [4][5] To see all available contexts and identify which one is currently in use (indicated by an asterisk *), use: docker context ls [6] OSType and System Information The OSType of the Docker daemon (the environment where the engine is running) is included in the output of the docker info command [3][7]. You can retrieve this specifically using: docker info --format '{{.OSType}}' The docker info command provides comprehensive system-wide information, including the Operating System, OSType, architecture, and the current context [3][7]. Note that the OSType refers to the engine's host OS, while your client's OS/Arch can be found in the output of docker version [3][8]. Summary of Commands: - Show current context name: docker context show [1] - List all contexts: docker context ls [6] - Show system information (including OSType): docker info [3] - Extract OSType only: docker info --format '{{.OSType}}' [3]
Citations:
- 1: https://docs.docker.com/reference/cli/docker/context/show/
- 2: https://docs.docker.com/reference/cli/docker/context/
- 3: https://docs.docker.com/reference/cli/docker/system/info/
- 4: Add "context" to "docker version" and "docker info" docker/cli#2500
- 5: Command: docker context show does not exist for Linux client docker/cli#3425
- 6: https://docs.docker.com/reference/cli/docker/context/ls/
- 7: https://fossies.org/linux/docker-cli/docs/reference/commandline/system_info.md
- 8: https://docs.docker.com/reference/cli/docker/version/
Make the macOS Docker Desktop verification check the local daemon.
The docs rely on the LinuxKit premise, but the caveat says docker info was not executed on Mac hardware. Add it to the “not measured” footnote, and require docker context show/docker info --format '{{.OSType}}' for the local Docker Desktop context before using the Linux OSType result. A remote Linux context also makes that docker info check insufficient.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/vm-isolation-research.md` around lines 125 - 128, Update the macOS
Docker Desktop verification section and its “not measured” footnote to state
that docker info was not run on Mac hardware, and require selecting or
validating the local Docker Desktop context with docker context show before
checking docker info --format '{{.OSType}}'. Ensure the Linux OSTType conclusion
is only based on the local context, not a remote Linux context.
| So on the two platforms where anyone actually runs CashPilot Desktop, **every | ||
| third-party earning binary is already inside a virtual machine.** A second VM | ||
| layer would be rebuilding, at considerable cost, a boundary the platform hands | ||
| you for free. |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
fd -t f -E .git | while IFS= read -r file; do
rg -n -C 4 \
'internal/runtime|native-process|docker-desktop-macos|docker-desktop-windows|colima|lima|salad' \
"$file" || true
doneRepository: GeiserX/CashPilot-Desktop
Length of output: 29967
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '--- docs/vm-isolation-research.md relevant sections ---\n'
nl -ba docs/vm-isolation-research.md | sed -n '60,85p;110,170p'
printf '\n--- docs/BRANCH-2-RUNTIME.md native/runtime section ---\n'
nl -ba docs/BRANCH-2-RUNTIME.md | sed -n '1,90p;36,72p;125,147p;130,158p'
printf '\n--- runtime catalog/provider declarations mentioning native ---\n'
rg -n 'NativeConfig|native:|NativeProcess|native-process|Image|image|docker:' internal/docs services -S || true
printf '\n--- files likely containing runtime/provider/service YAML images/natives ---\n'
fd -t f . services internal | sed -n '1,120p'Repository: GeiserX/CashPilot-Desktop
Length of output: 254
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '%s\n' '--- docs/vm-isolation-research.md relevant sections ---'
nl -ba docs/vm-isolation-research.md | sed -n '60,85p;110,170p'
printf '%s\n' ''
printf '%s\n' '--- docs/BRANCH-2-RUNTIME.md native/runtime section ---'
nl -ba docs/BRANCH-2-RUNTIME.md | sed -n '1,90p;36,72p;125,147p;188,202p'
printf '%s\n' ''
printf '%s\n' '--- source runtime/service declarations mentioning native and image fields ---'
rg -n -C 3 'NativeConfig|native:|NativeProcess|native-process|Image:|Image=|image:|docker:' internal services docs || true
printf '%s\n' ''
printf '%s\n' '--- service YAML files with native and/or image/docker fields ---'
for f in $(fd -t f '\.ya?ml$' services | sort); do
if rg -q -e '^(name|slug|native:|docker:|image:|command:|Image:)' "$f"; then
printf '%s\n' "## $f"
nl -ba "$f" | sed -n '1,100p;1,80p'
fi
doneRepository: GeiserX/CashPilot-Desktop
Length of output: 259
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo '--- docs/vm-isolation-research.md relevant sections ---'
awk 'NR>=60 && NR<=85 {printf "%5d:%s\n", NR, $0} NR>=110 && NR<=170 {printf "%5d:%s\n", NR, $0}' docs/vm-isolation-research.md
echo ''
echo '--- docs/BRANCH-2-RUNTIME.md native/runtime section ---'
awk 'NR>=1 && NR<=90 {printf "%5d:%s\n", NR, $0} NR>=36 && NR<=72 {printf "%5d:%s\n", NR, $0} NR>=125 && NR<=147 {printf "%5d:%s\n", NR, $0} NR>=188 && NR<=202 {printf "%5d:%s\n", NR, $0}' docs/BRANCH-2-RUNTIME.md
echo ''
echo '--- source runtime/service declarations mentioning native and image fields ---'
rg -n -C 3 'NativeConfig|native:|NativeProcess|native-process|Image:|Image=|image:|docker:' internal services docs || true
echo ''
echo '--- service YAML files with native and/or image/docker fields ---'
python3 <<'PY'
import os
import re
from pathlib import Path
for root, dirs, files in os.walk('services'):
for f in files:
if not f.endswith(('.yml', '.yaml')):
continue
path = os.path.join(root, f)
text = Path(path).read_text()
if re.search(r'^(name|slug|native:|docker:|image:|command:|Image:)', text, re.M):
print(f'## {path}')
for i, line in enumerate(text.splitlines(), 1):
if i <= 100 or i <= 80:
print(f'{i:5d}:{line}')
PYRepository: GeiserX/CashPilot-Desktop
Length of output: 50384
Scope the VM boundary claim to Docker-backed services.
docs/BRANCH-2-RUNTIME.md makes native process support explicit for Mysterium and the hybrid path. Line [130] then says every earning binary is inside a VM, even when users run native-only mixed deployments. Limit this text to Docker-backed container workloads, keep the dashboard sentence per provider, and show mixed/unknown when services run under different runtime boundaries.
Applies to lines 152-158 as well.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/vm-isolation-research.md` around lines 130 - 133, Revise the VM-boundary
claims in the referenced discussion, including lines 152–158, to apply only to
Docker-backed container workloads rather than every earning binary. Preserve the
per-provider dashboard statement, and explicitly represent mixed or unknown
runtime boundaries when services use different or unsupported execution modes,
including native Mysterium and hybrid deployments.
| 2. **On Linux, document the VM option rather than automating it.** This is the | ||
| only platform where a VM adds a boundary that is not already there. But it is | ||
| also where CashPilot most often runs on a server that does nothing else, which | ||
| is the "calculated risk" this page opens by acknowledging. A page describing | ||
| how to run the whole stack inside a VM — and being honest that it costs | ||
| nothing in GPU earnings, per the measurements above — serves the users who | ||
| want it without committing the project to a hypervisor abstraction. |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Locate and inspect the referenced documentation around the claim and nearby context.
fd -a 'vm-isolation-research\.md$' . | sed 's#^\./##' | while read -r file; do
echo "=== FILE: $file ==="
wc -l "$file"
echo "--- lines 130-185 ---"
sed -n '130,185p' "$file" | nl -ba -v130
done
echo "--- references to Linux VM, GPU, WSL, Tart, measurements ---"
rg -n -i "linux|vm|gpu|wsl|tart|measurement|earnings|passthrough|hypervisor" "$(fd 'vm-isolation-research\.md$' . | tr '\n' ' ')"Repository: GeiserX/CashPilot-Desktop
Length of output: 341
🏁 Script executed:
#!/bin/bash
set -euo pipefail
FILE="docs/vm-isolation-research.md"
echo "=== lines 130-185 ==="
awk 'NR>=130 && NR<=185 { printf "%4d\t%s\n", NR, $0 }' "$FILE"
echo "--- references to Linux VM, GPU, WSL, Tart, measurements ---"
rg -n -i "linux|vm|gpu|wsl|tart|measurement|earnings|passthrough|hypervisor|qemu|virtual" "$FILE"
echo "--- file section outlines by heading ---"
rg -n '^#+ ' "$FILE"Repository: GeiserX/CashPilot-Desktop
Length of output: 8713
Qualify the Linux VM GPU-cost claim.
The Linux recommendation extends macOS Metal and Windows WSL2 measurements to a Linux VM option, but Linux GPU passthrough/VM GPU behavior is unmeasured. Replace “it costs nothing in GPU earnings, per the measurements above” with “GPU impact is unmeasured unless Linux-specific measurements support it” before relying on this guidance.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/vm-isolation-research.md` around lines 160 - 166, Update the Linux VM
recommendation in the documented option section to qualify the GPU-cost
statement: replace the claim that it costs nothing in GPU earnings with wording
that Linux VM GPU impact is unmeasured unless supported by Linux-specific
measurements. Do not extend the macOS Metal or Windows WSL2 results to Linux.
The page recorded GPU throughput and CUDA visibility. It never measured the resource or cost difference between 'Desktop spawns a VM per service' and 'run Desktop inside a VM', so 'roughly two orders of magnitude' was a number with nothing behind it. State the difference qualitatively -- one is a subsystem on three platforms, the other is a docs page -- and keep the conclusion, which the measurements do support: neither option is justified.
|
Good catch, and fixed — the claim was unsupported. The page measured GPU throughput and CUDA visibility. It never measured resource or cost for "Desktop spawns a VM per service" versus "run Desktop inside a VM", so "roughly two orders of magnitude" was a number with nothing behind it. Replaced with a qualitative statement of the real asymmetry — one option is a subsystem to build and support on three platforms, the other is a documentation page — and kept the conclusion, which the measurements do support: neither is justified. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #118 +/- ##
=======================================
Coverage 74.45% 74.45%
=======================================
Files 18 18
Lines 3785 3785
=======================================
Hits 2818 2818
Misses 761 761
Partials 206 206 🚀 New features to boost your workflow:
|
1 participant
CashPilot-Desktop-bamasked for research and a recommendation. The research was already here and it's excellent — measured on real hardware, not quoted from vendor docs. This adds the conclusion it was missing.The recommendation
Two options were on the table: Desktop spawns a VM per service, or document "run Desktop itself in a VM." They differ by roughly two orders of magnitude in cost.
The measurements point at neither. Don't build a VM orchestrator — on macOS and Windows the boundary already exists, and the work is making it visible.
Why
Docker Desktop doesn't run containers on the host. It runs them inside a Linux VM — LinuxKit under Virtualization.framework on macOS, WSL2 on Windows. This page already records the Windows half, including that Salad ships its own WSL2 distribution.
So on the two platforms where anyone actually runs Desktop, every third-party earning binary is already in a virtual machine. A second layer would rebuild, at considerable cost, a boundary the platform hands you free.
That reframes the whole feature. The gap isn't isolation — it's that nothing tells the user which boundary they're behind, and the answer differs per platform in a way nobody could guess:
Linux is the one row that differs, and it differs in the direction that matters: an escape there lands on the user's own kernel.
What to build, in order
internal/runtimealready distinguishesdocker-desktop-macos,docker-desktop-windows,colimaand the rest. Turning that into an honest sentence — "your services run inside a Linux VM" vs "your services share this machine's kernel" — is a small change on existing code, and it's the entire remaining value on macOS and Windows.What this avoids
Per-platform hypervisor backends, guest image lifecycle and updates, VM networking that must preserve each service's egress IP (providers cap per IP —
CashPilot-5qc), GPU passthrough plumbing, and a UI for all of it.One claim I did not measure
That Docker Desktop on macOS uses a LinuxKit VM. It's the documented architecture and matches the Windows behaviour measured on this page — but every other claim here was verified on hardware and this one wasn't, so it's flagged in the text rather than blended in.
docker infoon a Mac settles it in one line: a Linux kernel, not Darwin.Docker wasn't running locally this session, which is exactly why it's marked rather than asserted.
Summary by CodeRabbit