Open source · Windows 10 & 11, any edition · Apache 2.0
Solon
Docker on Windows, without Docker Desktop or WSL.
Solon is a standalone container manager: one installer, a complete Docker engine running in a tiny Linux machine that Solon creates and manages itself. No licence, no telemetry, no WSL.
Windows 11 or 10 22H2, any edition (Home included), hardware virtualization enabled. Check the SHA-256 published with each release.
The installer is not signed yet: SmartScreen shows a warning, choose “More info” then “Run anyway”. Code signing through the SignPath Foundation (free signing for open-source projects) has been requested; releases will be signed as soon as the project is accepted.
≈ 3 sengine ready after you ask for itDocker Desktop: 6.1 s
4×less memory at rest and with a stack running430–520 MB vs 1,998 MB
0telemetry, accounts, licence feesApache 2.0
See it in action
A stack in one clickNew stack… → n8n → Create and start. Twenty seconds later the browser opens on https://n8n.n8n.solon.local with a trusted certificate. No port to publish, nothing to install on Windows.
Look insideA container's page: logs, the Files tab to browse and exchange files with Windows, and the debug shell with ps, curl and friends, even in images that ship no shell.
ActivityCPU, memory and network per container, hover for exact values, click a name to isolate it, 1 min / 10 min / 1 h windows.
What Solon does
Addresses that always work
Every container answers at https://<name>.solon.local, published port or not, with a certificate your browser trusts. Compose services get <service>.<project>.solon.local.
Fast Windows folders
Folders mounted into containers go through solonfs, Solon's own file sharing: 3.6 to 94× faster than the 9P sharing used by WSL2 and Docker Desktop, depending on the operation (docs/measurements.md).
Wake on demand
A container that receives no traffic for ten minutes is paused; the next request wakes it in a fraction of a second. Databases that only talk internally are never touched.
Ready-made stacks
WordPress, Odoo 18, PostgreSQL, MariaDB, MongoDB, Redis, n8n, Nextcloud, Ghost, Gitea, Uptime Kuma, Jupyter Lab, Mailpit… and starter kits for Django, Flask, FastAPI and Next.js that generate a project on first start.
Compose, all of it
Open a folder, Solon detects the stack or proposes one. Services, merged logs, Up / Down / Rebuild, and the compose file editable in place with Save and Up.
See inside
Files tab with drag-and-drop, terminal, debug shell that works even in images without a shell, live CPU, memory and network charts per container. VS Code Dev Containers work as is.
Radiography
Who calls whom, live: a map of your services and a journal of every exchange, refused calls in red, full HTTP for what comes through a local address, names on outside hosts. Pause, step, replay. Sensitive values masked before they are stored; everything stays on your PC.
Containers grouped by Compose project, each with its solon.local address.
A container's page: network, mounts, environment, files, terminal, debug shell.
The gallery of ready-made stacks and starter kits.
Measured against Docker Desktop, compared with the others
Same machine (Windows 11 Pro, 24 logical cores), same Compose stack (a Python web app and PostgreSQL 16), default settings on both sides. Docker Desktop 4.66.1 was measured on 3 September 2026, then uninstalled; Solon 0.1.0 was re-measured on 10 September 2026 with the script in bench/.
Honestly: Solon wins on what costs you every day (start-up, memory, files, disk writes); on pure CPU work the two are equivalent; web latency is the same. Reproduce it with bench/bench.ps1. bench/
Footprint
Solon measured on 13 September 2026 with three containers running; Docker Desktop measured on the same machine; Podman Desktop and Rancher Desktop from their documentation (published, not measured here).
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
6 GB required (published)
500 MB + 2–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 (published)
half of CPU and RAM by default (published)
Memory with a web app + PostgreSQL
1,196 MB
5,146 MB
not measured
not measured
Needs WSL 2
no
yes, or legacy Hyper-V
yes
yes
Features compared
Solon as of 0.2.1; the others as documented in September 2026. “Partial” means the feature exists with a caveat.
Solon
Docker Desktop
Podman Desktop
Rancher Desktop
Official docker CLI and Compose, no alias
yes
yes
partial: compatible socket
yes (moby)
Works without WSL 2
yes
partial: legacy Hyper-V
no
no
Windows Home
yes
yes
yes
yes
https://service.project.solon.local for every container, trusted 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: extension
no
no
Idle containers paused, woken on demand
yes
partial: whole machine (Resource Saver)
no
no
Windows folders shared with solonfs, 3.6 to 94× faster than 9P depending on the operation
yes
no: 9P
no: 9P
no: 9P
Find Compose projects on the disk
yes
no
no
no
VS Code Dev Containers
yes, verified
yes
partial: path setting
yes
Kubernetes built in
no
yes
partial: 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
yes
yes
Signed installer
not yet
yes
yes
yes
Stacks and starter kits
“New stack…” opens a gallery. Pick one, choose a folder, review the generated compose.yaml, “Create and start”. Opening a folder without a Compose file makes Solon look at what it contains and propose an environment.
Starter kits
The project folder is mounted in the container; on the first Up a small script installs the dependencies, generates the official skeleton if the folder is empty, then runs the development server with live reload. Nothing to install on Windows.
Every release ships the installer and its SHA-256. Installing over a previous version keeps your images, containers and volumes.
Solon 0.2.0
Solon no longer has a window. It has an icon in the taskbar corner and the `solon` command. *Version française plus bas.*
Why
Solon was a very good Docker Desktop, and "very good" does not make anyone switch tools. What makes Solon different is what happens underneath: the real `docker` and `docker compose`, no WSL, Windows Home included, an engine that boots in three seconds, puts idle containers to sleep and gives the memory back, an `https://service.project.solon.local` address for every container, and a Radiography that says in plain words why a service does not answer. None of that needs a window. So the window is gone, and with it a few hundred megabytes of interface that merely duplicated `docker`.
What you get
The icon, bottom right. One click: the engine state, your Compose projects with *Open https://…*, *Start*, *Restart*, *Stop*, the same for lone containers, *Open a terminal* with `solon` and `docker` ready, *Why is it broken?*, *Update Solon…*, *Start with Windows* (on; untick once and it stays off), *Start / Stop engine*, *Quit*. Windows notifications when the engine fails, when Docker restarts, when the engine disk is almost full, and when your projects are back after a reboot.
The `solon` command, next to `docker` in your PATH. Everything the window did is there, and more:
- `solon` : engine state and every running container with its address.
- `solon start | stop | restart`, `solon projects`, `solon domains`, `solon settings key=value`.
- `solon why [name]`, `solon trace [name] -f`, `solon clear` : the Radiography, in text.
- `solon backup`, `solon restore`, `solon clone <from> <to>` (one environment per Git branch, volumes copied).
- `solon scan` (Docker projects on this PC), `solon import` (volumes and images from Docker Desktop, untouched), `solon shell` (root inside the engine).
- `solon update` : checks GitHub, downloads the installer, verifies its SHA-256, installs. The only outgoing request Solon ever makes, and only when you ask.
- `solon prereq`, `solon logs -f`, `solon diag`, `solon exec`, `solon watch`, `solon version`. `--json` where it makes sense.
What disappears
The Containers, Images, Volumes and Networks screens (`docker` does that), the Projects page with its Compose editor, logs panel, file browser and templates (your editor, `docker compose logs`, `docker cp`), the in-machine terminal (`solon shell`), the Activity graphs (`docker stats`, no graphical equivalent), the Radiography map and playback bar (`solon trace` and `solon why` for now; the map comes back in a VS Code extension, the next step), the Settings screen (`solon settings`), the command palette, the welcome tour, themes.
Your images, containers, volumes, settings and history do not move. Installing 0.2.0 over any 0.1.x keeps everything.
Installation
Download `Solon_0.2.0_x64-setup.exe` and check its SHA-256 against `SHA256SUMS.txt`. Open a new terminal afterwards to get `solon` on the PATH.
Solon gets a command: `solon`. *Version française plus bas.*
New: the `solon` command
It is installed next to `docker`, in the same folder already on your PATH. `docker` talks to your containers; `solon` talks to the engine around them. No administrator prompt, no outgoing request. English, or French when Windows is.
- `solon` : engine state, then every running container with its project and its `https://service.project.solon.local` address.
- `solon start`, `solon stop`, `solon restart` : with the steps shown as they happen.
- `solon projects`, `solon domains` : your Compose projects with their Windows folder, and every local address answering right now.
- `solon why [name]` : what is wrong, in plain words, from the Radiography history. Refused calls grouped by caller, destination and port, with a hint (container asleep, nothing listening, address outside the engine); server errors 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 [name] [-f]`, `solon clear [project]` : the journal of exchanges, live with `-f`.
- `solon backup`, `solon restore` : the same one-zip backup as the application, from a script.
- `solon settings key=value`, `solon prereq`, `solon logs -f`, `solon diag`, `solon exec`, `solon watch`, `solon version`.
- `--json` on status, projects, domains, trace, settings, prereq and watch for scripts.
Also
The application and the command now share one code base for the service channel, backups and diagnostics. Nothing changes on screen.
Installation
Download `Solon_0.1.18_x64-setup.exe` and check its SHA-256 against `SHA256SUMS.txt`. Installing over 0.1.x keeps your images, containers and volumes. Open a new terminal to get `solon` on the PATH.
A maintenance release: a full read-through of the code found about ninety defects, and the serious ones are fixed here. Nothing new to learn. *Version française plus bas.*
Fixed in the app
- The Explorer, Open logs and Open buttons of the diagnostic did nothing: a permission was missing.
- Engine and Radiography subscriptions were never closed, and the per-container statistics streams outlived their screen: each visit left about ten more open. They are now closed when you leave.
- A black console window flashed on every file copy. No more.
- Down on a project and Clear in Radiography now ask for confirmation; both are destructive.
- Pressing Enter inside a dialog no longer triggers the action behind it. Saving settings twice in a row, invalid numbers in Settings, a "yes" that was not translated, a stale update banner after updating: fixed.
Fixed in the engine service
- The Windows `hosts` file could be rewritten with only Solon's lines left, when the antivirus was holding it or when it contained a non-ASCII character in ANSI encoding. Personal entries were lost. It is now read as bytes, retried while locked, and rewritten byte for byte.
- A single timed-out call to the engine shifted every later answer until the next restart.
- Two shared drives could end up on the same port after a drive was unplugged, so the second one read the first.
- The private key of the local https certificate authority is only created if its folder can be restricted to administrators, and the authority can only sign `*.solon.local`.
- The sleep logic no longer pauses a container that still has an open connection.
- The relay and the control pipe no longer stop serving after a transient Windows error. A line without end on the control pipe is rejected instead of being read forever. Settings are validated and written atomically.
Fixed in the Linux engine
- The reaper of dead processes could block for good and fill the process table of the engine.
- One malformed frame from the file server could bring the whole engine down.
- The DNS relay from 0.1.16 is now bounded: packet size, in-flight queries, remembered names.
- Container runtime shutdown is now kill, wait, remove, in that order.
Radiography masking
Headers with a suspicious name outside the known list, OAuth redirections carrying `?code=`, and `;jsessionid=` path segments are masked too.
Uninstall
The "Solon Local CA" certificate is now really removed from the Windows store at uninstall, as the Store listing has promised all along.
Installation
Download `Solon_0.1.17_x64-setup.exe` and check its SHA-256 against `SHA256SUMS.txt`. Installing over 0.1.x keeps your images, containers and volumes.
A new screen: Radiography, a debugger for what your services say to each other. *Version française plus bas.*
New
- Radiography (`Ctrl+7`). A live map of who calls whom inside your projects, and a journal of every exchange: TCP connections with their outcome, and for anything that comes in through a `*.solon.local` address, the full HTTP exchange — method, path, status, duration, headers on both sides. A refused connection shows up in red without instrumenting anything: that is the case nobody finds in the logs, because the calling library swallows the error. The map draws one circle per service and one line per relationship; the journal unfolds line by line.
- A playback bar. Pause, go back 10 seconds, step from one exchange to the next, replay at ×0.25, ×1 or ×4, and come back to live. While you scrub, the whole screen — map and journal — shows the engine as it was at that instant. Space and the arrow keys drive it.
- Request and response bodies, per project. Off by default. Pick a project and tick *Capture bodies*: Solon keeps the first 4 KB of each body, only for text (JSON, HTML, forms, XML), never for images, archives or compressed responses. The Settings screen lists the projects it applies to.
- Names on outside addresses. The engine now runs a tiny DNS relay: it forwards your containers' questions to the DNS servers your PC already uses, returns the answers untouched, and remembers which name resolved to which address. The journal shows `api.stripe.com`, not a number. If the relay does not answer, containers fall back to your PC's servers on their own. Containers started before this update keep the old setting until they are recreated.
- *Clear* follows the project filter: with a project selected, it clears only that project.
Masked, before it is stored
Nothing sensitive reaches the history. `Authorization`, `Cookie`, `Set-Cookie`, API keys and the like keep their name but lose their value. URL parameters and form fields whose name contains `pass`, `pwd`, `token`, `secret`, `key`, `auth`, `session`… lose their value; so do JSON keys with such names, at any depth. E-mail addresses and phone numbers disappear from paths, headers and bodies. The masking happens at capture time, not at display time: what was not captured cannot leak, even if the history is read later.
Testing this on a real WordPress caught a hole before release: WordPress sends its password as `pwd`, which was not in the list. It is now.
What it costs
One kernel probe on TCP state changes, measured at about 4 µs per connection on the worst case there is (refused connections in a loop). A thousand connections per second would cost 0.4 % of one core. The reader inside the engine stays under 4 MB. Everything stays on your PC; nothing is sent anywhere, and nothing is written outside `%ProgramData%\Solon`.
Not yet
Calls from container to container show the connection but not its content, and database protocols are not decoded. HTTPS going out of a container is not read either. These come next; the design notes are in `docs/radiographie.md`.
Installation
Download `Solon_0.1.16_x64-setup.exe` and check its SHA-256 against `SHA256SUMS.txt`. Installing over 0.1.x keeps your images, containers and volumes. Containers you want named in Radiography should be recreated once (`docker compose up -d --force-recreate`) so they pick up the DNS relay.
A small one: the Activity screen stops forgetting. *Version française plus bas.*
Fixed
- The Activity graphs no longer reset when you leave the screen. All the measuring lived inside the view, so switching to another section threw the history away — which meant the *10 min* and *1 h* buttons could never show anything, even though the code already kept an hour of points. The engine counters are now collected outside the view: every 2 seconds while you are looking at Activity, every 5 seconds otherwise, and not at all while the window is hidden, since Solon lives in the tray and nobody is reading. An hour at 5 seconds is 720 points across three series.
Per-container curves still start fresh with the view. Docker's stats stream costs CPU per container, and keeping an hour of curves for twenty containers would be expensive to collect and rarely looked at.
- The engine block at the bottom of the sidebar was polling the same counters on its own every 3 seconds. It reads the shared history now, so one duplicate polling loop is gone. Solon does slightly less work than before, not more.
Also
- A benchmark for something nobody measures: how much memory actually comes back to Windows. On the development machine, a container took 747 MB and 676 MB of it were returned in under 35 seconds — about 90 %, with the rest staying flat afterwards. Run it yourself with `bench\mem-reclaim.ps1`; the numbers and the method are in `docs/measurements.md`. The other engines were not measured here, so this says what Solon does, not what they do not.
Installation
Download `Solon_0.1.15_x64-setup.exe` and check its SHA-256 against `SHA256SUMS.txt`. Installing over 0.1.x keeps your images, containers and volumes.
Windows Home works too: the installer enables the Virtual Machine Platform, which is enough for Solon.
No Kubernetes, no separate Linux machines, no ARM images (x86-64 only).
The installer is not signed yet; signing is the next step before a wider launch.
No silent update: Solon tells you when a new version exists (Settings → Updates, can be turned off). One click downloads the installer, checks its SHA-256 and lets Windows ask you before installing.
Tested on the development machine and one fresh machine. Reports from other configurations are very welcome.