Problem
Currently, each container VM allocates CPU and memory at startup with fixed limits. There is no way to hot-adjust these limits while a container is running. This makes it difficult to build higher-level orchestration on top of container, because resources cannot be fluidly redistributed across containers based on load.
Use case
Running multiple containers on a Mac Studio (e.g., LLM inference + database + web server + Home Assistant). When idle containers sit with unused memory while active containers hit OOM, you currently have to manually stop/restart to resize — which defeats the purpose of running them as always-on services.
Even more interesting: a dedicated "orchestrator container" that monitors resource usage across all business containers and dynamically shifts memory/cpu from idle containers to busy ones, similar to a single-node Kubernetes scheduler.
Proposed solution
- Expose an API (CLI or gRPC) to hot-resize a running container VM:
container resize <name> --memory 16GB --cpu 4
- Support Linux memory balloon driver in the bundled kernel config, so the guest OS can shrink/expand its memory without rebooting
- Or extend
container machine to support runtime resource tuning
Why this matters
The VM-per-container model gives great isolation, but without dynamic resource reallocation, the isolation comes at the cost of rigid resource silos. Adding hot-resize would unlock a class of use cases where container transitions from "dev tool" to "local server platform."
Related: would love to see a container stats command showing current memory/cpu usage per container.
Thanks for the great work on v1.0!
Problem
Currently, each container VM allocates CPU and memory at startup with fixed limits. There is no way to hot-adjust these limits while a container is running. This makes it difficult to build higher-level orchestration on top of container, because resources cannot be fluidly redistributed across containers based on load.
Use case
Running multiple containers on a Mac Studio (e.g., LLM inference + database + web server + Home Assistant). When idle containers sit with unused memory while active containers hit OOM, you currently have to manually stop/restart to resize — which defeats the purpose of running them as always-on services.
Even more interesting: a dedicated "orchestrator container" that monitors resource usage across all business containers and dynamically shifts memory/cpu from idle containers to busy ones, similar to a single-node Kubernetes scheduler.
Proposed solution
container resize <name> --memory 16GB --cpu 4container machineto support runtime resource tuningWhy this matters
The VM-per-container model gives great isolation, but without dynamic resource reallocation, the isolation comes at the cost of rigid resource silos. Adding hot-resize would unlock a class of use cases where container transitions from "dev tool" to "local server platform."
Related: would love to see a
container statscommand showing current memory/cpu usage per container.Thanks for the great work on v1.0!