Solon

Version française : README.fr.md.

A stack in one click: New stack… → n8n → Create and start → the browser opens on its https://…solon.local address.

Solon is a standalone container manager for Windows, in the spirit of OrbStack: one installer, no software prerequisite to install yourself, and a complete Docker engine that boots in a few seconds inside a tiny, invisible Linux machine managed entirely by Solon.

Solon is not a front-end for an existing Docker Desktop. It replaces it: Docker engine, Compose, images, volumes, networks, terminal, logs, a system-tray icon, and a few things nothing else does on Windows.

Project status (1 November 2026): 0.2.1, twenty releases in two months, written by one person. It runs my own projects every day, and it has been tested on exactly two machines: a Windows 11 Pro PC and a fresh Windows 11 Home VM. The installer is not code-signed yet (SmartScreen warning; SHA-256 published with every release). Expect rough edges on hardware I do not have — and please tell me where it breaks. That issue is the most useful place to start; ideas and pull requests are just as welcome.

0.2.0 (31 October 2026) had removed the window and kept only the tray icon and the solon command; 0.2.1 (1 November 2026) brings the window and every screen back as they were in 0.1.18. What 0.2.0 added stays, see the release notes.

What Solon does

• Starts a Docker engine (dockerd, containerd, runc, Compose) ready ~3 s after you ask for it.
• Exposes the Docker API on \\.\pipe\solon; the bundled docker and docker compose commands are already on your PATH and point at Solon, and any other Docker CLI works with a docker context.
• Relays published ports to localhost with no configuration.
• Shares your Windows folders on demand: docker run -v C:\..., --mount, Compose projects, exactly like Docker Desktop, through solonfs, Solon's own file sharing, measured 3.6 to 94× faster than the 9P sharing used by WSL2 and Docker Desktop, depending on the operation (docs/measurements.md).
• Import from Docker Desktop: if it is installed and running, Solon lists its volumes and images with their sizes and copies the ones you tick into its own engine. Nothing is changed or removed on the Docker Desktop side, and anything already in Solon under the same name is left alone.
• Addresses that always work: every running container is reachable at https://<name>.solon.local (and https://<service>.<project>.solon.local for Compose), whether it publishes a port or not, with a certificate your browser trusts (a local certificate authority created on first use). Container IPs (10.90.x.y) are reachable directly from Windows too.
• Wake on demand: a container reached through Solon that receives no traffic for ten minutes is paused (zero CPU, memory kept); the next request wakes it in a fraction of a second before being served. Databases and background workers that only talk internally are never touched.
• Files tab for containers and volumes: browse, copy to Windows, send files or folders (buttons or drag-and-drop from Explorer), create folders, delete. Works even when the image has no shell.
• Debug shell into any container, including "distroless" images with no shell: a toolbox (bash, curl, dig, ps, strace, tcpdump, jq, vim…) that shares the container's processes, network and volumes.
• Activity: live CPU, memory, storage and network of the engine and of each container.
• Radiography: a live map of who calls whom inside your projects, and a journal of every exchange — TCP connections with their outcome (a refused call shows in red), full HTTP exchanges for anything coming in through a *.solon.local address, names on outside addresses. A playback bar to pause, step and replay. Sensitive values are masked before they are stored; bodies are off by default and enabled per project.
• A solon command next to docker: engine state and addresses, start and stop with the steps shown, settings, project backup and restore, and solon why, which reads the Radiography and says in plain words why a call failed. It talks to the service through its local pipe: no administrator prompt, no outgoing request (except solon update, on demand).
• Compose projects: services, merged logs, Up / Down / Rebuild with live output, open in Explorer or VS Code.
• Idle memory (engine + service): 430 to 520 MB measured for 2 GB allocated; unused memory is returned to Windows automatically.
• No telemetry, no outgoing network request other than what your containers and your docker pull ask for.

Benchmark: performance, footprint and features

Performance: Docker Desktop vs Solon

Same machine (Windows 11 Pro, 24 logical cores, NVMe), same Compose stack (a Python web application and its PostgreSQL 16 database, bench/compose.yaml), each engine with its default settings: Docker Desktop 4.66.1 on WSL2 with every core and 6.6 GB visible to containers; Solon 0.1.0 with 22 processors and 2 GB. Docker Desktop was measured on 3 September 2026, then uninstalled from the test machine; Solon was re-measured on 10 September 2026 with the same script. Details and raw numbers: docs/measurements.md.

	Docker Desktop	Solon
Engine ready after you ask for it	6.1 s	2.6 to 3.4 s (1.1 s when the machine is still up)	2× faster
Memory at rest, no container	1,998 MB	430 to 520 MB	4× lighter
Memory with the web app + PostgreSQL running, at rest	5,146 MB	1,196 MB	4× lighter
compose down then up -d, images present	7.1 s	5.2 s
The web app answers after up	1.5 s	1.0 to 2.5 s	same
Login page of the web app, average of 5 loads	27 to 46 ms	48 to 88 ms	same
Initialise the app's database with sample data (CPU, mostly single-threaded)	13.6 s	12.9 to 13.4 s	same
Synchronous writes on a Docker volume (pg_test_fsync, fdatasync / fsync)	154 / 79 ops/s	240 to 290 / 132 to 137 ops/s	1.7× faster
Windows folder mounted in a container, 5,000 files (listing / attributes / reads / writes)	9P	solonfs: 6.6× / 94× / 3.6 to 9× / 4× faster
docker run --rm busybox true, warm	not measured	0.55 s

What this says, honestly: Solon wins clearly on what costs you every day (start-up time, memory, file sharing, disk writes); on pure CPU work the two engines are equivalent; web latency is identical. Both keep the guest's disk cache in memory: Solon is capped by its allocation (2 GB by default), Docker Desktop grew to 5 GB.

Reproduce it: powershell -ExecutionPolicy Bypass -File bench\bench.ps1 on the engine your docker command points at (-Docker "C:\Program Files\Solon\bin\docker.exe" for Solon). The script only touches a Compose project named solon-bench on port 18069 and removes it when done.

Footprint

Solon measured on 13 September 2026 (0.1.10, three containers running); Docker Desktop measured on the same machine on 3 September; the other two from their documentation (marked published).

	Solon	Docker Desktop	Podman Desktop	Rancher Desktop
Installer	102 MB	≈ 600 MB (published)	≈ 100 MB + WSL machine (published)	≈ 500 MB (published)
Installed on disk	406 MB (Linux image 310, docker CLI 73, Solon 22)	6 GB required (published)	500 MB + 2 to 10 GB of images (published)	not published
Memory at rest, no container	430 to 520 MB	1,998 MB	WSL 2 machine, up to 50 % of RAM by default (published)	half of CPU and RAM by default (published)
Memory with a web app + PostgreSQL running	1,196 MB	5,146 MB	not measured	not measured
Needs WSL 2	no (own Hyper-V machine)	yes (or legacy Hyper-V backend)	yes	yes

Features compared

Solon as of 0.2.1; the others as documented in September 2026. "Partial" means it exists with a caveat.

	Solon	Docker Desktop	Podman Desktop	Rancher Desktop
Official docker CLI and Compose, no alias	yes	yes	partial: compatible socket, some differences	yes (moby)
Works without WSL 2	yes	partial: legacy Hyper-V backend	no	no
Windows Home	yes (Virtual Machine Platform)	yes (WSL 2)	yes	yes
https://<service>.<project>.solon.local for every container, trusted local certificate	yes	no	no	no
Projects page: address, environment, ports checked before Up, filtered logs	yes	partial: Compose list	partial: Compose list	no
One environment per Git branch, volumes copied	yes	no	no	no
Project backup and restore, volumes included	yes	partial: third-party extension	no	no
Command line for the engine itself: state, start and stop, settings, backup, why a call failed	yes (solon)	partial: docker desktop start/stop/status (documented)	partial: podman machine (documented)	partial: rdctl (documented)
Idle containers paused, woken on demand	yes	partial: Resource Saver pauses the whole machine	no	no
Windows folders shared with solonfs (3.6 to 94× faster than 9P, depending on the operation)	yes	no: 9P through WSL 2	no: 9P	no: 9P
Find Compose projects on the disk (7 s on 928 GB)	yes	no	no	no
Projects restarted after a Windows restart or an update	yes	partial: Docker restart policy	partial	partial
VS Code Dev Containers	yes, verified	yes	partial: docker path setting	yes
Kubernetes built in	no	yes	partial: Kind / Minikube extensions	yes (K3s)
Windows containers	no	yes	no	no
Extensions marketplace	no	yes	yes	no
Free for companies	yes (Apache 2.0)	paid above 250 employees or $10M revenue	yes (Apache 2.0)	yes (Apache 2.0)
Signed installer	not yet	yes	yes	yes

Requirements

Requirement	Detail
Windows	Windows 11 or Windows 10 22H2, any edition, Home included. Pro, Enterprise and Education use Hyper-V; Home uses the Virtual Machine Platform, which the installer enables (one restart). Verified on Windows 11 Home 25H2. On Home the legacy 9P file-sharing fallback is unavailable; the default sharing works.
CPU	Hardware virtualization enabled in the BIOS/UEFI: Intel VT-x ("Intel Virtualization Technology") or AMD-V ("SVM Mode").
Memory	8 GB recommended (4 GB minimum). Solon gives the engine 2 GB by default, adjustable in Settings.
Disk	~400 MB for Solon and its Linux image, plus a dynamic data disk (64 GB maximum by default, used on demand).
Windows features	"Hyper-V" and "Virtual Machine Platform". The installer enables them; a reboot may be required.

Solon coexists with WSL2 and Docker Desktop: it uses neither their pipe, nor their networks, nor your default docker context.

Installation

Installer

Download Solon_<version>_x64-setup.exe from the releases and check its SHA-256 against the value published with the release. The installer asks for elevation once, then: enables the required Windows features (a reboot may be requested), installs the SolonService service, copies the Linux image and the docker and solon commands, and creates the shortcut. Silent install: Solon_<version>_x64-setup.exe /S.

The installer is not signed yet: SmartScreen shows "Windows protected your PC"; click "More info" then "Run anyway". The signing chain is ready (installer/sign.ps1, tauri.signed.conf.json) and will be enabled as soon as a certificate is available.

Uninstall: Settings → Apps → Solon. The uninstaller stops the engine, removes the service and asks before deleting your images and volumes (%ProgramData%\Solon); by default they are kept.

From source (developers)

Prerequisites: Rust stable (≥ 1.85), Node 22, and Solon itself installed (the engine's Linux image is built inside a Solon container: no WSL needed). An administrator Windows session is only needed for the console mode.

# 1. Guest agent (cross-compiled from Windows, no C toolchain)
rustup target add x86_64-unknown-linux-musl
cargo build --release -p solon-agent --target x86_64-unknown-linux-musl

# 2. Linux image (reused kernel + Alpine root filesystem + initrd), built in a Solon container (~15 s)
docker run --rm -v "${PWD}:/work" -w /work public.ecr.aws/docker/library/alpine:3.24 sh -c "apk add -q bash curl python3 e2fsprogs coreutils tar grep findutils gzip; SKIP_KERNEL=1 SOLON_IMAGE_VERSION=0.1.0-dev.N bash image/build.sh /work/target/x86_64-unknown-linux-musl/release/solon-agent"
#    (the kernel itself is compiled once with image/kernel/build-kernel.sh, ~7 min, in the same kind of container)

# 3. Service, `solon` command and application (the installer embeds image/out/<version>, see tauri.conf.json)
cargo build --release -p solon-service -p solon-cli
cd apps\desktop && npm install && npm run tauri build
#    (the service and the CLI are copied as resources: `tauri build` does not rebuild them, hence the order)

Development mode without installing: start the service in console mode, either by hand (solon-service.exe console --start in an administrator terminal) or with .\tests\e2e\start-console.ps1 -ImageDir .\image\out\<version> -Release (one UAC prompt), then cd apps\desktop; npm run tauri dev.

Using Solon

The left menu has two groups: Docker (Projects, Containers, Volumes, Images, Networks) and General (Activity, Radiography, Terminal, Settings). The button at the top (or Ctrl+B) collapses it to icons. The block at the bottom shows the engine state, its uptime and two mini gauges (CPU, RAM). The tray icon carries a green, orange, red or grey dot depending on the engine state.

• Projects (home): one card per Compose project with its state, its main address (https://web.blog.solon.local, copyable, with the lock), its services, Open / Up / Stop / Details. Folders opened before but not running are listed too; containers started outside a project sit in "Other containers". With nothing yet, the page offers four ways to start: open a folder, choose a stack, find the projects already on this PC, try hello-world. The project page adds an Environment tab: the .env and the environment: blocks of compose.yaml, plus the published ports, editable without touching the YAML.
• Back up and restore a project: "Back up…" on a project page writes one zip with the Compose files, the .env and the data of every volume (taken directly from the engine, running or not); "Restore a backup…" on the Projects home recreates the volumes and files in the folder you choose, then Up.
• Ports checked before Up: a host port already taken on this PC stops Up before anything starts, with "Use 8081 instead" (the file is edited for you) or "Up anyway".
• Find projects on this PC: one click reads the file table of your internal drives (a few seconds, administrator rights of the service, nothing leaves the PC) and lists every folder with a compose.yaml, a Dockerfile or a devcontainer.json, minus dependency, cache and system folders. Tick the ones to keep.
• One environment per Git branch: on a project whose folder is a Git repository, tick "One environment per branch" next to the branch name. Each branch then gets its own containers, volumes and addresses (web.blog-feature-login.solon.local). Switch branch in your terminal and Solon offers to stop the old environment and start the new one, with or without a copy of the old branch's data.
• Restart what was running: when the engine stops (Windows restart, install, Stop from Solon), Solon remembers the projects and containers that were running and starts them again once the engine is back; Docker alone only does that for restart: always containers. Settings → engine, on by default.
• Containers: live list with CPU and memory, filter, Compose groups, icon actions, streamed logs, terminal, inspection. A published port is a link, and so is the local domain. Compose projects live here: "Open a project…" picks a folder containing compose.yaml, and clicking a group header opens the project screen (services, merged logs, Up / Down / Rebuild with live output, Explorer, VS Code).
• Ready-made stacks and project detection: "New stack…" opens a gallery: starter kits that generate a project on first start (Django + PostgreSQL, Flask + Redis, FastAPI + PostgreSQL, Next.js), ready-made apps (WordPress, Odoo 18, PostgreSQL, MariaDB, MongoDB, Redis, n8n, Nextcloud, Ghost, Gitea, Uptime Kuma, Jupyter Lab, static Nginx site) and developer tools (Mailpit): pick one, choose a folder, review the generated compose.yaml, "Create and start". Opening a folder that has no Compose file makes Solon look at what it contains (package.json, requirements.txt, Dockerfile, composer.json, go.mod, Cargo.toml, pom.xml, .csproj, Gemfile…) and propose an environment for it, editable before creation. Nothing is ever overwritten.
• Container page: Overview (image, command, dates, restart policy, networks, ports, mounts, environment, labels, file copy), Logs (All / Warnings / Errors filters with counts, search, wrap, colours; on a project, one chip per service), Files, Terminal, Debug shell, Inspect. Start, stop, restart, remove and "Keep awake" in the header.
• Images, Volumes, Networks: list, create, inspect, remove (always with confirmation). Volumes have a Files browser.
• Activity: the engine's CPU, memory, storage and network as curves over the last 1 min, 10 min or 1 h (your choice), then each running container with CPU, memory, network rates and a CPU curve.
• Radiography (Ctrl+7): who calls whom, in real time. A map (one circle per service, one line per relationship, red when calls fail) and a journal (one exchange per line, unfolding to show headers). What comes in through a *.solon.local address is shown as the complete HTTP exchange; calls between containers show the connection and its outcome; outside addresses carry the name that was resolved. The playback bar pauses, steps from one exchange to the next and replays at ×0.25, ×1 or ×4. Capture bodies, per project, keeps the first 4 KB of text bodies. Headers, URL parameters, form fields and JSON keys with sensitive names, e-mail addresses and phone numbers are masked at capture time. Everything stays on your PC.
• Terminal (Ctrl+\``): a root shell inside the Linux engine itself, for docker, ps, df, dmesg`…
• Search Ctrl+K: containers, images, volumes, networks, projects, engine actions, sections. Ctrl+1 to Ctrl+9 switch sections. Ctrl+Alt+S from any application brings Solon to the front with the search open.
• Settings: language (English by default, French), appearance (light, dark, follow Windows), accent colour (Solon pink or the Windows accent), engine memory and processors (all cores minus two by default), storage limit, start at sign-in, sleep of idle containers, legacy file sharing fallback, diagnostic export.
• Windows notifications: container exited with an error (outside actions you made in Solon), engine failed or restarting, engine disk 90 % full.
• Diagnostic (Settings → Export a diagnostic…): a zip with logs, state, settings, prerequisites and docker info to attach to a bug report. No credentials are included.
• Tray: one click opens the menu: engine state, each project with Start / Restart / Stop, then the loose containers, open Solon, start or stop the engine, quit. Closing the window keeps Solon in the tray.
• The icon starts with Windows (since 0.2.0): on first launch, Solon registers itself in your user's startup entries (Solon.exe --tray: minimized to the tray, no window opened) and says so in a notification. Untick "Start with Windows" in the icon's menu to say no; that no is remembered (%LOCALAPPDATA%\Solon\no-autostart). Uninstalling removes the entry for every profile.

Bundled docker and docker compose

The installer puts C:\Program Files\Solon\bin first on the PATH. It contains the official Docker CLI and the Compose plugin (Apache-2.0, versions in bin\NOTICE-third-party.txt) behind a small docker.exe launcher that points them at the Solon engine. In a new terminal:

docker version
docker compose -f examples\wordpress\compose.yaml up -d

The launcher respects your choices: -H, --context, DOCKER_HOST or DOCKER_CONTEXT win, so Docker Desktop stays reachable if you keep it (docker context use desktop-linux). With another Docker CLI:

docker context create solon --docker host=npipe:////./pipe/solon
docker context use solon

If Docker Desktop is installed, the CLI uses the Windows credential manager and may send stale Docker Hub credentials ("unauthorized: incorrect username or password"). Run docker logout or test with an empty DOCKER_CONFIG; this is not related to Solon.

Command line: solon

The same folder holds solon, Solon's own command. docker talks to the containers; solon talks to the engine around them: its state, its addresses, its settings, the Radiography, backups. It goes through the service's local pipe, like the application: no administrator prompt, no outgoing request (except solon update, below). Messages are in English, or in French when Windows is (SOLON_LANG=fr forces it). solon help lists every command; --json on status, projects, domains, trace, settings, prereq, watch, scan, import and update prints machine-readable output. Exit codes: 0, 1 error, 2 usage, 3 service unreachable.

solon alone is solon status. Outputs below are shortened:

> solon
Solon 0.1.17 · engine ready since 09:12:04 (2 h 31 min)
  image 0.1.0-dev.22 · address 172.30.0.2
  local domains *.solon.local : http and https

2 containers running, 1 asleep (woken on demand)
CONTAINER              PROJECT    STATUS      ADDRESS
wordpress-db-1         wordpress  Up 2 hours  https://db.wordpress.solon.local
wordpress-wordpress-1  wordpress  asleep      https://wordpress.wordpress.solon.local

> solon restart
Restarting the engine…
  checking prerequisites…
  cleaning up…
  verifying the image…
  preparing the data disk…
  creating the network…
  creating the engine…
  booting…
  waiting for the engine…
  configuring the network…
  waiting for Docker…
Engine ready.

> solon projects
PROJECT    STATUS      FOLDER                     ADDRESSES
wordpress  running(2)  C:\Users\me\wordpress      db.wordpress.solon.local, wordpress.wordpress.solon.local

> solon why wordpress
Since 01:27:40, … What stands out:

- 10.90.5.4 tried 4 times to reach db (wordpress) on port 9999 and never got an answer (last at 01:28:51,
  from the program "wget"). Nothing was listening there. Is the container up, and does it listen on that
  port? `docker logs` on it usually says why.

Detail: solon trace wordpress

> solon trace wordpress -n 3
01:28:25  wordpress (wordpress) -> db (wordpress):3306  closed after 48 ms  [apache2]
01:28:25  GET https://wordpress.wordpress.solon.local/wp-login.php  -> 302 in 170 ms  (wordpress (wordpress))
01:28:51  10.90.5.4 -> db (wordpress):9999  FAILED, no answer  [wget]

> solon backup C:\Users\me\wordpress
Backing up wordpress (C:\Users\me\wordpress)…
Written: wordpress-20261031-1422.zip (2 volumes, …)

> solon settings memory=4096 idle=20
Saved.
Memory, processors, disk and file sharing apply at the next engine start: solon restart

solon why reads the same history as the Radiography screen and groups what went wrong: refused calls by caller, destination and port, with a hint (container asleep, nothing listening, address outside the engine), server errors (5xx) per host, 401/403 refusals, the slowest request when it is above one second. When nothing stands out it says so, with the counts. solon trace is the journal (-f follows live, --all prints everything), solon clear [project] forgets it.

solon backup and solon restore do exactly what the application's buttons do: one zip with the Compose file, the .env and the volumes, restored into the folder of your choice. solon domains lists every *.solon.local address answering right now; solon exec runs a command as root inside the engine; solon logs and solon diag give the service log and the zip to attach to a bug report; solon watch prints engine events as they happen; solon prereq checks the Windows prerequisites; solon settings alone shows every setting with its meaning.

Five commands added in 0.2.0 and kept in 0.2.1. solon update reads the latest version published on GitHub, downloads its installer, checks the SHA-256 against the SHA256SUMS.txt of that release and runs it with elevation (--check only tells whether there is one). Together with the application's own update check, it is the only outgoing request Solon makes, and always on demand; from the Store it answers that updates come from the Store. solon scan lists the Docker projects on your internal disks (the service does the search). solon shell opens a root shell inside the engine (docker run -it --privileged --pid=host busybox nsenter). solon clone <from> <to> copies the volumes of a project under another name: one environment per Git branch. solon import lists what Docker Desktop holds and, with --all or --volumes a,b --images x:tag, copies it without touching Docker Desktop.

VS Code Dev Containers

The Dev Containers extension works with Solon as is: it uses the docker on your PATH, which is Solon's. Open a folder that has .devcontainer/devcontainer.json, run "Dev Containers: Reopen in Container", and VS Code builds or pulls the image, starts the container with the folder mounted at /workspaces/<name>, installs its server inside and connects. Forwarded ports work, postCreateCommand runs, and the container appears in Solon's Containers list (and in "Find projects on this PC"). Nothing to configure; if you had set dev.containers.dockerPath for Docker Desktop, remove it. Tested with @devcontainers/cli 0.89 and the mcr.microsoft.com/devcontainers/base:alpine image.

The Containers view (extension ms-azuretools.vscode-containers) refreshes live through docker events. The extension arms that listener once, at startup, and gives up after three immediate failures. Solon's Docker pipe exists as soon as the Solon service starts and docker waits while the engine boots, so a VS Code window restored at logon keeps live refresh. If Solon is updated while VS Code is open, the pipe vanishes for a few seconds and that window falls back to a refresh every minute and the Refresh button: run Developer: Reload Window to get live refresh back.

Shared Windows folders: how it works

Windows folders mounted into containers (-v C:\..., Compose projects) go through solonfs, Solon's file system: a server on the Windows side, a client on the Linux side, and a protocol that fetches a whole folder in one question instead of one per file. Measured on 5,000 files against Windows 9P sharing (the one used by WSL2 and Docker Desktop): 3.6 to 94× faster depending on the operation (listing 6.6×, attributes 94×, reads 3.6 to 9×, writes 4×). Details and method: docs/measurements.md.

• Files appear as owned by root with 0777 / 0666; chmod and chown are accepted and ignored (Windows has no POSIX permissions), as with Docker Desktop.
• A change made on the Windows side is visible in the container within 1.5 s.
• For dependencies and databases, always prefer Docker volumes: they live on Solon's disk at native speed (20 to 50 ms for the same 5,000 files).
• Fallback: Settings → "Use the legacy Windows file sharing (9P)" restores the old mechanism at the next engine start. The old share also stays mounted under /mnt/host9p/<letter> inside the machine.

Troubleshooting

Step-by-step guide for the most common problems (SmartScreen, reboot after enabling Hyper-V, port already in use, container that exits at once, network and solon.local addresses, disk space): https://v94lere.github.io/solon/troubleshooting/. To report a problem, attach the zip from Settings → Diagnostic → "Export a diagnostic…" (logs, state, settings, docker info; no credentials).

Error messages carry a stable code; logs are in %ProgramData%\Solon\logs (service) and can be copied from the error screen.

Code	Cause	What to do
VIRTUALIZATION_DISABLED_IN_FIRMWARE	VT-x / AMD-V disabled	Enable virtualization in the BIOS/UEFI (Advanced, CPU or Security tab), reboot.
WINDOWS_FEATURE_MISSING	Hyper-V or Virtual Machine Platform disabled	Reinstall Solon (the installer enables them) or, in an administrator PowerShell: Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V,VirtualMachinePlatform -All, then reboot.
WINDOWS_FEATURE_BLOCKED_BY_POLICY	Company policy (WSUS, GPO) refuses the feature	Ask your administrator to enable Microsoft-Hyper-V and VirtualMachinePlatform.
HYPERVISOR_NOT_RUNNING	Windows hypervisor not started	Uninstall old VirtualBox/VMware (< 6.1 / < 15.5), check bcdedit /enum (hypervisorlaunchtype Auto), do not run Solon in a VM without nested virtualization.
HOST_COMPUTE_SERVICE_UNAVAILABLE	vmcompute or hns service stopped or missing	Reboot Windows; otherwise reinstall Solon.
BLOCKED_BY_SECURITY_SOFTWARE	Antivirus / EDR blocks the disks or the service	Add %ProgramData%\Solon and the installation folder to the exclusions.
INSUFFICIENT_PRIVILEGES	The service does not run with the expected rights	Reinstall Solon (the service must run as LocalSystem).
IMAGE_CORRUPTED	Engine files missing or SHA-256 mismatch	Reinstall Solon.
DATA_DISK_ERROR	data.vhdx cannot be created or opened	Check disk space and antivirus exclusions; as a last resort rename %ProgramData%\Solon\data.vhdx (loses Docker data).
VM_BOOT_TIMEOUT, AGENT_UNREACHABLE, ENGINE_UNREACHABLE	The machine does not answer	Restart the engine; read solon-service.log; report with the log.
UNSUPPORTED_WINDOWS_EDITION	Windows edition not supported	Solon runs on Windows 10 22H2 and Windows 11, all editions including Home; older builds are not supported. Update Windows.
VM_CONFIGURATION_REJECTED, HCS_ERROR	Windows refused the engine configuration, or the virtualization layer returned an error	Reboot once; if it persists, report with solon-service.log (it carries the Windows error code).
IO	A file under %ProgramData%\Solon could not be read or written	Check disk space and antivirus exclusions on %ProgramData%\Solon.
INTERNAL	A bug in Solon	Report with solon-service.log; the engine usually recovers after a restart.
No network from containers	Corporate VPN or IP range conflict	Solon picks a free range among 172.30.0.0/24… and sets the MTU to 1400; some VPNs (AnyConnect, GlobalProtect) still block virtual adapters: disable the VPN to test, then report.
"The Solon service is not running"	Service stopped	sc start SolonService as administrator, or reinstall.

Power loss or hard shutdown: at the next start Solon checks and repairs the data disk (fsck), then restarts the engine. Unsynced writes of the last two seconds may be lost, as on any Linux machine.

Known limitations (0.1)

• UDP published ports are not relayed to localhost (TCP only).
• One engine per machine, no multiple profiles.
• Not signed (SmartScreen warning). No silent update: Solon tells you when a new version exists (Settings → Updates, one request to github.com, can be turned off). Install update downloads the installer, checks its SHA-256 against the release's SHA256SUMS.txt, then Windows asks you to allow the install; Solon reopens and restarts what was running. Nothing installs without you.
• A sleeping container does not run its internal scheduled tasks until something calls it; use "Keep awake" on its page if that matters.
• curl.exe on Windows rejects the local HTTPS certificates unless you pass --ssl-no-revoke (same as mkcert); browsers and .NET accept them.

Where it is going, and where you can help

Solon is young and the list of what is left to do is longer than the list of what is done. These are the next things I want to build, each with an issue you can comment on or take:

• Update images from the app (#3): a badge when a newer image exists, one button to pull and recreate.
• Relay UDP published ports (#5), the last gap against docker run -p.
• Hot reload from Windows (#7): tell the container when a Windows file changes, so Vite, nodemon and Odoo's reloader notice.
• Windows 10, tested rather than assumed.
• A signed installer: the certificate sponsor asked for community traction first, so this one depends on people finding the project useful.

Good places to start are the issues labelled good first issue and help wanted. CONTRIBUTING.md builds the whole thing in one command, and documentation, translations and bug reproductions count as much as code.

Documentation

• ARCHITECTURE.md: technical choices (HCS virtualization, Linux image, HvSocket, solonfs, network), measured results block by block, risk register. In French.
• docs/guide-fonctionnel.md: the functional guide, screen by screen. In French.
• docs/measurements.md: every measurement and established fact. In French.
• bench/: the comparison script and its Compose stack (see the benchmark above).
• site/: the presentation website (Astro, static), published to GitHub Pages by the Site workflow.
• tests/e2e/: end-to-end scenarios.
• CONTRIBUTING.md: how to contribute; SECURITY.md: how to report a vulnerability; CODE_OF_CONDUCT.md.

Licence

Apache License 2.0, see LICENSE and NOTICE. Solon bundles third-party software (Docker CLI, Docker Compose, a Linux kernel, Alpine Linux packages, Rust and npm dependencies, the Urbanist font) under their own licences: see THIRD-PARTY.md.