Nano11, an extreme offshoot of the popular Tiny11 project, can squash a Windows 11 installation down to just 2.8GB. The script strips away almost everything Microsoft considers essential, leaving a bare-bones OS that boots but can’t be serviced, patched, or trusted for daily use. It’s a remarkable engineering demo with a very narrow audience.

Behind the microscopic footprint is a PowerShell-driven builder that leverages Microsoft’s own DISM tools and recovery compression (LZMS/LZX) to remove inbox apps, security components, language packs, drivers, and even the servicing stack. The result is an image that might be up to 3.5 times smaller than a standard Windows ISO, but the developer’s warning is blunt: “You cannot add back features or languages … The resulting OS is not serviceable.”

How Nano11 Carves Away Windows’ Bulk

Nano11 builds on the Tiny11 core, a project by developer NTDEV that pioneered aggressive offline servicing to produce lighter Windows images. While Tiny11 already removes many pre-installed apps and optional components, Nano11 goes further by deleting Windows Hello packages, .NET precompiled assemblies, IME components, wallpapers, unnecessary drivers, and even parts of the Windows Update and servicing infrastructure.

The toolchain is entirely based on Microsoft’s own image utilities, avoiding closed-source third-party compressors. The workflow follows a repeatable sequence:

  • DISM (Deployment Image Servicing and Management) mounts an official Windows ISO and removes packages, features, and language packs.
  • oscdimg.exe (from the Windows Assessment and Deployment Kit) repacks the modified image into a bootable ISO.
  • PowerShell orchestrates the entire process, feeding removal lists and compression flags.
  • The critical flag /Compress:recovery applies LZMS/LZX compression to the WIM/ESD payload, achieving far higher density than standard modes.

This surgical removal list targets a long lineup of heavyweight components:

  • Inbox apps: Clipchamp, Mail & Calendar, Xbox apps, Solitaire, Media Player, and more.
  • Modern clients: Copilot, the new Outlook, consumer Microsoft Teams.
  • Cloud hooks: OneDrive integration bits.
  • Browser payloads tied to Edge.
  • Security and servicing: Windows Defender, Windows Update servicing stack, parts of WinSxS.
  • Biometric frameworks, Windows Hello packages, IME components, and non-essential language packs.
  • Wallpapers, optional fonts, accessibility extras, and certain device driver packages.
  • Runtime assemblies and .NET precompiled assemblies in the most aggressive profiles.

Once the image is installed, further shrinkage comes from enabling CompactOS (compact.exe with EXE:LZX mode), which compresses system binaries on the fly, and optionally removing the pagefile. The combined effect can take a vanilla installation from over 20GB to the low single digits.

The Numbers: What’s Verified and What’s Variable

Community demos and independent tests, including those reported by Windows Central, confirm that Nano11 can produce ISOs as small as 2.28GB and fully installed footprints around 3.25GB. With a Windows 11 LTSC source and full LZX compression, the developer demonstrated a system installed at just 2.8GB. These figures are reproducible under the right conditions, but they are not universal guarantees.

Key variables that swing the final size:

  • Source SKU: LTSC or single-language Pro ISOs compress more than multi-language consumer editions.
  • Language packs and IMEs: Removing these can save gigabytes but also eliminates multilingual support.
  • Driver bundles and OEM packages in the WinSxS store dramatically affect outcomes.
  • Post-install CompactOS and pagefile removal shave off a few hundred additional megabytes.

Treat the headline 2.8GB number as a best-case case study, achieved with a deliberate set of choices: LTSC, English only, driver stripping, and maximum compression. Your mileage will vary.

Valid Use Cases Where Nano11 Shines

For all its warnings, Nano11 has genuine utility in tightly constrained environments:

  • Rapid VM provisioning and CI/CD: Tiny images and tiny installed footprints mean faster spin-up and lower storage costs for disposable test VMs. Build artifacts that were once several gigabytes now fit into a few hundred megabytes of differential storage.
  • Embedded and constrained devices: Single-purpose kiosks, digital signage, and industrial controllers with controlled lifecycles can benefit from deterministic, minimal images. In-place updates are replaced by periodic image rebuilds.
  • Forensic sandboxes and malware labs: A minimal host reduces noise and attack surface, letting analysts focus on target behavior without inbox apps or telemetry interference.
  • Educational case study: The project is a masterclass in how component stores, servicing stacks, and compression interact to shape a modern OS image.

In these niches, the trade-offs are acceptable because the machines are either air-gapped, disposable, or updated through image rebuilds.

Why Nano11 Is a Dangerous Daily Driver

The list of what you lose is structural, not cosmetic. Several risks are absolute, not probabilistic:

  • No Windows Updates, ever: When servicing components and WinSxS are gutted, the image cannot receive security patches through Windows Update. The only path to remediation is rebuilding and redeploying the entire image, a model that is impractical for most endpoints.
  • No built-in security: Many Nano11 builds remove Windows Defender and other security primitives. You must supply a third-party AV and a reliable update pipeline—an operational burden that is easy to get wrong on a locked-down system.
  • Driver and feature breakage: Stripping drivers, IMEs, biometric frameworks, and audio stacks can render hardware useless. Wi-Fi, fingerprint readers, cameras, and GPU features may never work without manually injecting back the exact missing components.
  • Compatibility gaps: Modern applications expect optional multimedia and runtime frameworks that are absent from Nano11. Expect to manually reinstall dependencies and accept that some software will simply fail.
  • Legal and support consequences: Deploying community-modified images in an organization may violate Microsoft licensing or void support agreements. Internal compliance teams will need to sign off, and you cannot redistribute full modified ISOs without careful legal review.
  • Supply-chain trust: While the builder uses Microsoft’s own binaries, the removal logic comes from a third-party script. Running unreviewed code in sensitive environments is a risk that demands thorough auditing.

The developer’s own documentation, echoed by multiple community reports, states clearly: Nano11 is “not meant as a daily driver” and is intended “only for testing, development, or embedded use in VMs.”

Under the Hood: Cross-Checking the Technical Claims

Several claims made by Nano11 are verifiable against Microsoft’s documentation and community observations:

  • DISM supports offline package removal and export compression flags, including /Compress:recovery for LZMS/LZX. This is documented in Microsoft’s ADK references and has been used legitimately for years in corporate imaging.
  • CompactOS and EXE:LZX compression are supported Windows features, often used on low-storage devices like tablets. Enabling them on a trimmed Nano11 installation further reduces on-disk size.
  • Removing the WinSxS component store and servicing hooks indeed breaks Windows Update. This is not conjecture; it’s a direct functional consequence of removing the infrastructure that processes updates.
  • The specific ISO size (2.28GB) and installed size (2.8GB) figures are attested in multiple independent tests and the developer’s own demos, always with the caveat of using LTSC and specific compression choices.

Where a claim depends on configuration (like final installed size), Nano11’s own notes flag the variability. No credible source suggests these numbers are achievable on every possible combination of hardware and SKU.

How to Experiment Safely Without Nuking Your PC

If you want to tinker with Nano11, follow a disciplined approach used by the community and recommended by the developer:

  1. Use a disposable testbed: Virtual machines or air-gapped hardware only. Never run a Nano11 Core image on a production desktop.
  2. Start from verified media: Download official Windows ISOs from Microsoft and check hashes before letting any script touch them.
  3. Audit the builder script: Read the PowerShell code line-by-line. Know exactly what packages and features are being removed.
  4. Choose the serviceable profile: The builder offers a less aggressive “serviceable” variant that preserves the servicing stack and Windows Update. If you need periodic patching, this is the only safe option.
  5. Test comprehensively: Validate drivers, network connectivity, multimedia, and your intended application stack before committing to a deployment. Check whether third-party security agents can be installed.
  6. Adopt immutable infrastructure: Treat trimmed images as artifacts that are rebuilt on each patch cycle, rather than trying to patch them in place.
  7. Maintain rollback: Keep rescue ISOs, snapshots, and documented recovery procedures.
  8. Review licensing: Consult your organization’s legal team about deploying modified Windows images, even in labs.

These steps reflect the consensus from both Nano11’s own documentation and the wider Windows enthusiast community.

Operational Advice by Scenario

Labs, CI/CD, and QA
Nano11’s small size pays dividends in storage and provisioning speed. Use the serviceable profile where possible, and integrate image rebuilds into your pipeline to absorb security updates.

Embedded devices and kiosks
Only deploy Nano11 if the device lifecycle is fully controlled and you can push updates by reimaging. Maintain a signed, auditable build process.

Security sandboxes and forensics
The deterministic footprint is a plus, but isolate the host completely. A vulnerable persistent OS could compromise your analysis.

Enterprises and production endpoints
Do not deploy Nano11 Core images on internet-connected desktops or servers that rely on Microsoft’s patch cadence. If storage pressure forces trimming, use a serviceable Tiny11 profile and retain the servicing stack.

The Bottom Line: Incredible Engineering, Real Constraints

Nano11 is a showcase of what offline servicing and compression can achieve when you throw away the rulebook. It shrinks Windows 11 to the size of a live Linux ISO and boots in a fraction of the normal time. For developers, testers, and embedded engineers, it’s a powerful tool that slashes storage and deployment overhead.

But the same techniques that deliver the tiny footprint also sever the lifelines that keep a Windows PC secure and current. Removing the servicing stack transforms Windows from a continuously patched, vendor-supported OS into a static artifact that must be rebuilt from scratch to receive fixes. That model works for ephemeral VMs and sealed appliances; it’s reckless for a laptop that browses the web.

The community and the developer are refreshingly candid about these limits. Nano11 is not a daily driver, and it’s not a replacement for a properly maintained Windows installation. It’s a precision instrument for a narrow set of problems—and in those situations, it delivers exactly what it promises.