Nano11: Shrinking Windows 11 to a 2-3 GB Test ISO (Non-Serviceable)

A PowerShell script named Nano11 can collapse a full Windows 11 installation image down to a tiny, bootable ISO and produce installed systems that weigh in at roughly 2–3 GB, but it does so by deliberately cutting out large swathes of the operating system — including servicing, security, drivers, and many user-facing features — making the resulting build strictly a testbed or embedded VM image, not a daily-driver OS.

Background / Overview​

Windows 11 ships as a polished, feature-rich OS with dozens of preinstalled components and services. For most users that’s convenience; for enthusiasts, refurbishers, and test-lab operators it’s unnecessary overhead. Community projects have long targeted this problem: Tiny11 proved that Windows 11 could be trimmed significantly, and now Nano11 goes further by performing aggressive component removal at the ISO image stage so those components never reach the final install.
Nano11 is a PowerShell-based builder that uses only Microsoft servicing tools (DISM) and Microsoft’s own imaging utilities to:

• remove Appx and OEM applications,
• prune optional components,
• delete selected drivers and language packs,
• strip or compress the Windows Component Store (WinSxS), and
• recompress the install image into a much smaller bootable ISO.

The project is explicitly experimental: the author warns that images created by Nano11 are not serviceable — that is, you cannot re-add components, drivers, or receive regular Windows Updates — so the intended audience is limited to virtual machines, test/dev sandboxes, and embedded images where a static, ultra-minimal footprint is desirable.

---

What Nano11 actually does (technical summary)​

How the script works at a glance​

• The script mounts an official Windows 11 ISO, selects a SKU index (Home, Pro, LTSC, etc.), and mounts the install image (WIM or ESD).
• It then executes a set of DISM component removals and feature uninstalls against the offline image.
• Optional additional optimizations include applying CompactOS/LZX compression and pruning the WinSxS component store.
• Finally, oscdimg (or the ADK utility) is used to re-create a bootable ISO from the trimmed install.wim/esd.

Key components removed by default (according to project notes)​

• Windows Update servicing components
• Microsoft Defender Antivirus and its services
• Many drivers (keeps only VGA, generic network, and basic storage drivers depending on options)
• IMEs and several language components
• Microsoft Edge, OneDrive, Xbox services, and many preinstalled Appx apps
• Internet Explorer legacy components and some accessibility pieces
• BitLocker, biometric modules, and Windows Search in aggressive profiles
  The GitHub README and media write-ups emphasize that the script intentionally strips features that would normally keep Windows serviceable — this is the primary reason the images are not updatable in the conventional sense.

---

Step-by-step: building a Nano11 image (concise guide)​

• Download an official Windows 11 ISO from Microsoft and mount it in File Explorer.
• Download Nano11 from the GitHub repository and extract the ZIP to a working folder.
• Open PowerShell as Administrator and run:
• Set-ExecutionPolicy Bypass -Scope Process
• cd C:\path\to\nano11
• Launch the builder script (nano11.ps1 or nano11builder.ps1) and follow prompts: specify mounted drive letter and choose the desired image index (Home/Pro/LTSC).
• Wait while DISM removes components and oscdimg rebuilds the ISO. The script reports progress and outputs the trimmed ISO beside the script files.

This is a one-way image transform — the resulting ISO is purposely minimal and non-servicable; follow the author’s guidance and use this for lab/test VM images only.

---

Real-world results: what installers and reporters observed​

Multiple independent tests and journalistic write-ups show consistent outcomes: Nano11 can shrink official Windows 11 ISOs from sizes in the 5–7 GB range down to the low single-digit gigabytes for the ISO and produce installed systems that occupy roughly 2.8–8 GB depending on options and post-install compression. Published reports cite examples such as a final ISO of around 2.2–2.9 GB and installed footprints ranging from ~2.8 GB (using LTSC base builds with CompactOS applied) to ~7–11 GB before LZMS/LZX re-compression steps. Those numbers vary by Windows build, whether LZX compression was applied, and which components were removed.
A hands-on account reproduced the workflow and reported an output ISO of roughly 2.09 GB reduced from an original 5.49 GB image, and an installed VM image that used about 7.7 GB on disk post-install with 2 GB RAM assigned (VS ~25 GB for a standard Windows 11 install). That same trial also noted runtime oddities (a black desktop background, missing apps, winget and curl failing until a browser was manually installed) and found that some functionality — like YouTube playback — still worked, meaning basic multimedia support remained in a minimal configuration. That anecdotal report is consistent with the documented trade-offs of removing GUI subsystems and optional drivers. (This hands-on test was performed as a single-case VM experiment and should be treated as illustrative rather than definitive for all hardware and SKUs.)

---

Benefits — where Nano11 makes sense​

• Tiny VM/Test images: Lab environments, CI/CD testing, or ephemeral sandbox VMs that only need a minimal Windows runtime. Smaller ISOs speed provisioning and reduce storage or transfer costs.
• Embedded or kiosk devices: Where a locked, immutable image is required and updates are managed outside the normal Windows servicing model.
• Refurbishers and imaging specialists: When building many identical images for controlled deployments, a minimal base can reduce attack surface and storage consumption — provided the trade-offs are acceptable.
• Research and curiosity: Demonstrates how much of Windows can be removed while preserving basic GUI boot and a trimmed shell.

The core advantage is straightforward: more control over exactly which components appear on the installed system and reduced storage/transfer overhead for deployments that will not rely on Microsoft servicing.

---

The trade-offs and outright risks​

Nano11’s power comes with significant responsibilities; these are not cosmetic or reversible changes.

• No official servicing or updates: Removing Windows Update components and the Component Store means Microsoft cumulative updates cannot be applied normally. This instantly removes the standard security and feature update model. Any system carrying sensitive data or exposed to the internet should not run this build without compensating controls.
• Defender removed — security gap: Microsoft Defender and platform protections may be stripped. Unless third-party endpoint protection is preinstalled and maintained out-of-band, the system will be vulnerable.
• Driver and hardware incompatibility: The script can remove most third-party drivers; specialized peripherals, GPUs, audio devices, and Wi‑Fi chips may not function. Some builds keep only generic VGA, storage and basic network drivers, but that is insufficient for many real machines.
• Broken or degraded app ecosystem: The Microsoft Store, winget, and Appx-dependent features may fail. In some cases, basic package managers stall or throw source errors and must be replaced by manual installers. This undermines the convenience of automated app provisioning.
• Legal/updates policy risk on unsupported installs: Community tools that patch or bypass Windows setup checks (Flyby11/Flyoobe lineage) reveal how community installs can avoid Microsoft’s validation gates — but Microsoft’s update guarantees for unsupported configurations are not guaranteed, and the company can change policies. Users should assume they are operating outside the vendor’s supported path.
• Irreversibility and data risk: Images are intentionally non-serviceable. The only safe remediation is to restore a backup or reinstall an official Windows image and re-provision apps and settings.

These are not minor caveats. They are fundamental consequences of the script’s design philosophy: create a minimal, locked, static image rather than a maintainable, general-purpose OS. Anyone considering Nano11 must weigh whether the storage and footprint gains justify the maintenance and security overhead they inherit.

---

Practical mitigation strategies when using Nano11​

If the use case still seems compelling, adopt controls that reduce risk:

• Use Nano11 only in isolated environments (lab networks, air-gapped VMs, containers, or kiosk networks behind perimeter controls).
• Do not store sensitive data on Nano11 systems; treat them as ephemeral images. Use centralized storage that is separately hardened and audited.
• If temporary internet access is required, apply perimeter protection (VPNs, NAT, IDS/IPS) and restrict outbound connections to known endpoints.
• For longer-lived installs, implement an internal update/patching workflow (image rebuilds) and schedule regular re-imaging with updated Nano11 builds rebuilt from a fresh Microsoft ISO.
• Keep a standard, serviceable recovery image on hand for failback and restore points for any production-adjacent workflow.

---

Cross-checking key claims — verification and caveats​

Multiple independent outlets and the project’s own repository corroborate several headline claims:

• The GitHub repository documents the script, steps, and the explicit warning that images are non-serviceable.
• Independent testing and reporting by outlets (Tom’s Hardware, Windows Central, The Register, PC Gamer) confirm that Nano11 is capable of producing ISOs in the ~2–3 GB range and installed footprints as small as ~2.8–3.5 GB depending on the base SKU and compression choices. These reports all stress the same trade-offs: security and updateability are intentionally sacrificed for minimal size.

Caveats to those numbers:

• Reported ISO and installed sizes vary by Windows build (Insider vs stable), chosen SKU (LTSC vs Home/Pro), and whether additional compression (LZX/LZMS) is enabled post-install.
• Single-system tests (one VM instance or one hardware run) are useful but not definitive. Different hardware, virtualized drivers, or optional components will alter the end result.
• Any claims about long-term update behavior on bypassed/trimmed installs are inherently uncertain; Microsoft may change update policies or block certain classes of unsupported images at any time. Treat statements about future updates as provisional and unverifiable.

---

Alternatives and less risky approaches​

For users who want a lighter Windows without the extreme trade-offs, consider:

• Tiny11/Tiny11 Core: Less aggressive than Nano11 but still significantly smaller than stock Windows; preserves more updateability and driver compatibility.
• Rufus + Unattend + Component Management: Create a customized install USB that removes specific Appx packages and optional features while preserving servicing components to keep the system updatable.
• Sysprepping and Image-based deployment: Build an official, serviceable image and use compression or LZX where appropriate, but keep update components intact.
• Use official Windows LTSC/LTSB builds where long-term stability and minimal feature churn is required, rather than stripping a consumer image down post-facto.

These compromise paths let administrators retain updateability and platform protections while still producing a significantly leaner baseline for deployment.

---

Responsible usage and recommended test plan​

• Test the Nano11 ISO in a sandboxed VM with snapshot capability first; do not deploy to production hardware.
• Inventory exactly which applications and driver classes your workload needs; test those functions explicitly (audio/video, GPU, Wi‑Fi, printers, TPM/BitLocker if needed).
• Verify application installers you depend on (winget, MSI, third‑party updaters) still work or prepare alternate installers and offline repositories.
• Define a recovery and re-image policy and automation to restore systems quickly if updates fail or a component is missing.
• Maintain full backups of any configuration or data on devices where Nano11 will be trialed.

A disciplined testing approach will reveal whether the footprint trade-off matches the operational cost of maintenance.

---

Critical analysis: what Nano11 proves, and what it warns about​

Nano11 is as much a technical demonstration as it is a tool. It proves that Microsoft’s Windows 11 distribution contains many layers that can be trimmed for specific use cases. That should spark two important conversations:

• On one hand, it highlights how much optional functionality arrives in stock Windows and suggests Microsoft could provide more first-party "slim" or "server-like" channels for lightweight deployments.
• On the other hand, Nano11 reveals the fragile coupling of Windows servicing, updates, and security architecture: strip the right components and the entire update path and platform protections are compromised.

For enthusiasts, this is a triumph of tooling and ingenuity. For organizations and less technical users, it is a cautionary tale: the convenience of a lean image does not justify bypassing security and servicing safeguards for general-purpose devices. The responsible path is to use such tools only in tightly controlled, non-production contexts and to prefer vendor-supported lightweight offerings where available.

---

Final verdict — who should (and should not) use Nano11​

Nano11 is best suited for:

• Lab engineers who need rapid provisioning for ephemeral VMs,
• Developers building small, repeatable test images,
• Technicians imaging specialized appliances or kiosks in a closed network,
• Hobbyists who understand the full implications and can tolerate non-updatability.

Nano11 should be avoided for:

• Primary productivity machines and personal laptops that need security updates,
• Systems holding personal or regulated data,
• Users who rely on Microsoft Store apps, automatic updates, or modern driver support out of the box.

In short: Nano11 delivers a remarkable technical result — a desktopable Windows 11 image in the low gigabytes — but the compromises are existential for the platform. Use it deliberately, not casually.

---

Closing summary​

Community-driven image builders such as Nano11 demonstrate how far Windows 11 can be stripped to serve tightly scoped use cases: smaller ISOs, faster VM provisioning, and minimal footprints. The trade-off is immediate and total: remove update mechanisms, security components, and many drivers and the OS becomes a static, non-serviceable artifact that must be maintained by rebuilding images rather than patching them. For labs, embedded devices, and controlled test environments this can be a valuable tool; for day-to-day computing it is a risk that outweighs the benefit. Anyone interested in trying Nano11 should read the project README closely, test in isolated VMs, and adopt robust recovery and rebuild procedures before considering any production use.

---

Source: MakeUseOf I cut Windows 11 down to 2GB with this debloat tool