What Is Hyperbutler? The Beginner's Guide to Docker on Windows Without WSL

CodexFuse Team · 2026-11-05T21:45:20.325Z · 19 min read min read

What Is Hyperbutler? The Beginner's Guide to Docker on Windows Without WSL

What Is Hyperbutler?

Hyperbutler is an open-source Docker engine for Windows 11 that runs Linux containers without WSL. That is the short answer to what is hyperbutler, and it is the whole pitch: instead of installing Windows Subsystem for Linux and letting Docker Desktop run its virtual machine inside it, Hyperbutler boots a minimal Linux virtual machine directly through the Windows Host Compute Service (HCS), the same low-level API that WSL 2 uses underneath, and then runs the Docker daemon inside that virtual machine.

The project is brand new. Its GitHub repository was created on 31 October 2026, the maker announced it on dev.to on 3 November 2026, and by 6 November 2026 the current release was v0.1.1. Treat Hyperbutler as early software: the project is six days old at the time of writing, and its maker still calls it a preview-era project. That matters more than any benchmark in this article, because early software changes fast and some release tests had not finished yet.

Hyperbutler is free and open source under the Apache License 2.0, and there is no paid tier at any company size. If you download the installer, check it first: a SHA-256 hash generator gives you the file fingerprint to compare against the release's SHA256SUMS file. You run everything on your own Windows machine, and if you ever need a Linux server of your own to host things on, a VPS hosting plan is the usual way to rent one.

Hyperbutler is not made by Docker, Inc., and it is not affiliated with or endorsed by Docker, Inc. or Microsoft. It is one developer's answer to a specific frustration: Docker Desktop on Windows runs on WSL 2, and WSL 2 is a general-purpose Linux virtual machine that a container engine happens to share.

Hyperbutler builds something narrower, a virtual machine that exists only to run containers, and nothing else.

How Does Hyperbutler Run Docker Windows Without WSL?

Hyperbutler runs Docker Windows without WSL by asking Windows itself to boot a small Linux virtual machine. It uses the Host Compute Service (HCS), the same Windows API that WSL 2 uses underneath, and then runs the Docker daemon inside that virtual machine. WSL is never installed, never started, and never involved in the path between your docker command and your container.

The Hyperbutler Docker Windows setup has three parts, and each one gets only the privilege its job needs. The engine, hyperbutler.exe, runs as your normal user account with no administrator rights. It relays the Docker API from the Windows named pipe into the virtual machine, runs the virtual machine's network in user mode with the gVisor netstack, and serves bind mounts from C:\ over FUSE.

The engine itself idles at about 18 MB.

The broker service, hyperbutler-broker.exe, is the only part that talks to HCS. It runs as a Windows service under the SYSTEM account and accepts just seven short, typed requests, such as start, stop, status, and pause. It builds the virtual machine from a fixed template, verifies the guest image against a SHA-256 hash compiled into the binary, and treats the connection that started the virtual machine as its lease, so the virtual machine stops when that connection closes.

Daily use needs neither administrator rights nor Hyper-V Administrators membership.

The guest is a minimal Alpine Linux userland. Inside it, the guest agent hyperbutlerd runs dockerd and containerd. Its system disk is read-only and pinned by hash, and its data disk is sparse, so it hands freed blocks back to Windows when you delete images.

That is why deleting images gives your disk space back automatically instead of leaving a virtual disk at its largest size.

That design answers the obvious question: if every Linux container still needs a Linux kernel, what did removing WSL actually remove? It removed a general-purpose Linux distribution, a second package manager, and a whole subsystem you had to install, update, and troubleshoot. What is left is a single-purpose virtual machine that exists only to run containers.

To understand the pieces, it helps to know what Docker is: a platform that packages applications with their dependencies into containers that share one Linux kernel.

Hyperbutler vs Docker Desktop

Hyperbutler vs Docker Desktop is a contest between a narrow, lightweight engine and a broad, mature platform. Hyperbutler wins on size, idle memory, and startup speed on the maker's one test machine. Docker Desktop wins on breadth: Kubernetes, Windows containers, extensions, a mature graphical interface, and support contracts.

Which one fits depends on whether you want the smallest possible Docker setup or the fullest one.

The numbers in that table are the current ones from the project's README and official site, reflecting v0.1.0-rc.1 and later. The launch post measured 322 MiB idle, a 116 MB download, and a 179 MB installed size on the earlier preview build. The difference is the build, not a correction: the newer releases added the broker service and changed what gets measured, so the current figures supersede the launch figures.

Docker Desktop's newer Docker VMM backend, in beta since version 4.86, is worth a mention because it attacks the same problem Hyperbutler does: it reclaims idle memory and improves file input and output. Docker Desktop is not standing still on lightness. The difference is that Docker VMM is one backend inside a large product, while Hyperbutler is a product built entirely around being small.

How Fast Is Hyperbutler?

Every performance figure in this article was measured by the maker on one laptop, not by an independent tester. The machine was a Windows 11 Home laptop with an Intel Core Ultra 7 155H processor and 32 GB of RAM, measured on 2 November 2026, with both engines at their out-of-the-box settings, one at a time, using the same script. The maker states it plainly: "One machine, one build of each.

This is not a general result."

The gaps are large in absolute terms. Docker Desktop's idle memory of 1.7 to 2.7 GB is roughly 5 to 8 times Hyperbutler's 319 MiB. Its 592 MB download is about 5 times the 120 MB installer, and its roughly 6.7 GB installed size is about 34 times the 197 MB install.

Starting a first container took 2.5 seconds against 5.6, about 2.2 times faster. Bind mounts were the most dramatic gap: listing 2,000 small files took 0.04 seconds against 2.3, about 57 times faster, while reading them took 0.4 seconds against 3.4, about 8.5 times faster, and writing them took 1.8 seconds against 4.9, about 2.7 times faster.

Docker Desktop has one honest counterweight: Resource Saver. After about seven minutes without containers, Docker Desktop stops its virtual machine, and its host processes then use 404 MiB. That is still about 27 percent more than Hyperbutler's 319 MiB with its virtual machine running, but the next docker command has to wait for the virtual machine to boot again, and the maker did not measure that wait.

Docker publishes no official idle-memory figure for Docker Desktop, so the 1.7 to 2.7 GB range is the maker's measurement, not a Docker claim.

Three things were not measured at all: network throughput against Docker Desktop, docker build, and GPUs. The full method, the raw data files, and the list of what was not measured are in docs/compare-docker-desktop.md in the repository. Defaults matter here too: WSL by default gives Docker Desktop's virtual machine half the RAM, 16 GB on the test machine, and all 22 logical processors.

Docker Desktop was not tested with a smaller virtual machine set in .wslconfig, and Hyperbutler was not tested with a bigger one.

The soak tests are the strongest evidence that the engine holds together under load. Version 0.1.0 passed a 24-hour soak of 261,338 docker commands with none failing and no memory-leak trend, which averages about 3 commands every second for a full day. The earlier preview build passed a 1-hour soak of 12,827 commands.

Version 0.1.1 made bind mounts from C:\ about twice as fast.

How Do You Install Hyperbutler?

The Hyperbutler install has two paths: the MSI installer, which the maker recommends, and a zip file for developers who want no installer. Both need the same thing first: Windows 11 on x64 with virtualization enabled in the firmware. Windows 10 is not supported, and there is no Windows container support to install for.

1. Download the MSI from the latest GitHub release.
2. Check the download against the release's SHA256SUMS file before you run it.
3. Run the MSI and accept the one UAC prompt. It installs the broker service, sets up the PATH, and turns on Virtual Machine Platform if it is off.
4. Restart if asked, or open a new terminal so it sees the new PATH, and sign out and back in if prompted.
5. Run hyperbutler start, then docker run --rm hello-world to confirm it works.

Builds are not code-signed yet, so Windows SmartScreen warns before the installer runs. Click More info, then Run anyway, only after you have checked the hash. Every release file also carries build provenance you can verify with gh attestation verify, which confirms the file was built by the project's own release workflow.

The zip path works without installing anything, but it has no broker service, so your account needs Hyper-V Administrators membership. The maker warns that membership is close to administrator rights, because every program you run inherits control of Hyper-V virtual machines. Treat the zip as a developer mode, not the normal install.

How Do You Run Your First Container?

Once the engine is installed, the daily experience is the stock docker CLI. Hyperbutler adds a hyperbutler docker context, and your existing docker commands, Compose files, and SDKs talk to it through the named pipe. Switching back to Docker Desktop is one command: docker context use desktop-linux.

If you are new to the commands themselves, a guide to how to use Docker covers the basics before you try them here.

hyperbutler start                 # boots the VM; the Docker API answers in about 1.5 s
docker run --rm hello-world
docker compose up -d              # in a folder with a compose.yaml
hyperbutler status                # is it running, and which docker it serves
hyperbutler stop

The first start boots the virtual machine, and the Docker API answers in about 1.5 seconds. Hyperbutler status tells you whether the engine is running and which docker it serves. Hyperbutler stop shuts the virtual machine down.

If you already run Docker Desktop, hyperbutler import --from-desktop copies your images and volumes over and leaves Docker Desktop exactly as it was. Installing the two side by side is fine, and the import is the fastest way to try Hyperbutler without rebuilding your containers.

What Works With Hyperbutler?

Hyperbutler runs Linux containers with the Docker CLI and Compose, and that is the full list. Compose is tested end to end: builds, healthchecks, service names, named volumes, bind mounts, and published ports. Bind mounts from C:\ go through Hyperbutler's own file server, and a change on Windows reaches inotify in a few milliseconds, so Vite and webpack rebuilds fire normally.

The Docker API is exposed on a Windows named pipe, and if you have never worked with one, what an API is matters here: it is the contract your docker CLI uses to ask the daemon to start, stop, and list containers. Networking runs in user mode, so published ports answer on localhost, host.docker.internal resolves, and DNS and NAT work without a virtual switch, a vEthernet adapter, or administrator rights. That is also why daily use needs no administrator rights at all.

What Is the Hyperbutler MCP Server?

Hyperbutler mcp is a Model Context Protocol server that runs on standard input and output, so an MCP client such as your editor's AI assistant can see what the engine is doing. It opens no network port and exits with its client. By default it is read-only: it can report status, containers, logs, images, volumes, and disk and memory use, and it can run settings and diagnose.

Writing needs an explicit flag. The --allow-write flag adds start, stop, run, pull, and config_set, and deleting needs --allow-delete as well. A tool that is not allowed is not listed at all, so it cannot be called by mistake.

Results pass through the same redaction as hyperbutler diagnose and are bounded in size, so logs and settings do not leak secrets into your editor.

The configuration is a few lines in your MCP client settings, pointing at the hyperbutler executable with the mcp argument. That is the whole setup: there is no server to host, no port to open, and no account to create. The read-only default is the right choice for most people, because an assistant that can only look cannot accidentally stop your containers.

What Can You Configure and Check?

Hyperbutler config sets memory, CPUs, and disk size for the virtual machine. A daemon.json file reaches dockerd directly for registry mirrors and insecure registries, and it applies without restarting the virtual machine. Hyperbutler doctor checks the prerequisites before you start, and hyperbutler diagnose builds a local, redacted zip for bug reports.

Nothing is uploaded.

The graphical window, hyperbutler gui, shows the engine, containers grouped by Compose project with logs, storage, settings, and troubleshooting, in English or Korean. It makes no network requests. Hyperbutler sends no usage data at all: the app checks GitHub for updates once a day, and you can turn that off.

When Should You Not Use Hyperbutler?

Windows 11 only, and Linux containers only. If you run Windows 10, if you need Windows containers, or if you need Kubernetes, Hyperbutler is not your tool. Docker Desktop covers all three, and no Hyperbutler setting changes that.

Write-heavy bind mounts are a known gap: they work, but they are not fast yet, so the maker suggests a named volume for node_modules. The installer is English only. Corporate proxies, big Compose projects, and other CPUs are untested, and the clean-PC install test and a real sleep-and-resume test had not run when this article was written.

CodexFuse does not offer a Hyperbutler tool. This article is a guide to the maker's project, not a CodexFuse product, and the download comes from the project's own GitHub releases.

Is Hyperbutler Ready for Daily Use?

The honest answer is that it depends on your tolerance for early software. Version 0.1.0 passed a 24-hour soak of 261,338 docker commands with no failures, and v0.1.1 made bind mounts about twice as fast. That is real evidence of stability, but it is evidence from the maker's own machine, and the project's own site still lists open items: the clean-PC install test, a real sleep test, corporate proxies, and big Compose projects.

If your work is a personal project or a side experiment on Windows 11, Hyperbutler is worth an afternoon. If your containers pay the bills, keep Docker Desktop installed, import your images with hyperbutler import --from-desktop, and try Hyperbutler on a copy of your stack first. Side-by-side install means the experiment costs you nothing but time.

How Do You Switch Back to Docker Desktop?

Switching back is one command, and nothing is uninstalled. Run docker context use desktop-linux, and your docker CLI talks to Docker Desktop again. Run docker context use hyperbutler to come back.

The two engines share no state, so an image you pulled under one is not visible to the other until you import it.

That separation is the safety net that makes trying Hyperbutler cheap. You keep Docker Desktop, you keep your images and volumes, and you can move between the two engines with a single command while you decide which one earns the daily job. For most Windows developers, the experiment is worth it: the worst case is that you delete a 197 MB install and go back to what you had.

Sources

1. higangssh, "I built a lightweight Docker engine for Windows: no WSL, 322 MiB idle", DEV Community, 3 November 2026. https://dev.to/higangssh/i-built-a-lightweight-docker-engine-for-windows-no-wsl-322-mib-idle-4702

2. Higangssh/hyperbutler, GitHub repository and README. https://github.com/Higangssh/hyperbutler — fetched 6 November 2026.

3. Hyperbutler official site. https://hyperbutler.dev/ — fetched 6 November 2026.

4. Show HN listing, "Show HN: Hyperbutler – Docker on Windows without WSL, 320 MB at idle". The listing exists; its points and comment counts could not be retrieved on 6 November 2026, so no Hacker News figures appear in this article.

5. Docker, "Install Docker Desktop on Windows", official documentation. https://docs.docker.com/desktop/setup/install/windows-install/ — fetched 6 November 2026.

6. Docker, "Virtual Machine Manager", official documentation. https://docs.docker.com/desktop/features/vmm/ — fetched 6 November 2026.

Frequently Asked Questions

Is Hyperbutler free?

Yes. Hyperbutler is open source under the Apache License 2.0, with no paid tier at any company size. Docker Desktop is free for personal use, education, non-commercial open source, and small businesses with fewer than 250 employees and less than $10 million in annual revenue; larger companies need a paid subscription.

Does Hyperbutler need WSL?

No. Hyperbutler boots a minimal Linux virtual machine directly through the Windows Host Compute Service, the same API that WSL 2 uses underneath, and it never installs or starts WSL. Docker Desktop's default backend on Windows is WSL 2, which is why it needs WSL and Hyperbutler does not.

Can Hyperbutler replace Docker Desktop?

For Linux containers driven by the docker CLI and Compose on Windows 11, yes, it can. It cannot replace Docker Desktop if you need Kubernetes, Windows containers, extensions, Scout and build cloud, or a support contract. Most developers who try it keep Docker Desktop installed side by side and switch between the two with docker context use.

Does Hyperbutler run on Windows 10?

No. Hyperbutler needs Windows 11 on x64, in Home, Pro, or Enterprise editions, with virtualization enabled in the firmware. Windows 10 is not supported, and there is no 32-bit build.

If you run Windows 10, Docker Desktop is the supported path.

Is it safe to install if the builds are not code-signed?

Check the download before you run it. Compare its SHA-256 hash against the release's SHA256SUMS file, and verify the build provenance with gh attestation verify if you have the GitHub CLI. Windows SmartScreen will warn because the builds are unsigned; that is expected for now.

Remember this is early software: try it, and report what breaks to the project.