Docker-style containers for Windows, Linux, and macOS — no VTx, no Hyper-V, no Docker, no WSL.

A single ~2 MB binary. Pure OS kernel primitives (AppContainer on Windows, namespaces+cgroups on Linux, sandbox-exec on macOS).
Works on VMs, bare metal, and cloud instances where nested virtualization is unavailable.

Quick Start • Why Psroot? • Features • Commands • Architecture • Isolation Tiers • Building • Docs

# Drop into an isolated container shell — one command, zero setup
psroot shell

# That's it. You're inside an AppContainer sandbox:
psroot> echo %USERNAME%
ContainerUser

psroot> echo %COMPUTERNAME%
PSROOT

psroot> echo %PATH%
C:\...\rootfs\Windows\System32

psroot> exit

# Container with Node.js and outbound internet
psroot shell --tool node --network outbound

# Container with Rust CLI tools
psroot shell --tool rust-bin

# Run a specific command and exit
psroot run -- cmd /c "echo Hello from the sandbox"

# Create → Start → Exec → Stop → Remove
psroot create --name myapp --memory 512M --cpu 5000 --tool node
psroot start myapp
psroot exec myapp "node -e \"console.log('hi')\""
psroot stats myapp
psroot stop myapp
psroot rm myapp

# Or list everything
psroot ls

The problem is real. If you've ever tried to run containers on:

• ☁️ A cloud VM without nested virtualization (most AWS/GCP/Azure instances)
• 🖥️ A Windows VM on Proxmox, QEMU, or older ESXi without VT-x passthrough
• 💻 A machine where Docker Desktop / Hyper-V / WSL2 can't be installed
• 🏢 A corporate environment where admin rights are restricted

...you know the frustration. Docker on Windows requires Hyper-V or WSL2. Both require hardware virtualization. No VT-x? No containers. Until now.

Psroot uses only native Windows kernel primitives — the same APIs that Chrome, Edge, and the Microsoft Store use for sandboxing. No virtualization hardware. No hypervisor. No kernel drivers. No elevated privileges required for the standard tier.

Psroot uses Windows AppContainer — the same sandbox technology that isolates Chrome tabs, Edge processes, and Microsoft Store apps. This is a kernel-enforced boundary, not a userspace hack.

AppContainer process CANNOT:
  ✗ Read C:\Users\*          (your files are invisible)
  ✗ Read C:\Program Files\*  (host software is invisible)
  ✗ Write anywhere outside the container rootfs
  ✗ Access the Windows registry (AppContainer-scoped hive only)
  ✗ See other processes' named objects (mutexes, events, sections)

AppContainer process CAN:
  ✓ Read C:\Windows\System32  (shared OS libraries, same as Docker)
  ✓ Read/write the container rootfs
  ✓ Run cmd.exe, PowerShell, Node.js, Rust binaries

Inside a psroot container, processes can only see their own process tree — not the host's processes. This is implemented via psroot-procshim, a DLL injected at container start that intercepts process enumeration at the OS level.

All process listing APIs are covered from a single chokepoint — NtQuerySystemInformation in ntdll — so tools like tasklist, Get-Process, CreateToolhelp32Snapshot, and .NET's Process.GetProcesses() all return the filtered view automatically. OpenProcess on host PIDs is blocked with ACCESS_DENIED.

This achieves PID-namespace-equivalent isolation on the Standard tier, without admin privileges or Server Silos.

psroot shell --network none      # Default: no network at all
psroot shell --network outbound  # Can reach the internet, can't listen
psroot shell --network full      # Full network + loopback (for servers)

Host environment variables are completely replaced inside the container. No path leaks, no username leaks, no tool path leaks:

35+ environment variables are sanitized, including VS Code paths, tool paths, and any variable containing host directory references.

psroot shell --memory 512M --cpu 5000 --max-procs 50

• Memory limits — hard cap, process killed on exceed (like Docker --memory)
• CPU throttling — 1–10000 scale (5000 = 50% of all cores)
• Process count limits — prevent fork bombs
• Full accounting — psroot stats <id> shows memory/CPU/process usage

Containers auto-provision with tools from your host:

psroot shell --tool node       # Copies Node.js + npm into rootfs
psroot shell --tool rust-bin   # Copies Rust CLI tools from ~/.cargo/bin
psroot shell --tool winget     # Sets up winget support directories

psroot test all

Runs a comprehensive test suite covering:

• Job object limits (memory, CPU, process count)
• Filesystem isolation (host paths inaccessible)
• Process visibility (host processes not enumerable)
• Network isolation (connectivity control)
• Environment sanitization (no host leaks)
• AppContainer enforcement (registry, named objects)
• Stress tests (100 processes, rapid spawn/kill)

See the full CLI Reference for all flags and options.

Psroot is admin-aware — it automatically detects what's available and uses the strongest isolation possible:

PS> psroot info

Psroot System Capabilities
─────────────────────────────────────
Windows Build:    19045
Administrator:    NO
Job Objects:      ✓
Process Shim:     ✓
Server Silos:     ✗ (needs admin + build >= 17763)
Bind Filter:      ✗ (needs admin + build >= 26100)
VTx Required:     NO (pure kernel primitives)

Isolation Level:  Standard (AppContainer + ProcShim + Env)
  ⚠ Non-admin: server silos and bind filter unavailable
    Run as Administrator for full namespace isolation

Standard tier is strong. It's the same kernel sandbox that Chrome uses for renderer processes, plus process visibility isolation and resource limits on top. Admin tiers add mount-level path remapping and full PID/IPC/UTS namespace separation via Server Silos.

Psroot is a Cargo workspace with focused crates:

psroot (workspace)
├── psroot-types         # Config, errors, state types
├── psroot-job           # Job Objects (memory/CPU/process limits + accounting)
├── psroot-bindlink      # Bind Filter filesystem remapping (admin, Win 11 24H2+)
├── psroot-namespace     # Object namespace isolation via NT APIs
├── psroot-silo          # Server Silo creation and management (admin)
├── psroot-container     # Container lifecycle + AppContainer sandbox + rootfs
├── psroot-procshim      # Process visibility isolation (ntdll inline hooking)
├── psroot-netinject     # DLL injection (CreateRemoteThread + LoadLibraryW)
├── psroot-netshim       # Network interception layer
├── psroot-netstack-*    # Virtual network stack (host/ipc/proto)
├── psroot-portmap       # Port forwarding for containerized servers
├── psroot-rootfs-stager # Rootfs provisioning and tool staging
├── psroot-shell-resolver# Interactive shell resolution
├── psroot-desktop       # Desktop integration
├── psroot-unix          # Linux/macOS backend (namespaces+cgroups / sandbox-exec)
└── psroot-cli           # CLI interface (clap)

No kernel drivers. No virtualization. Just the Windows kernel doing what it already knows how to do.

Psroot's Windows backend is the unique value-add. On Linux and macOS it provides a consistent CLI over the platform's native primitives:

• Rust 1.75+ (stable)
• Windows 10 build 17763+ (for runtime — compiles anywhere)

git clone https://github.com/psmux/Psroot.git
cd Psroot
cargo build --release

The binary lands at target\release\psroot.exe (~2 MB with LTO).

.\target\release\psroot.exe test all
# RESULTS: 66/66 passed, 0 failed

Q: Is this as secure as Docker? A: Different trade-offs. Docker uses a hypervisor (hardware boundary). Psroot uses AppContainer + process visibility isolation (kernel boundary). AppContainer is battle-tested — Chrome trusts it for billions of users. For dev/CI/tooling workloads, it's excellent. For multi-tenant hostile workloads, use a VM.

Q: Can I run Linux binaries? A: No. Psroot runs native Windows executables. For Linux binaries, you need WSL2 (which needs VT-x). Psroot is for Windows-native workloads.

Q: Does it work on Windows Server? A: Yes. Windows Server 2019+ supports all the APIs. Server editions also unlock Server Silos for the Full isolation tier.

Q: Can I use this in CI/CD? A: Absolutely — that's a primary use case. Isolate build steps, run untrusted scripts, limit resource usage. Works on any Windows CI runner, even those without nested virtualization.

Q: How does process visibility isolation work? A: The psroot-procshim DLL is injected before the container's first process starts. It patches ntdll's NtQuerySystemInformation and NtOpenProcess at the function entry point, so every process enumeration API (tasklist, PowerShell Get-Process, WMI, .NET, Toolhelp32) returns only the container's own processes. This is a single kernel-level chokepoint that catches all callers.

Q: Why Rust? A: Zero-overhead FFI to Win32 APIs. Single static binary. No runtime dependencies. Memory safety for security-critical sandbox code. Compiles to a 2 MB binary that starts in under a second.

MIT

Built by psmux