Open source · Windows 10 & 11, any edition · Apache 2.0

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.

Solon_0.2.0_x64-setup.exe · 103 MB · SHA-256 c3e6b2d6f5b019d47d3a161e018e0dac8d07a731f515404d3a3a93c5bc0fb5ce · Releases

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.

Solon's Activity page: CPU curves per containerSolon's Activity page: CPU curves per container
≈ 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/.

Docker DesktopSolon
Engine ready after start6.1 s2.6 to 3.4 s
Memory at rest, no container1,998 MB430 to 520 MB
Memory with the stack running5,146 MB1,196 MB
compose down then up -d7.1 s5.2 s
The web app answers after up1.5 s1.0 to 2.5 s
Login page, average of 527 to 46 ms48 to 88 ms
Initialise the database with sample data (CPU)13.6 s12.9 to 13.4 s
Synchronous writes on a volume, fdatasync / fsync154 / 79 ops/s240–290 / 132–137 ops/s
Windows folder, 5,000 files: listing / attributes / reads / writes9P6.6× / 94× / 3.6–9× / 4× faster

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).

SolonDocker DesktopPodman DesktopRancher Desktop
Installer102 MB≈ 600 MB (published)≈ 100 MB + WSL machine (published)≈ 500 MB (published)
Installed on disk406 MB6 GB required (published)500 MB + 2–10 GB of images (published)not published
Memory at rest, no container430 to 520 MB1,998 MBWSL 2 machine, up to 50 % of RAM (published)half of CPU and RAM by default (published)
Memory with a web app + PostgreSQL1,196 MB5,146 MBnot measurednot measured
Needs WSL 2noyes, or legacy Hyper-Vyesyes

Features compared

Solon as of 0.2.1; the others as documented in September 2026. “Partial” means the feature exists with a caveat.

SolonDocker DesktopPodman DesktopRancher Desktop
Official docker CLI and Compose, no aliasyesyespartial: compatible socketyes (moby)
Works without WSL 2yespartial: legacy Hyper-Vnono
Windows Homeyesyesyesyes
https://service.project.solon.local for every container, trusted certificateyesnonono
Projects page: address, environment, ports checked before Up, filtered logsyespartial: Compose listpartial: Compose listno
One environment per Git branch, volumes copiedyesnonono
Project backup and restore, volumes includedyespartial: extensionnono
Idle containers paused, woken on demandyespartial: whole machine (Resource Saver)nono
Windows folders shared with solonfs, 3.6 to 94× faster than 9P depending on the operationyesno: 9Pno: 9Pno: 9P
Find Compose projects on the diskyesnonono
VS Code Dev Containersyes, verifiedyespartial: path settingyes
Kubernetes built innoyespartial: extensionsyes (K3s)
Windows containersnoyesnono
Extensions marketplacenoyesyesno
Free for companiesyes (Apache 2.0)paid above 250 employees or $10Myesyes
Signed installernot yetyesyesyes

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.

Django + PostgreSQLFlask + RedisFastAPI + PostgreSQLNext.js

Ready-made apps

WordPressPostgreSQL + AdminerMariaDB + AdminerMongoDB + Mongo ExpressRedisn8nNextcloudGhostGiteaUptime KumaJupyter LabStatic site (Nginx)

Developer tools

MailpitBlank compose.yaml

Releases

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 0.1.18

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.

Solon 0.1.17

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.

Solon 0.1.16

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.

Solon 0.1.15

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.

Known limitations

  • 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.